netdev - Re: [BUG] vlan-aware bridge breaks vlan on another port on same gmac

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: <20230121133549.vibz2infg5jwupdc@skbuf>
Date:   Sat, 21 Jan 2023 15:35:49 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Frank Wunderlich <frank-w@...lic-files.de>
Cc:     Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Landen Chao <Landen.Chao@...iatek.com>,
        Sean Wang <sean.wang@...iatek.com>,
        DENG Qingfang <dqfext@...il.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Daniel Golle <daniel@...rotopia.org>
Subject: Re: [BUG] vlan-aware bridge breaks vlan on another port on same gmac

On Sat, Jan 21, 2023 at 01:32:42PM +0100, Frank Wunderlich wrote:
> so first patch fixes the behaviour on bpi-r3 (mt7531)...but maybe mt7530 need the tagging on cpu-port
> 
> > Can you try the second patch instead of the first one? Without digging
> > deeply into mt7530 hardware docs, that's the best chance of making
> > things work without changing how the hardware operates.
> 
> second patch works for wan, but vlan on bridge is broken, no packets receiving my laptop (also no untagged ones).

It's hard for me to understand how applying only patch "tag_mtk only
combine VLAN tag with MTK tag is user port is VLAN aware" can produce
the results you describe... For packets sent to port lan0, nothing
should have been changed by that patch, because dsa_port_is_vlan_filtering(dp)
should return true.

If you can confirm there isn't any mistake in the testing procedure,
I'll take a look later today at the hardware documentation and try to
figure out why the CPU port is configured the way it is.