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.
