netdev - Re: vlan_filtering=1 breaks all traffic (was: Re: warnings from MTU setting on switch ports)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 5 Dec 2020 19:03:11 +0000
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>
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 (was: Re: warnings from MTU
 setting on switch ports)

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?

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 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.
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?

So it either is a problem specific to the 6250, 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
# bridge vlan del dev lan4 vid 1
# bridge vlan add dev lan4 vid 100 pvid untagged && bridge vlan add dev br0 vid 100 pvid untagged self
# ping 192.168.100.1
[...]
^C--- 192.168.100.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 0.993/1.358/1.633/0.269 ms