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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
