Message-ID: <ecb50a5e-45e5-a6a6-5439-c0b5b60302a9@prevas.dk>
Date:   Sat, 5 Dec 2020 21:13:37 +0100
From:   Rasmus Villemoes <rasmus.villemoes@...vas.dk>
To:     Vladimir Oltean <vladimir.oltean@....com>
Cc:     Network Development <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Russell King - ARM Linux <linux@...linux.org.uk>
Subject: Re: vlan_filtering=1 breaks all traffic

On 05/12/2020 20.03, Vladimir Oltean wrote:
> Hi Rasmus,
> 
> On Sat, Dec 05, 2020 at 03:49:02PM +0100, Rasmus Villemoes wrote:
>> So I'm out of ideas. I also tried booting a 5.3, but that had some
>> horrible UBI/nand failure,
> 
> Test with a ramdisk maybe?
> 
>> and since the mv88e6250 support only landed
>> in 5.3, it's rather difficult to try kernels further back.
>> Does anyone know what might have happened between 4.19 and 5.4 that
>> caused this change in behaviour for Marvell switches?
> 
> I think the most important question is: what commands are you running,
> and how are you determining that "it doesn't work"? What type of traffic
> are you sending, and how are you receiving it?
> 

Ping, ssh, you-name-it. Testing with both IPv4 and IPv6LL.

> I don't own a 6250 switch, but the 6390 and 6190. On my switches, both
> termination and forwarding work fine with VLAN filtering enabled -
> tested just now. This is with the official v5.9 tag:
> 
> commit bbf5c979011a099af5dc76498918ed7df445635b (HEAD, tag: v5.9)
> Author: Linus Torvalds <torvalds@...ux-foundation.org>
> Date:   Sun Oct 11 14:15:50 2020 -0700
> 
>     Linux 5.9
> 
> It's interesting that it is you who added VLAN support for the 6250 

Not just VLAN, all of 6250 was added by me around that time.

in
> commit bec8e5725281 ("net: dsa: mv88e6xxx: implement vtu_getnext and
> vtu_loadpurge for mv88e6250") which appeared around the v5.3 timeframe.
> When you tested it then, did you apply the same test as you did now?
>
> It is very confusing that you mention v4.19, since of course, it is the
> v5.3 tag where the 6250 support for VLANs has appeared, just as you said.

We're running with the set of 6250 patches backported to 4.19, and the
testing was/is done on that. I'd love to be able to run Linus' master
branch at any time, and that's actually what I'm currently in the
process of getting closer to (apart from the switch issue, 5.9 seems to
work just fine for us with just about five out-of-tree patches, none
network-related).

> As far as I can gather from your email, the only kernel where your
> testing passes is a kernel that nobody else can test, am I right?

In a sense, yes, but nobody else has the hardware that I have either.

> So it either is a problem specific to the 6250,

That is certainly a possibility.

 or a problem that I did
> not catch with the trivial setup I had below:
> 
> # uname -a
> Linux buildroot 5.9.0-mox #1526 SMP PREEMPT Sat Dec 5 20:53:11 EET 2020 aarch64 GNU/Linux
> # ip link add br0 type bridge vlan_filtering 1 && ip link set br0 up
> # ip link set lan4 master br0
> [   56.393743] br0: port 1(lan4) entered blocking state
> [   56.396614] br0: port 1(lan4) entered disabled state
> [   56.408327] device lan4 entered promiscuous mode
> [   56.410255] device eth1 entered promiscuous mode
> [   57.155280] br0: port 1(lan4) entered blocking state
> [   57.157639] br0: port 1(lan4) entered forwarding state
> #
> # ip addr add 192.168.100.2/24 dev br0
> # ping 192.168.100.1
> [...]
> --- 192.168.100.1 ping statistics ---
> 18 packets transmitted, 18 received, 0% packet loss, time 17034ms
> rtt min/avg/max/mdev = 1.389/1.643/2.578/0.266 ms

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.

Rasmus

Powered by blists - more mailing lists