Re: multicast issues

[Hans-Peter Jansen]

Hi David,

Am Montag, 17. März 2008 schrieb David Stevens:
> Your program is not specifying the interface on which to join
> the multicast groups, for one thing. You can use "netstat -gn"
> to verify that you joined it on the interface you want.

Ahh, nice trick I didn't notice before. Very helpful.

On the offending (send/receive handicapped) host:

~# LANG=C netstat -gn
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      224.0.0.1
eth0            1      232.1.1.1
eth0            1      224.0.0.1
lo              1      ff02::1
eth0            1      ff02::1:ff24:683c
eth0            1      ff02::1

Looks like it bound to the (one and only real) interface. 

> If you 
> leave that as "INADDR_ANY", the system will pick an
> interface which may or may not be the one you want. That's
> on the client side.

It looks like it prefers eth0 over the others, which is generally a good 
choice in my environment.

> I don't use python, so I'm not sure, but it appears that you
> are not checking the return values of the system calls.
> Doing that to see if there are failures in any of those would
> also be a good idea.

Even if it doesn't appear so, python does error checking implicitely for the 
socket calls by raising exceptions in the failure case. Not catching them 
would trigger a backtrace. That's of course not obvious for anybody not 
used to python.

> You can also use wireshark or tcpdump in promiscuous
> mode to verify that the packets are being sent on the
> correct interface.

I should have mentioned, that I did that already. On the offending host, it 
doesn't receive a single bit on that port while the client is running. 
Running in server mode, I can see the packets on that interface, but 
nowhere else. Looks like it never leaves the NIC unless I use 224.0.0.1. 

Since it smells stronger then ever like an specific driver issue, I will 
continue nagging Ayaz Abdulla about the issue. 

I'm still unsure about the call of {ip ,}route. Is it still necessary?
Tried the following variants, with no change in behavior whatsoever:

route add -net 224.0.0.0/4 dev eth0
ip route add 224.0.0.0/4 dev eth0
ip route add multicast 224.0.0.0/4 dev eth0

Thanks for your care, David.

Pete
--
To unsubscribe from this list: 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