[Xorp-users] Re: Newbie Xorp & m'cast problem

Pavlin Radoslavov pavlin@icir.org
Tue, 14 Jun 2005 23:10:27 -0700


> >> [ 2005/06/07 17:29:02  ERROR xorp_fea:16848 MFEA +1340 
> >> mfea_proto_comm.cc proto_socket_read ] proto_socket_read() failed: 
> >> invalid unicast sender address: 0.0.0.0
> > 
> > Those "invalid unicast sender address: 0.0.0.0" messages are odd.
> > Do you run a sender or a receiver on the same box as the XORP
> > router?
> > In any case, please run tcpdump on all network interfaces and try to
> > catch if there are any IP packets that have indeed source address of
> > 0.0.0.0.
> 
> 	I had a very large TCPDUMP with several packets sourced from 0.0.0.0
> 
> 	I deleted it already, but if I remember correctly, the suspicious 
> packets has been IGMP leave messages sent to ALL-ROUTERS GROUP.
> 
> 	I have the only example of it now:
> 
> 00:28:51.713070 0.0.0.0 > ALL-ROUTERS.MCAST.NET: igmp leave 227.11.22.33 
> [tos 0xc0]  [ttl 1]

Later Mark ran tcpdump and I think his src=0.0.0.0 packets also were
"IGMP leave" messages. I don't know whether he found by the MAC
address where the messages came from.

> 
> 	I have no MAC so I don't know the exact source of it.
> 
> 	They sems to be sent sometime by hosts which lost the IP (DHCP renewal 
> expired, for example) or shutting down.

This is an interesting observation.
If the DHCP renewal expired, and if the IP stack removed the IP
address before it sent the IGMP leave message, then the IGMP leave
message may indeed appear from 0.0.0.0.

Looks like a bug in the particular IP stack implementation, and it
would be interesting to find the OS(es) with such behavior.


> 	There are seems not to be reason to ignore IGMP from this source unless 
> we are hesitate about the forged leave messages.

Indeed, Section 10 (Security Considerations) in RFC 2236 says that
we shouldn't accept such leave messages:

     - Ignore the Leave message if you cannot identify the source
       address of the packet as belonging to a subnet assigned to the
       interface on which the packet was received.  This solution means
       that Leave messages sent by mobile hosts without addresses on the
       local subnet will be ignored.

Furthermore, some OSes don't tell us the interface a packet has
arrived on, and in case of link-local multicast we have to use the
source address to match it against the corresponding interface.
Hence, in such case we cannot match packets with src=0.0.0.0 to the
corresponding interface.

In any case, ignoring suspicious IGMP leave messages is harmless,
because in the worst case then it will take up to [Group Membership
Interval] (260 sec) to timeout the lastest group member.

Pavlin

> 	Well, it may not help to analyse Mark's problem too much, but it's 
> information that IGMP message from 0.0.0.0 may not be rare.
> 
> 						Dan