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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 18 Oct 2007 12:17:12 -0400
From:	Vlad Yasevich <vladislav.yasevich@...com>
To:	netdev <netdev@...r.kernel.org>
Cc:	Brian Haley <brian.haley@...com>,
	David Stevens <dlstevens@...ibm.com>
Subject: Re: multicast: bug or "feature"

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.
> 
> Looking at the group memberships, I see the receiving interface as
> part of the group and IGMP messages were on the wire.
> 
> So, before I try to spend time figuring out where the packet went is
> why, I'd like to know if this is a Linux "feature".
> 

Ok, so I've traced the failure down to fib_validate_source().

Because the packet we received was sourced from one of our own
addresses, we end up finding a RTN_LOCAL route and fail out
of that function with -EINVAL.

I can see the reason for this behavior and I think dropping
in this case is fine.

Now, to figure out what IPv6 does different and why it works.
Seems to me that the two should have the same behavior.

-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