On Thu, 20 Apr 2006, Andrew Athan wrote:
> I sent a similar message to LKML, but thought this list might also be
> appropriate.
>
> It's likely this is a programming error, but I am at a loss.
>
> The simple UDP multicast receive application below, adapted from source
> on IBM's web site, will not receive any data. While it is blocked on
> recv():
...
> And tcpdump shows traffic arriving at the interface(see below)! This
> leads me to belive the kernel is filtering it, and or not delivering it
> to the socket.
>
> The one "strange" thing about this network is that the traffic is
> flowing in "dense mode", meaning there is no explicit need for IGMP
> messaging (nor any response to such messaging).
>
> Can anyone point me in the right direction regarding why the socket
> never receives any data????
>
> Thanks.
> Andrew
It is possible that the kernel is dropping the multicast traffic because
it is not arriving on the "correct" interface for the source of the
traffic, which would be the interface out which you would route traffic
to that source. In your case the multicast traffic is being received
on interface eth1, but the "correct" interface for source 206.200.5.144
might be eth0 (or one of its subinterfaces). If that's the case, then
you might want to check out the settings of:
/proc/sys/net/ipv4/conf/*/rp_filter
>From /usr/src/linux/Documentation/networking/ip-sysctl.txt:
rp_filter - BOOLEAN
1 - do source validation by reversed path, as specified in RFC1812
Recommended option for single homed hosts and stub network
routers. Could cause troubles for complicated (not loop free)
networks running a slow unreliable protocol (sort of RIP),
or using static routes.
0 - No source validation.
conf/all/rp_filter must also be set to TRUE to do source validation
on the interface
Default value is 0. Note that some distributions enable it
in startup scripts.
I don't know if this even applies to multicast traffic.
-Hope this helps
-Bill
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
