lists.openwall.net   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  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:   Sat, 14 Nov 2020 20:49:15 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     "Tj (Elloe Linux)" <ml.linux@...oe.vision>
Cc:     netdev@...r.kernel.org, chris.packham@...iedtelesis.co.nz,
        andrew@...n.ch, f.fainelli@...il.com, marek.behun@....cz,
        vivien.didelot@...il.com, info <info@...ris.cz>
Subject: Re: dsa: mv88e6xxx not receiving IPv6 multicast packets

On Sat, Nov 14, 2020 at 03:39:28PM +0000, Tj (Elloe Linux) wrote:
> MV88E6085 switch not passing IPv6 multicast packets to CPU.
>
> Seems to be related to interface not being in promiscuous mode.
>
> This issue has been ongoing since at least July 2020. Latest v5.10-rc3
> still suffers the issue on a Turris Mox with mv88e6085. We've not been
> able to reproduce it on the Turris v4.14 stable kernel series so it
> appears to be a regression.
>
> Mox is using Debian 10 Buster.
>
> First identified due to DHCPv6 leases not being renewed on clients being
> served by isc-dhcp-server on the Mox.
>
> Analysis showed the client IPv6 multicast solicit packets were being
> received by the Mox hardware (proved via a mirror port on a managed LAN
> switch) but the CPU was not receiving them (observed using tcpdump).
>
> Further investigation has identified this also affects IPv6 neighbour
> discovery for clients when not using frequent RAs from the Mox.
>
> Currently we've found two reproducible scenarios:
>
> 1) with isc-dhcp-server configured with very short lease times (180
> seconds). After mox reboot (or systemctl restart systemd-networkd)
> clients successfully obtain a lease and a couple of RENEWs (requested
> after 90 seconds) but then all goes silent, Mox OS no longer sees the
> IPv6 multicast RENEW packets and client leases expire.
>
> 2) Immediately after reboot when DHCPv6 renewals are still possible if
> on the Mox we do "tcdump -ni eth1 ip6" and immediately terminate,
> tcpdump takes the interface out of promiscuous mode and IPv6 multicast
> packets immediately cease to be received by the CPU. If we use 'tcpdump
> --no-promiscuous-mode ..." so on termination it doesn't try to take the
> interface out of promiscuous mode IPv6 multicast packets continue to be
> seen by the CPU.
>
> We've been pointed to the mv8e6xxx_dump tool and can capture data but
> not sure what specifically to look for.
>
> We've also added some pr_info() debugging into mvneta to analyse when
> promiscuous mode is enabled or disabled since this seems to be strongly
> related to the issue.
>
> We believe there's a big clue in being able to reset the issue by
> restarting systemd-networkd on the Mox. We've looked for but not found
> any clues or indications of services on the Mox causing this but aren't
> ruling this out.

Is there a simple step-by-step reproducer for the issue, that doesn't
require a lot of configuration? I've got a Mox with the 6190 switch
running net-next and Buildroot that I could try on.

Powered by blists - more mailing lists