lkml.org 
[lkml]   [2018]   [Dec]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: iMX6 FEC driver Linux-fslc 4.17 - IPV6 Multicast not working when unplugging/plugging ethernet cable
Date
Le 12/27/18 à 6:21 AM, Stefano Cappa a écrit :
> Hi everyone,
> I already posted this in NXP forum as a comment
> (https://community.nxp.com/thread/359397), in yocto mailing list
> (https://lists.yoctoproject.org/pipermail/yocto/2018-December/043664.html)
> and in meta-freescale mailing list
> (https://lists.yoctoproject.org/pipermail/meta-freescale/2018-December/023625.html)
> A user in meta-freescale's mailing list suggested to resend this
> message to the emails obtained running "./scripts/get_maintainer.pl -F
> drivers/net/ethernet/freescale/fec_main.c".
>
>
> The problem is:
>
> If I boot my iMX6 device with ethernet cable attached and I execute "ping6
> ff02::fb" to ping the multicast address I get this response:
> ~# ping6 ff02::fb
> PING ff02::fb (ff02::fb): 56 data bytes
> 64 bytes from fe80::c2f:eff:fe11:2d71: seq=0 ttl=64 time=2.057 ms
> 64 bytes from fe80::809:1bfb:8d4c:ae54: seq=0 ttl=64 time=73.101 ms (DUP!)
> 64 bytes from fe80::3e28:6dff:feed:5b97: seq=0 ttl=64 time=150.772 ms
> (DUP!)
>
>
> Otherwise, If I unplug and plug again ethernet cable, I cannot ping the
> multicast ipv6 address anymore.
> The result is:
> ~# ping6 ff02::fb
> PING ff02::fb (ff02::fb): 56 data bytes
> ping6: sendto: Network is unreachable
>
>
> The original NXP discussion was about older version of Linux, however
> this issue is happening with both Linux 4.9.88 and Linux 4.17.
> Probably also with the latest version, but I didn't try.
>
>
> Do you have any suggestions? Is this a bug? This is really a
> frustrating and I'm really
> surprised to see the same problem also on Linux 4.17.

All multicast filter programming would occur from within the
set_multicast_list() function. At first glance, there are several things
that could be wrong:

- hash is only 6 bits, and written across a pair of 32-bit registers, so
that would leave only 10 unique multicast address entries if I
understand correctly how the hardware is designed

- if we are exceeding the maximum number of unique hash values/bit
positions then the interface should be put in promiscuous mode to allow
the reception of all traffic, and multicast filtering needs to be done
in software (very few drivers get this right)

I would instrument that function and see what is happening in there at
the time of failure.

>
>
> PS: I'm sorry for the double email, but the previous one was in html
> and it was rejected.
>
> Thank u.
>


--
Florian

\
 
 \ /
  Last update: 2018-12-28 02:15    [W:0.048 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site