RE: Multicast problem
> > > > > > OK, so from all this and earlier mail I think that the > > device driver don't > > > receive multicast pkgs. Tomorrow I will try the real OSPF > > test case with > > > promisc mode enabled, se if that works. If so, it means there is > > > a bug in the drivers(ucc_geth.c) set_multicast_list() function. > > > > > > Thank you for helping me to narrow it down. > > > > > > Jocke > > > > You can test multicast easily standalone with iperf: > > http://dast.nlanr.net/Projects/Iperf/#multicast > > > > Thanks, will give it a try. > Managed to cross compile iperf and ran the test. I need promisc mode on the ethernet i/f to receive anything from that test so I guess this confirms it, the set_multicast_list() in ucc_geth driver is broken. Leo, forgot to CC you earlier. Seem like the multicast function is somewhat buggy. Jocke - 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
RE: Multicast problem
> -Original Message- > From: Stephen Hemminger [mailto:[EMAIL PROTECTED] > Sent: den 16 oktober 2007 22:13 > > On Tue, 16 Oct 2007 22:07:35 +0200 > "Joakim Tjernlund" <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > > > From: David Stevens [mailto:[EMAIL PROTECTED] > > > Sent: den 16 oktober 2007 21:46 > > > To: Joakim Tjernlund > > > Cc: 'Netdev'; [EMAIL PROTECTED] > > > Subject: RE: Multicast problem > > > > > > > dev_mcast and igmp looks: > > > > [EMAIL PROTECTED]:/proc/net# m dev_mcast > > > > 1eth01 0 01005e01 > > > > 2eth11 0 01005e01 > > > > > > These are the hardware multicast addresses for > > > 224.0.0.1 (so, correct). > > > > > > > [EMAIL PROTECTED]:/proc/net# m igmp > > > > Idx Device: Count Querier GroupUsers > > > TimerReporter > > > > 1 eth0 : 1 V3 > > > > E001 1 0: 0 > > > > 2 eth1 : 1 V2 > > > > E001 1 0: 0 > > > > 4 lo: 0 V3 > > > > E001 1 0: 0 > > > > > > ...and these are the group memberships for 224.0.0.1, so > > > also correct. This should receive and answer pings to 224.0.0.1 > > > as long as you don't have ICMP set to ignore broadcasts. > You should > > > not need to put the device in promiscuous mode for a ping of > > > 224.0.0.1 to work, so if you do, then you have a driver, device > > > or switch problem. > > > None of these interfaces have memberships in the > OSPF groups, > > > so if you had OSPF running when you did this, it didn't join. > > > > > > +-DLS > > > > > > > OK, so from all this and earlier mail I think that the > device driver don't > > receive multicast pkgs. Tomorrow I will try the real OSPF > test case with > > promisc mode enabled, se if that works. If so, it means there is > > a bug in the drivers(ucc_geth.c) set_multicast_list() function. > > > > Thank you for helping me to narrow it down. > > > > Jocke > > You can test multicast easily standalone with iperf: > http://dast.nlanr.net/Projects/Iperf/#multicast > Thanks, will give it a try. - 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
Re: Multicast problem
On Tue, 16 Oct 2007 22:07:35 +0200 "Joakim Tjernlund" <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: David Stevens [mailto:[EMAIL PROTECTED] > > Sent: den 16 oktober 2007 21:46 > > To: Joakim Tjernlund > > Cc: 'Netdev'; [EMAIL PROTECTED] > > Subject: RE: Multicast problem > > > > > dev_mcast and igmp looks: > > > [EMAIL PROTECTED]:/proc/net# m dev_mcast > > > 1eth01 0 01005e01 > > > 2eth11 0 01005e01 > > > > These are the hardware multicast addresses for > > 224.0.0.1 (so, correct). > > > > > [EMAIL PROTECTED]:/proc/net# m igmp > > > Idx Device: Count Querier GroupUsers > > TimerReporter > > > 1 eth0 : 1 V3 > > > E001 1 0: 0 > > > 2 eth1 : 1 V2 > > > E001 1 0: 0 > > > 4 lo: 0 V3 > > > E001 1 0: 0 > > > > ...and these are the group memberships for 224.0.0.1, so > > also correct. This should receive and answer pings to 224.0.0.1 > > as long as you don't have ICMP set to ignore broadcasts. You should > > not need to put the device in promiscuous mode for a ping of > > 224.0.0.1 to work, so if you do, then you have a driver, device > > or switch problem. > > None of these interfaces have memberships in the OSPF groups, > > so if you had OSPF running when you did this, it didn't join. > > > > +-DLS > > > > OK, so from all this and earlier mail I think that the device driver don't > receive multicast pkgs. Tomorrow I will try the real OSPF test case with > promisc mode enabled, se if that works. If so, it means there is > a bug in the drivers(ucc_geth.c) set_multicast_list() function. > > Thank you for helping me to narrow it down. > > Jocke You can test multicast easily standalone with iperf: http://dast.nlanr.net/Projects/Iperf/#multicast -- Stephen Hemminger <[EMAIL PROTECTED]> - 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
RE: Multicast problem
> -Original Message- > From: David Stevens [mailto:[EMAIL PROTECTED] > Sent: den 16 oktober 2007 21:46 > To: Joakim Tjernlund > Cc: 'Netdev'; [EMAIL PROTECTED] > Subject: RE: Multicast problem > > > dev_mcast and igmp looks: > > [EMAIL PROTECTED]:/proc/net# m dev_mcast > > 1eth01 0 01005e01 > > 2eth11 0 01005e01 > > These are the hardware multicast addresses for > 224.0.0.1 (so, correct). > > > [EMAIL PROTECTED]:/proc/net# m igmp > > Idx Device: Count Querier GroupUsers > TimerReporter > > 1 eth0 : 1 V3 > > E001 1 0: 0 > > 2 eth1 : 1 V2 > > E001 1 0: 0 > > 4 lo: 0 V3 > > E001 1 0: 0 > > ...and these are the group memberships for 224.0.0.1, so > also correct. This should receive and answer pings to 224.0.0.1 > as long as you don't have ICMP set to ignore broadcasts. You should > not need to put the device in promiscuous mode for a ping of > 224.0.0.1 to work, so if you do, then you have a driver, device > or switch problem. > None of these interfaces have memberships in the OSPF groups, > so if you had OSPF running when you did this, it didn't join. > > +-DLS > OK, so from all this and earlier mail I think that the device driver don't receive multicast pkgs. Tomorrow I will try the real OSPF test case with promisc mode enabled, se if that works. If so, it means there is a bug in the drivers(ucc_geth.c) set_multicast_list() function. Thank you for helping me to narrow it down. Jocke - 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
RE: Multicast problem
> dev_mcast and igmp looks: > [EMAIL PROTECTED]:/proc/net# m dev_mcast > 1eth01 0 01005e01 > 2eth11 0 01005e01 These are the hardware multicast addresses for 224.0.0.1 (so, correct). > [EMAIL PROTECTED]:/proc/net# m igmp > Idx Device: Count Querier GroupUsers TimerReporter > 1 eth0 : 1 V3 > E001 1 0: 0 > 2 eth1 : 1 V2 > E001 1 0: 0 > 4 lo: 0 V3 > E001 1 0: 0 ...and these are the group memberships for 224.0.0.1, so also correct. This should receive and answer pings to 224.0.0.1 as long as you don't have ICMP set to ignore broadcasts. You should not need to put the device in promiscuous mode for a ping of 224.0.0.1 to work, so if you do, then you have a driver, device or switch problem. None of these interfaces have memberships in the OSPF groups, so if you had OSPF running when you did this, it didn't join. +-DLS - 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
RE: Multicast problem
> > hmm maybe I misunderstand here, but the we are trying to make OSPF work > in 2.6 and the problem appears to be that our board does not pick up > multicasts. > Is icmp_echo_ignore_broadcasts=0 required to make OSPF work in 2.6? > > Jocke > No, it's required to make "ping" to a multicast address work, which is what your mail said was the problem. :-) "ping" uses ICMP, OSPF does not. If you receive ping responses with ignore_broadcasts=0 and not in promiscuous mode, then the problem may be a smart switch that doesn't understand IGMPv3. In that case, you can try: sysctl -w net.ipv4.conf.all.force_igmp_version=2 You can also, of course, check /proc/net/igmp and /proc/net/dev_mcast to make sure you've joined the OSPF multicast address on the interface(s) you care about. +-DLS - 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
RE: Multicast problem
> -Original Message- > From: David Stevens [mailto:[EMAIL PROTECTED] > Sent: den 16 oktober 2007 19:05 > To: [EMAIL PROTECTED] > Cc: Netdev > Subject: Re: Multicast problem > > If you have icmp_echo_ignore_broadcasts set to 1, it won't respond to > multicasts. That should be all you need to do for 224.0.0.1. hmm maybe I misunderstand here, but the we are trying to make OSPF work in 2.6 and the problem appears to be that our board does not pick up multicasts. Is icmp_echo_ignore_broadcasts=0 required to make OSPF work in 2.6? Jocke - 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
RE: Multicast problem
> -Original Message- > From: David Stevens [mailto:[EMAIL PROTECTED] > Sent: den 16 oktober 2007 19:05 > To: [EMAIL PROTECTED] > Cc: Netdev > Subject: Re: Multicast problem > > If you have icmp_echo_ignore_broadcasts set to 1, it won't respond to > multicasts. That should be all you need to do for 224.0.0.1. > > Some smart switches rely on IGMP snooping to determine group > membership, > and some of those don't understand IGMPv3, so if you have no v1 or v2 > queriers > on the network, you can force the IGMP version to be 2 instead of the > default 3 > by using a sysctl. Tried forcing igmp from 3 to 2, didn't help > But that's not the issue for 224.0.0.1, since the > all-hosts group > is not reported via IGMP. > > You might check the contents of /proc/net/igmp and > /proc/net/dev_mcast to dev_mcast and igmp looks: [EMAIL PROTECTED]:/proc/net# m dev_mcast 1eth01 0 01005e01 2eth11 0 01005e01 [EMAIL PROTECTED]:/proc/net# m igmp Idx Device: Count Querier GroupUsers TimerReporter 1 eth0 : 1 V3 E001 1 0: 0 2 eth1 : 1 V2 E001 1 0: 0 4 lo: 0 V3 E001 1 0: 0 I can't tell if that's OK or not. > make > sure they have entries for the group. If so, I'd guess it might be a > driver or device issue. Could it be some missing kernel config? This is a custom board so I could very well miss something I kernel config or user space config. Thanks for your help, if you have any more ideas you are most welcome to share :) Jocke > > +-DLS - 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
Re: Multicast problem
If you have icmp_echo_ignore_broadcasts set to 1, it won't respond to multicasts. That should be all you need to do for 224.0.0.1. Some smart switches rely on IGMP snooping to determine group membership, and some of those don't understand IGMPv3, so if you have no v1 or v2 queriers on the network, you can force the IGMP version to be 2 instead of the default 3 by using a sysctl. But that's not the issue for 224.0.0.1, since the all-hosts group is not reported via IGMP. You might check the contents of /proc/net/igmp and /proc/net/dev_mcast to make sure they have entries for the group. If so, I'd guess it might be a driver or device issue. +-DLS - 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
Multicast problem
I can't get my PowerPC 83xx(eth driver ucc_qeth) board to reply on a multcast ping: ping -t 1 -c 2 224.0.0.1 unless I do ifconfig eth1 promisc and echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts I guess I am missing something, but what? Kernel: 2.6.23 Jocke - 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
