Multicast problem

Multicast problem

[Joakim Tjernlund]

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

Re: Multicast problem

[David Stevens]

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

RE: Multicast problem

[Joakim Tjernlund]

> -----Original Message-----
> From: David Stevens [mailto:dlstevens@us.ibm.com] 
> Sent: den 16 oktober 2007 19:05
> To: joakim.tjernlund@transmode.se
> 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:
root@Challenger:/proc/net# m dev_mcast
1    eth0            1     0     01005e000001
2    eth1            1     0     01005e000001

root@Challenger:/proc/net# m igmp
Idx     Device    : Count Querier       Group    Users Timer    Reporter
1       eth0      :     1      V3
                                E0000001     1 0:00000000               0
2       eth1      :     1      V2
                                E0000001     1 0:00000000               0
4       lo        :     0      V3
                                E0000001     1 0:00000000               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

RE: Multicast problem

[Joakim Tjernlund]

> -----Original Message-----
> From: David Stevens [mailto:dlstevens@us.ibm.com] 
> Sent: den 16 oktober 2007 19:05
> To: joakim.tjernlund@transmode.se
> 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

RE: Multicast problem

[David Stevens]

> 
> 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

RE: Multicast problem

[David Stevens]

> dev_mcast and igmp looks:
> root@Challenger:/proc/net# m dev_mcast
> 1    eth0            1     0     01005e000001
> 2    eth1            1     0     01005e000001

        These are the hardware multicast addresses for
224.0.0.1 (so, correct).

> root@Challenger:/proc/net# m igmp
> Idx     Device    : Count Querier       Group    Users Timer    Reporter
> 1       eth0      :     1      V3
>                                 E0000001     1 0:00000000 0
> 2       eth1      :     1      V2
>                                 E0000001     1 0:00000000 0
> 4       lo        :     0      V3
>                                 E0000001     1 0:00000000 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

RE: Multicast problem

[Joakim Tjernlund]

> -----Original Message-----
> From: David Stevens [mailto:dlstevens@us.ibm.com] 
> Sent: den 16 oktober 2007 21:46
> To: Joakim Tjernlund
> Cc: 'Netdev'; netdev-owner@vger.kernel.org
> Subject: RE: Multicast problem
> 
> > dev_mcast and igmp looks:
> > root@Challenger:/proc/net# m dev_mcast
> > 1    eth0            1     0     01005e000001
> > 2    eth1            1     0     01005e000001
> 
>         These are the hardware multicast addresses for
> 224.0.0.1 (so, correct).
> 
> > root@Challenger:/proc/net# m igmp
> > Idx     Device    : Count Querier       Group    Users 
> Timer    Reporter
> > 1       eth0      :     1      V3
> >                                 E0000001     1 0:00000000 0
> > 2       eth1      :     1      V2
> >                                 E0000001     1 0:00000000 0
> > 4       lo        :     0      V3
> >                                 E0000001     1 0:00000000 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

Re: Multicast problem

[Stephen Hemminger]

On Tue, 16 Oct 2007 22:07:35 +0200
"Joakim Tjernlund" <joakim.tjernlund@transmode.se> wrote:

> > -----Original Message-----
> > From: David Stevens [mailto:dlstevens@us.ibm.com] 
> > Sent: den 16 oktober 2007 21:46
> > To: Joakim Tjernlund
> > Cc: 'Netdev'; netdev-owner@vger.kernel.org
> > Subject: RE: Multicast problem
> > 
> > > dev_mcast and igmp looks:
> > > root@Challenger:/proc/net# m dev_mcast
> > > 1    eth0            1     0     01005e000001
> > > 2    eth1            1     0     01005e000001
> > 
> >         These are the hardware multicast addresses for
> > 224.0.0.1 (so, correct).
> > 
> > > root@Challenger:/proc/net# m igmp
> > > Idx     Device    : Count Querier       Group    Users 
> > Timer    Reporter
> > > 1       eth0      :     1      V3
> > >                                 E0000001     1 0:00000000 0
> > > 2       eth1      :     1      V2
> > >                                 E0000001     1 0:00000000 0
> > > 4       lo        :     0      V3
> > >                                 E0000001     1 0:00000000 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 <shemminger@linux-foundation.org>

RE: Multicast problem

[Joakim Tjernlund]

> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@linux-foundation.org] 
> Sent: den 16 oktober 2007 22:13
> 
> On Tue, 16 Oct 2007 22:07:35 +0200
> "Joakim Tjernlund" <joakim.tjernlund@transmode.se> wrote:
> 
> > > -----Original Message-----
> > > From: David Stevens [mailto:dlstevens@us.ibm.com] 
> > > Sent: den 16 oktober 2007 21:46
> > > To: Joakim Tjernlund
> > > Cc: 'Netdev'; netdev-owner@vger.kernel.org
> > > Subject: RE: Multicast problem
> > > 
> > > > dev_mcast and igmp looks:
> > > > root@Challenger:/proc/net# m dev_mcast
> > > > 1    eth0            1     0     01005e000001
> > > > 2    eth1            1     0     01005e000001
> > > 
> > >         These are the hardware multicast addresses for
> > > 224.0.0.1 (so, correct).
> > > 
> > > > root@Challenger:/proc/net# m igmp
> > > > Idx     Device    : Count Querier       Group    Users 
> > > Timer    Reporter
> > > > 1       eth0      :     1      V3
> > > >                                 E0000001     1 0:00000000 0
> > > > 2       eth1      :     1      V2
> > > >                                 E0000001     1 0:00000000 0
> > > > 4       lo        :     0      V3
> > > >                                 E0000001     1 0:00000000 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.

RE: Multicast problem

[Joakim Tjernlund]

 
> > > 
> > > 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