netdev - 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 15:49:02 +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: vlan_filtering=1 breaks all traffic (was: Re: warnings from MTU
 setting on switch ports)

On 30/11/2020 23.13, Rasmus Villemoes wrote:
> On 30/11/2020 17.04, Vladimir Oltean wrote:

> Thanks, but I don't think that will change anything. -34 is -ERANGE.
>> But you might also want to look into adding .ndo_change_mtu for
>> ucc_geth. 
> 
> Well, that was what I first did, but I'm incapable of making sense of
> the QE reference manual. Perhaps, given the domain of your email
> address, you could poke someone that might know what would need to be done?
> 
> In any case, something else seems to be broken with 5.9; no network
> traffic seems to be working (but the bridge creation etc. seems to work
> just the same, link status works, and "ip link show" shows the same
> things as in 4.19). So until I figure that out I can't play around with
> modifying ucc_geth.

So, I found out that the problem disappers when I disable
vlan_filtering, and googling then led me to Russell's patches from
around March
(https://patchwork.ozlabs.org/project/netdev/cover/20200218114515.GL18808@shell.armlinux.org.uk/).

But, unlike from what I gather from Russell's description, the problem
is there whether or not the bridge is created with vlan_filtering
enabled from the outset or not. Also, cherry-picking 517648c8d1 to
5.9.12 doesn't help. The problem also exists on 5.4.80, and (somewhat
naively) backporting 54a0ed0df496 as well as 517648c8d1 doesn't change that.

So I'm out of ideas. I also tried booting a 5.3, but that had some
horrible UBI/nand failure, 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?

Rasmus