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: <trinity-7c2af652-d3f8-4086-ba12-85cd18cd6a1a-1674304362789@3c-app-gmx-bap60>
Date:   Sat, 21 Jan 2023 13:32:42 +0100
From:   Frank Wunderlich <frank-w@...lic-files.de>
To:     Vladimir Oltean <olteanv@...il.com>
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: Aw: Re: [BUG] vlan-aware bridge breaks vlan on another port on same
 gmac

> Gesendet: Samstag, 21. Januar 2023 um 13:22 Uhr
> Von: "Vladimir Oltean" <olteanv@...il.com>
>
> On Sat, Jan 21, 2023 at 01:11:43PM +0100, Frank Wunderlich wrote:
> > > What happens in mt7530_port_vlan_filtering() is that the user port (lan0)
> > > *and* the CPU port become VLAN aware. I guess it is the change on the
> > > CPU port that affects the traffic to "wan".
> >
> > interesting, and funny to see that vlan_aware on gmac is added, but not removed in else branch :p
>
> it is... see "if (all_user_ports_removed)" in mt7530_port_set_vlan_unaware().
>
> > > If this works, I expect it will break VLAN tagged traffic over lan0 now :)
> > > So I would then like you to remove the first patch and try the next one
> >
> > tried first patch, and wan stays working, now i try to figure out how i can access the vlan in the bridge to set ip-address..
> >
> > ip link del vlan110 #delete vlan-interface from wan to have clean routing
> > bridge vlan add vid 110 dev lan0
> > bridge vlan add vid 110 dev lanbr0 self
> >
> > how can i now set ip-address to the vlan110 (imho need to extract the vlan as separate netdev) for testing that lan0 still works?
>
> ip link add link lanbr0 name lanbr0.110 type vlan id 110

thanks found it already ;)

found out how to get access to the vlan from the bridge and it is still working

> If this works, I expect it will break VLAN tagged traffic over lan0 now :)
> So I would then like you to remove the first patch and try the next one

> tried first patch, and wan stays working, now i try to figure out how i can access the vlan in the bridge to set ip-address..

> ip link del vlan110 #delete vlan-interface from wan to have clean routing
> bridge vlan add vid 110 dev lan0
> bridge vlan add vid 110 dev lanbr0 self

> how can i now set ip-address to the vlan110 (imho need to extract the vlan as separate netdev) for testing that lan0 still works?

root@...-r3:~# ip link add link lanbr0 name lanbr0.100 type vlan id 110
root@...-r3:~# ip a a 192.168.110.5/24 dev lanbr0.100
root@...-r3:~# ip link set lanbr0.100 up

did "ping" and look at the remote side

root@...nk-G5:~# tcpdump -i enp3s0 -nn -e vlan
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp3s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:20:39.908845 96:3f:c5:84:65:f0 > e4:b9:7a:f7:c4:8b, ethertype 802.1Q (0x8100), length 102: vlan 110, p 0, ethertype IPv4 (0x0800), 192.168.110.5 > 192.168.110.3: ICMP echo request, id 48077, seq 1, length 64
13:20:39.908878 e4:b9:7a:f7:c4:8b > 96:3f:c5:84:65:f0, ethertype 802.1Q (0x8100), length 102: vlan 110, p 0, ethertype IPv4 (0x0800), 192.168.110.3 > 192.168.110.5: ICMP echo reply, id 48077, seq 1, length 64

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

regards Frank

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ