lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Thu, 27 Dec 2018 17:14:12 -0800
From:   Florian Fainelli <>
To:     Stefano Cappa <>,,,,
Cc:     Andrew Lunn <>,
        Vivien Didelot <>
Subject: Re: iMX6 FEC driver Linux-fslc 4.17 - IPV6 Multicast not working when
 unplugging/plugging ethernet cable

Le 12/27/18 à 6:21 AM, Stefano Cappa a écrit :
> Hi everyone,
> I already posted this in NXP forum as a comment
> (, in yocto mailing list
> (
> and in meta-freescale mailing list
> (
> A user in meta-freescale's mailing list suggested to resend this
> message to the emails obtained running "./scripts/ -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.


Powered by blists - more mailing lists