Date: Thu, 17 Aug 2000 12:55:16 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: gbnaidu@sasi.com Cc: freebsd-net@FreeBSD.ORG Subject: Re: multicast packets & tcpdump... Message-ID: <y7vhf8kh78b.wl@condor.isl.rdc.toshiba.co.jp> In-Reply-To: In your message of "Wed, 16 Aug 2000 18:03:09 %2B0530 (IST)" <Pine.LNX.4.21.0008161759470.738-100000@pcd75.sasi.com> References: <Pine.LNX.4.21.0008161759470.738-100000@pcd75.sasi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Wed, 16 Aug 2000 18:03:09 +0530 (IST), >>>>> "G.B.Naidu" <gbnaidu@sasi.com> said: > I was looking at the tcpdump output while multicast packets are flowing > between two routers, tcpdump shows the source and destination address as > "224.0.0.2". It should show the source address of the multicast packet > rather than the multicast group address. > I found that, when the receiver does the recvfrom(), the address returned > shows the multicast group address. Is this a bug or feature? On linux this > shows the source address. I suspect those two facts means that the source address of the multicast packet was really a multicast address. If you bind a socket to an IPv4 multicast address on a BSD system (including FreeBSD) and try to send a (unicast or multicast) packet via the socket, the source address of the packet is the bound multicast address. For example, if you have the following PCB Proto Recv-Q Send-Q Local Address Foreign Address udp 0 0 224.0.0.2.6666 *.* and send a packet to 224.0.0.5 through the socket, the packet will be as follows: 12:49:49.914187 224.0.0.2.6666 > 224.0.0.5.6666: udp 0 [ttl 1] 4500 001c 2ecb 0000 0111 cafe e000 0002 e000 0005 1a0a 1a0a 0008 0bc2 In this case, of course, the recvfrom() call on the receiver side will retrun the multicast address (224.0.0.5) as the packet's source address. Note that the same thing does not happen for BSD's IPv6 implementation. The IPv6 network layer rejects packets with multicast source addresses to be sent on the wire. I think a similar fix should be implemented for IPv4, too. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y7vhf8kh78b.wl>