Re: dsa: mv88e6xxx not receiving IPv6 multicast packets

["Tj (Elloe Linux)" <ml.linux@elloe.vision>]

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.