netdev - Re: dsa: mv88e6xxx not receiving IPv6 multicast packets

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 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:   Sun, 15 Nov 2020 10:53:00 +0000
From:   "Tj (Elloe Linux)" <ml.linux@...oe.vision>
To:     Vladimir Oltean <olteanv@...il.com>
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 14/11/2020 18:49, Vladimir Oltean wrote:
> On Sat, Nov 14, 2020 at 03:39:28PM +0000, Tj (Elloe Linux) wrote:
>> MV88E6085 switch not passing IPv6 multicast packets to CPU.

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

Our set-up is Mox A (CPU) + G (mini-PCIe) + F (4x USB 3.0) + 3 x E (8
port Marvell switch) + D (SFP cage)

Whilst working on this we've moved one of the E modules to another A CPU
in our lab so as not to mess with the gateway.

Running Debian 10, using systemd-networkd, which configures:

eth0 (WAN) static IPv4 and IPv6 - DHCP=no
eth1 (uplink to the switch ports) DHCP=no
lan1 (connected to external managed switch) Bridge=br-lan
br-lan static IPv4 and IPv6, Kind=bridge, IPForward=true

Whilst we're working on this issue only lan1 is connected to anything
external; a 48-port managed switch. No connection to SPF either.

We assign an IPv6 from our delegated /48 prefix to br-lan and have
isc-dhcp-server configured on a very short lease (180 seconds) to issue
leases.

On a LAN client we request a lease using:

dhclient -d -6 wlp4s0

Usually, if this is started just after the Mox systemd-networkd was
restarted, it'll manage to obtain and then renew a lease about 3 or 4 times.

These will show up in the Mox logs too.

At some point, with absolutely nothing showing in any Mox log in the
meantime, additional renewals will fail.

We later noticed that after this happens sometime later clients on the
network lose IPv6 connectivity to the Mox because neighbour discovery is
also failing - took us a while to spot this because the Mox occasionally
sends RAs at which point the clients can talk to the Mox again. The
symptom here was unexplained random-length 'hangs' of SSH sessions to
the Mox that would affect LAN clients only when the neighbour table
entry had expired.

I'm trying to create a very small reproducer root file-system on the lab
Mox.

Right now I've not been able to reproduce it on the lab unit even with a
clone of the gateway Mox's micro SD-card, but that seems due to it
failing to complete a regular boot - hence creating a fresh root
file-system.