Re: vlan_filtering=1 breaks all traffic

[Vladimir Oltean <vladimir.oltean@nxp.com>]

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.