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 for Android: free password hash cracker in your pocket
[<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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ