On Sat, Dec 05, 2020 at 09:13:37PM +0100, Rasmus Villemoes wrote: > Yup, that corresponds pretty much to what I do. Just for good measure, I > tried doing exactly the above (with only a change in IP address), and... > it worked. So, first thought was "perhaps it's because you bring up br0 > before adding the ports". But no, bringing it up after still works. > Second thought: "portS - hm, only one port is added here", and indeed, > once I add two or more ports to the bridge, it stops working. Removing > all but the single port that has a cable plugged in makes it work again. > It doesn't seem to matter whether the other ports are up or down. > > I should probably mention that wireshark says that ARP (ipv4) and > neighbor solicitation (ipv6ll) packets do reach my laptop when I attempt > the ping. If I start by doing a succesful ping (i.e., no other ports > added), then add another port, then do a ping, the ping packets do reach > the laptop (and of course get answered). So the problem does not appear > to be on egress.
It would be interesting to see what is the ingress drop reason, if that could be deduced from the drop counters that are incrementing in ethtool -S. I am not confident that it can be a VTU issue, given the fact that you have not said that you see VTU violation warnings, which are fairly loud on mv88e6xxx. The procedure of joining a new port to the bridge does alter the VTU, since that second port needs to be a part of the default_pvid of the bridge as soon as it goes up (VID 1). However that is not the main thing that bridging a new port does - instead, the in-chip Port VLAN map is altered. In theory it _would_ be possible (even if unlikely) for the VTU to get overwritten by the second port join, in a way that removes the first port from the bridge's VID 1. Remember that this issue only seems to be observable on 8250, so it seems logical to search in 8250 specific code first (therefore making the VTU a more likely suspect than the in-chip Port VLAN map). Since you've already made the effort to boot kernel 5.9, you could make the extra leap to try out the 5.10 rc's and look at the VTU using Andrew's devlink based tool: https://github.com/lunn/mv88e6xxx_dump # devlink dev mdio_bus/d0032004.mdio-mii:11 mdio_bus/d0032004.mdio-mii:12 mdio_bus/d0032004.mdio-mii:10 # ./mv88e6xxx_dump --device mdio_bus/d0032004.mdio-mii:10 --vtu VTU: V - a member, egress not modified U - a member, egress untagged T - a member, egress tagged X - not a member, Ingress frames with VID discarded P VID 0123456789a FID SID QPrio FPrio VidPolicy # ip link add br0 type bridge vlan_filtering 1 # ip link set lan4 master br0 [ 74.443547] br0: port 1(lan4) entered blocking state [ 74.446037] br0: port 1(lan4) entered disabled state [ 74.461416] device lan4 entered promiscuous mode [ 74.463564] device eth1 entered promiscuous mode # ./mv88e6xxx_dump --device mdio_bus/d0032004.mdio-mii:10 --vtu VTU: V - a member, egress not modified U - a member, egress untagged T - a member, egress tagged X - not a member, Ingress frames with VID discarded P VID 0123456789a FID SID QPrio FPrio VidPolicy 0 1 XXXXUXXXXVV 1 0 - - 0 # ip link set lan5 master br0 [ 84.533120] br0: port 2(lan5) entered blocking state [ 84.535563] br0: port 2(lan5) entered disabled state [ 84.552022] device lan5 entered promiscuous mode # # ./mv88e6xxx_dump --device mdio_bus/d0032004.mdio-mii:10 --vtu VTU: V - a member, egress not modified U - a member, egress untagged T - a member, egress tagged X - not a member, Ingress frames with VID discarded P VID 0123456789a FID SID QPrio FPrio VidPolicy 0 1 XXXXUUXXXVV 1 0 - - 0 You would expect to see two U's for your ports, and not something else like X.
