Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
Message-ID: <trinity-7c2af652-d3f8-4086-ba12-85cd18cd6a1a-1674304362789@3c-app-gmx-bap60>
From:   Frank Wunderlich <frank-w@public-files.de>
To:     Vladimir Oltean <olteanv@gmail.com>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Landen Chao <Landen.Chao@mediatek.com>,
        Sean Wang <sean.wang@mediatek.com>,
        DENG Qingfang <dqfext@gmail.com>,
        Matthias Brugger <matthias.bgg@gmail.com>,
        Daniel Golle <daniel@makrotopia.org>
Subject: Aw: Re: [BUG] vlan-aware bridge breaks vlan on another port on same
 gmac
Content-Type: text/plain; charset=UTF-8
Date:   Sat, 21 Jan 2023 13:32:42 +0100
Importance: normal
Sensitivity: Normal
In-Reply-To: <20230121122223.3kfcwxqtqm3b6po5@skbuf>
References: <trinity-e6294d28-636c-4c40-bb8b-b523521b00be-1674233135062@3c-app-gmx-bs36>
 <20230120172132.rfo3kf4fmkxtw4cl@skbuf>
 <trinity-b0df6ff8-cceb-4aa5-a26f-41bc04dc289c-1674303103108@3c-app-gmx-bap60>
 <20230121122223.3kfcwxqtqm3b6po5@skbuf>
UI-OutboundReport: notjunk:1;M01:P0:V7elQmlp5QU=;Bo6zAsBDpPtn0ABb8sb5fe/C81J
 SUbn0TQ0eG18/+HqKhoJ2pmfUfgVkhAl23msUNARujaiixteOO6YAreNBX1QfV6tlgnjWQ33M
 4FiZHBgNbnzle7YLPmqtBPy1PcSbykfK5Vbh1K0fpUgCnWEfEeiHv4gB6o3vJQVwZT0NG8HWJ
 e2k4RcNlYglnMZa5MgNgdoOioNTvDV7SQi8cVXKi8AdvJMq953bPvERbed5Hvlz1lWb7RTaj6
 W2D01jgLNbOuSoCXiFfcyV0TSW5LkYZ3OgM2mefUZJ0njEj4cdNqnzl7xmPI6gZ3UFLoI+D/s
 rzro4/SBr8V9DAeWazrBaYAm+pAvL+4joPYqpyN5+TevioZrG36c31ZaFppXEBnp6A5hzmyyg
 Sp2z1hA9ifgq+J90RAw6MO78o3lrApjIOZI9wHEVoh8EXUwKXCjuB8vIC+MKZop9M8Fn6KEsK
 Uv1ZhcCnxTdY51PS601T+B1p4MGgHteq//EGdvivnsBGGxkBf3tDlaXclpwM80vPZ42/BR/tU
 Esrg6G+IyEeGP9tSbjF7X6P9hDTDMwbM85oxqpq8oeYqyiHYQOOCpaOrSJetiW0ZFiFfG/NJB
 YKSh0BZJce8EYlEFyC+phvmGmeo3kK21mkNZW4ckXSYXgf/s0TATSUAbmnojQoRW0D0aOvU6d
 Uxyutb8xNJ/WRcmr+4a5wZOsLsXaIQG/vxVCdmZHcyUxTEhNqrITm24mLaZR0pdzzOv7AivYm
 pSQiYUWjFpZh7AUnuj2q44Zg31daeZoBflw8vuBgZ/EO2xPNSGBsVFyNEFQYeu1JTqSSMUhuW
 ovwESZEH4dDFMnSDMenFMfjcyl7dVHSziYEXNS1s0Wdpk=
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

> Gesendet: Samstag, 21. Januar 2023 um 13:22 Uhr
> Von: "Vladimir Oltean" <olteanv@gmail.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 th=
e
> > > CPU port that affects the traffic to "wan".
> >
> > interesting, and funny to see that vlan_aware on gmac is added, but no=
t removed in else branch :p
>
> it is... see "if (all_user_ports_removed)" in mt7530_port_set_vlan_unawa=
re().
>
> > > 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 rout=
ing
> > 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 wo=
rking

> 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 routin=
g
> 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 vl=
an as separate netdev) for testing that lan0 still works?

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

did "ping" and look at the remote side

root@frank-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 b=
ytes
13:20:39.908845 96:3f:c5:84:65:f0 > e4:b9:7a:f7:c4:8b, ethertype 802.1Q (0=
x8100), 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 (0=
x8100), 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 n=
eed 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 recei=
ving my laptop (also no untagged ones).

regards Frank