[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47178708.2040606@hp.com>
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
Powered by blists - more mailing lists