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]

Message-ID: <20201205154529.GO1551@shell.armlinux.org.uk>
Date:   Sat, 5 Dec 2020 15:45:29 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Rasmus Villemoes <rasmus.villemoes@...vas.dk>
Cc:     Vladimir Oltean <vladimir.oltean@....com>,
        Network Development <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>
Subject: Re: vlan_filtering=1 breaks all traffic (was: Re: warnings from MTU
 setting on switch ports)

On Sat, Dec 05, 2020 at 03:49:02PM +0100, Rasmus Villemoes wrote:
> 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.

No. My problem is where the bridge is created _without_ vlan_filtering
enabled, and is subsequently enabled. That caused traffic to stop as
soon as vlan_filtering was enabled.

Note that if the bridge were created with vlan_filtering enabled from
the start, there would be no problem.

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

I'm not sure what 517648c8d1 is - this isn't a mainline or net-next
commit ID.

54a0ed0df496 is a modification by Vladimir Oltean of my original patch
("net: dsa: mv88e6xxx: fix vlan setup") that fixed it for Marvell DSA,
dropping the Marvell DSA bits of the patch, thereby neutering it for
its intended purpose, while still mostly maintaining the commit
description which implies that it fixes Marvell DSA.

I'm afraid that I've now given up dealing with anything that involves
interaction with the impossible Vladimir Oltean - the problems you are
experiencing are a direct result of Vladimir Oltean's attitudes towards
fellow kernel developers.

You will, however, find that the problem was subsequently fixed by
1fb74191988f on top of 54a0ed0df496, which adds the part that
Vladimir Oltean failed to carry forward. It's all an unnecessary
horrible mess.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!