netdev - Re: multicast: bug or "feature"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <47166E4D.70802@hp.com>
Date:	Wed, 17 Oct 2007 16:19:25 -0400
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	Rick Jones <rick.jones2@...com>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: multicast: bug or "feature"

Rick Jones wrote:
> Vlad Yasevich wrote:
>> We've been trying to field some questions regarding multicast
>> behavior and one such behavior has stumped us.
>>
>> I've reproduced the following behavior on 2.6.23.
>>
>> The application opens 2 sockets.  One socket is the receiver
>> and it simply binds to 0.0.0.0:2000 and joins a multicast group
>> on interface eth0 (for the test we used 224.0.1.3).  The other
>> socket is the sender.  It turns off MULTICAST_LOOP, sets MULTICAST_IF
>> to eth1, and sends a packet to the group that the first socket
>> joined.
>>
>> We are expecting to receive the data on the receiver socket, but
>> nothing comes back.
>>
>> Running tcpdump on both interfaces during the test, I see the packet
>> on both interfaces, ie. I see it sent on eth0 and received on eth1 with
>> IP statistics going up appropriately.
> 
> I think you got things switched - in the beginning you said that the
> receiver has joined a multicast group on eth0 and the sender set
> MULTICAST_IF to eth1, but in the paragraph just above you say
> transmission is on eth0 and reception is on eth1...

Yes, that was just the typing switch.  The send packet was on eth1
(the checksum wasn't finished yet), and the received packet was
on eth0.

> 
> I am _guessing_ that the MULITCAST_LOOP stuff is implemented with "is
> this datagram's source IP one of the local IP's on the system" rather
> than "is this datagram from my own socket"
> 

Well, from what I've see, MULTICAST_LOOP is checked only on output, so
that doesn't seem to be the issue.

Also, IPv6 works as expected, i.e. I can receive the data in the app
above if I use IPv6 multicast addresses.

-vlad
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html