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

Powered by blists - more mailing lists