mv88e6xxx / MV88E6176 + VLAN-aware unusable in 5.15.98 (ok in 5.10.168) (resend)

netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed

* mv88e6xxx / MV88E6176 + VLAN-aware unusable in 5.15.98 (ok in 5.10.168) (resend)
@ 2023-03-12  5:41 Etienne Champetier
  2023-03-12 12:11 ` Tobias Waldekranz
  2023-03-13 22:30 ` Vladimir Oltean
  0 siblings, 2 replies; 7+ messages in thread
From: Etienne Champetier @ 2023-03-12  5:41 UTC (permalink / raw)
  To: Vladimir Oltean, Tobias Waldekranz, Linux Netdev List

(properly formatted this time)

Hello Vladimir, Tobias,

Sending this email to both of you as reverting some of your patches 'fix' the issues I'm seeing.
I'm slowly investigating a regression in OpenWrt going from 22.03 (5.10.168 + some backports)
to current master (5.15.98 + some backports). Using my Turris Omnia (MV88E6176) with the following network config:

# bridge vlan
port              vlan-id
lan0              6 PVID Egress Untagged
lan1              5 PVID Egress Untagged
lan2              4 PVID Egress Untagged
lan3              3 PVID Egress Untagged
lan4              2 PVID Egress Untagged
br-lan            2
                   3
                   4
                   5
                   6
wlan1             3 PVID Egress Untagged
wlan1-1           5 PVID Egress Untagged
wlan1-2           6 PVID Egress Untagged
wlan0             2 PVID Egress Untagged

I get tagged frame with VID 3 on lan4 (at least some multicast & broadcast), but lan4 is not a member of VLAN 3
Also unicast frames from wifi to lan4 exit tagged with VID 2, broadcast frames are fine (verifed with scapy)
Reverting
5bded8259ee3 "net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports" from Vladimir
and
b80dc51b72e2 "net: dsa: mv88e6xxx: Only allow LAG offload on supported hardware"
57e661aae6a8 "net: dsa: mv88e6xxx: Link aggregation support"
from Tobias allow me to get back to 5.10 behavior / working system.

On the OpenWrt side, 5.15 is the latest supported kernel, so I was not able to try more recent for now.

I'm happy to try to backport any patches that can help fix or narrow down the issue, or provide more infos / tests results.

These issues affect other devices using mv88e6xxx: https://github.com/openwrt/openwrt/issues/11877
In the Github issue the reporter note that first packet is not tagged and the following are.

Here a diff of "mv88e6xxx_dump --vtu --ports --global1 --global2" between 5.10 and 5.15 (without revert)

@@ -9,18 +9,18 @@
  05 Port control 1         0000 0000 0000 0000 0000 0000 0000
  06 Port base VLAN map     007e 007d 007b 0077 006f 005f 003f
  07 Def VLAN ID & Prio     0006 0005 0004 0003 0002 0000 0000
-08 Port control 2         0c80 0c80 0c80 0c80 0c80 1080 2080
+08 Port control 2         0c80 0c80 0c80 0c80 0c80 1080 1080
  09 Egress rate control    0001 0001 0001 0001 0001 0001 0001
  0a Egress rate control 2  0000 0000 0000 0000 0000 0000 0000
-0b Port association vec   1001 1002 1004 1008 1010 1000 1000
+0b Port association vec   1001 1002 1004 1008 1010 1020 1040
  0c Port ATU control       0000 0000 0000 0000 0000 0000 0000
  0d Override               0000 0000 0000 0000 0000 0000 0000
  0e Policy control         0000 0000 0000 0000 0000 0000 0000
  0f Port ether type        9100 9100 9100 9100 9100 dada dada
  10 In discard low         0000 0000 0000 0000 0000 0000 0000
  11 In discard high        0000 0000 0000 0000 0000 0000 0000
-12 In filtered            0000 0000 0000 0000 0000 0000 0000
-13 RX frame count         0000 0000 0000 008c 0000 021a 0000
+12 In filtered            0000 0000 0000 0003 0000 0000 0000
+13 RX frame count         0000 0000 0000 008e 0000 04dd 0000
  14 Reserved               0000 0000 0000 0000 0000 0000 0000
  15 Reserved               0000 0000 0000 0000 0000 0000 0000
  16 LED control            0000 0000 0000 0000 0000 0000 0000
@@ -39,22 +39,23 @@
  	T - a member, egress tagged
  	X - not a member, Ingress frames with VID discarded
  P  VID 0123456  FID  SID QPrio FPrio VidPolicy
-0    1 XXXXXVV    1    0     -     -     0
-0    2 XXXXUVV    6    0     -     -     0
-0    3 XXXUXVV    5    0     -     -     0
-0    4 XXUXXVV    4    0     -     -     0
-0    5 XUXXXVV    3    0     -     -     0
-0    6 UXXXXVV    2    0     -     -     0
+0    1 XXXXXVV    2    0     -     -     0
+0    2 XXXXUVV    7    0     -     -     0
+0    3 XXXUXVV    6    0     -     -     0
+0    4 XXUXXVV    5    0     -     -     0
+0    5 XUXXXVV    4    0     -     -     0
+0    6 UXXXXVV    3    0     -     -     0
+0 4095 UUUUUVV    1    0     -     -     0
  Global1:
  00 Global status                    c814
-01 ATU FID                          0006
-02 VTU FID                          0002
+01 ATU FID                          0007
+02 VTU FID                          0001
  03 VTU SID                          0000
  04 Global control                   40a8
-05 VTU operations                   4000
-06 VTU VID                          0fff
-07 VTU/STU Data 0-3                 3331
-08 VTU/STU Data 4-6                 0303
+05 VTU operations                   4043
+06 VTU VID                          1fff
+07 VTU/STU Data 0-3                 1111
+08 VTU/STU Data 4-6                 0111
  09 Reserved                         0000
  0a ATU control                      0149
  0b ATU operations                   4000
@@ -90,10 +91,10 @@
  08 Trunk mapping                    7800
  09 Ingress rate command             1600
  0a Ingress rate data                0000
-0b Cross chip port VLAN addr        31ff
-0c Cross chip port VLAN data        0000
-0d Switch MAC/WoL/WoF               05c5
-0e ATU Stats                        000f
+0b Cross chip port VLAN addr        3010
+0c Cross chip port VLAN data        007f
+0d Switch MAC/WoL/WoF               05fe
+0e ATU Stats                        001f
  0f Priority override table          0f00
  10 Reserved                         0000
  11 Reserved                         0000

Thanks in advance
Etienne


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: mv88e6xxx / MV88E6176 + VLAN-aware unusable in 5.15.98 (ok in 5.10.168) (resend)
  2023-03-12  5:41 mv88e6xxx / MV88E6176 + VLAN-aware unusable in 5.15.98 (ok in 5.10.168) (resend) Etienne Champetier
@ 2023-03-12 12:11 ` Tobias Waldekranz
  2023-03-13  3:13   ` Etienne Champetier
  2023-03-13 22:30 ` Vladimir Oltean
  1 sibling, 1 reply; 7+ messages in thread
From: Tobias Waldekranz @ 2023-03-12 12:11 UTC (permalink / raw)
  To: Etienne Champetier, Vladimir Oltean, Linux Netdev List

On sön, mar 12, 2023 at 00:41, Etienne Champetier <champetier.etienne@gmail.com> wrote:
> (properly formatted this time)
>
> Hello Vladimir, Tobias,
>
> Sending this email to both of you as reverting some of your patches 'fix' the issues I'm seeing.
> I'm slowly investigating a regression in OpenWrt going from 22.03 (5.10.168 + some backports)
> to current master (5.15.98 + some backports). Using my Turris Omnia (MV88E6176) with the following network config:
>
> # bridge vlan
> port              vlan-id
> lan0              6 PVID Egress Untagged
> lan1              5 PVID Egress Untagged
> lan2              4 PVID Egress Untagged
> lan3              3 PVID Egress Untagged
> lan4              2 PVID Egress Untagged
> br-lan            2
>                    3
>                    4
>                    5
>                    6
> wlan1             3 PVID Egress Untagged
> wlan1-1           5 PVID Egress Untagged
> wlan1-2           6 PVID Egress Untagged
> wlan0             2 PVID Egress Untagged
>
> I get tagged frame with VID 3 on lan4 (at least some multicast & broadcast), but lan4 is not a member of VLAN 3

Are these packets being sent to the CPU with a FORWARD tag or TO_CPU? If
it is the latter, what is the CPU_CODE set to? Better yet, could you
post some output from `tcpdump -Q in -evnli <YOUR-DSA-INTERFACE>`?

> Also unicast frames from wifi to lan4 exit tagged with VID 2, broadcast frames are fine (verifed with scapy)

If you're capturing on the lan4 interface, this is to be expected.

When forwarding offloading is enabled. In order for the tag driver to
generate the correct DSA tag, we need to know to which VLAN the packet
belongs (there could be more than one VLAN configured to egress
untagged). Since a FORWARD tag is (should be) generated, the switch will
handle the stripping of the VLAN tag for untagged members.

If you tcpdump at the DSA interface, are the packet sent to the switch
with a FORWARD tag or FROM_CPU?

> Reverting
> 5bded8259ee3 "net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports" from Vladimir
> and
> b80dc51b72e2 "net: dsa: mv88e6xxx: Only allow LAG offload on supported hardware"
> 57e661aae6a8 "net: dsa: mv88e6xxx: Link aggregation support"
> from Tobias allow me to get back to 5.10 behavior / working system.
>
> On the OpenWrt side, 5.15 is the latest supported kernel, so I was not able to try more recent for now.
>
> I'm happy to try to backport any patches that can help fix or narrow down the issue, or provide more infos / tests results.
>
> These issues affect other devices using mv88e6xxx: https://github.com/openwrt/openwrt/issues/11877
> In the Github issue the reporter note that first packet is not tagged and the following are.
>
> Here a diff of "mv88e6xxx_dump --vtu --ports --global1 --global2" between 5.10 and 5.15 (without revert)
>
> @@ -9,18 +9,18 @@
>   05 Port control 1         0000 0000 0000 0000 0000 0000 0000
>   06 Port base VLAN map     007e 007d 007b 0077 006f 005f 003f
>   07 Def VLAN ID & Prio     0006 0005 0004 0003 0002 0000 0000
> -08 Port control 2         0c80 0c80 0c80 0c80 0c80 1080 2080
> +08 Port control 2         0c80 0c80 0c80 0c80 0c80 1080 1080
>   09 Egress rate control    0001 0001 0001 0001 0001 0001 0001
>   0a Egress rate control 2  0000 0000 0000 0000 0000 0000 0000
> -0b Port association vec   1001 1002 1004 1008 1010 1000 1000
> +0b Port association vec   1001 1002 1004 1008 1010 1020 1040
>   0c Port ATU control       0000 0000 0000 0000 0000 0000 0000
>   0d Override               0000 0000 0000 0000 0000 0000 0000
>   0e Policy control         0000 0000 0000 0000 0000 0000 0000
>   0f Port ether type        9100 9100 9100 9100 9100 dada dada
>   10 In discard low         0000 0000 0000 0000 0000 0000 0000
>   11 In discard high        0000 0000 0000 0000 0000 0000 0000
> -12 In filtered            0000 0000 0000 0000 0000 0000 0000
> -13 RX frame count         0000 0000 0000 008c 0000 021a 0000
> +12 In filtered            0000 0000 0000 0003 0000 0000 0000
> +13 RX frame count         0000 0000 0000 008e 0000 04dd 0000
>   14 Reserved               0000 0000 0000 0000 0000 0000 0000
>   15 Reserved               0000 0000 0000 0000 0000 0000 0000
>   16 LED control            0000 0000 0000 0000 0000 0000 0000
> @@ -39,22 +39,23 @@
>   	T - a member, egress tagged
>   	X - not a member, Ingress frames with VID discarded
>   P  VID 0123456  FID  SID QPrio FPrio VidPolicy
> -0    1 XXXXXVV    1    0     -     -     0
> -0    2 XXXXUVV    6    0     -     -     0
> -0    3 XXXUXVV    5    0     -     -     0
> -0    4 XXUXXVV    4    0     -     -     0
> -0    5 XUXXXVV    3    0     -     -     0
> -0    6 UXXXXVV    2    0     -     -     0
> +0    1 XXXXXVV    2    0     -     -     0
> +0    2 XXXXUVV    7    0     -     -     0
> +0    3 XXXUXVV    6    0     -     -     0
> +0    4 XXUXXVV    5    0     -     -     0
> +0    5 XUXXXVV    4    0     -     -     0
> +0    6 UXXXXVV    3    0     -     -     0
> +0 4095 UUUUUVV    1    0     -     -     0
>   Global1:
>   00 Global status                    c814
> -01 ATU FID                          0006
> -02 VTU FID                          0002
> +01 ATU FID                          0007
> +02 VTU FID                          0001
>   03 VTU SID                          0000
>   04 Global control                   40a8
> -05 VTU operations                   4000
> -06 VTU VID                          0fff
> -07 VTU/STU Data 0-3                 3331
> -08 VTU/STU Data 4-6                 0303
> +05 VTU operations                   4043
> +06 VTU VID                          1fff
> +07 VTU/STU Data 0-3                 1111
> +08 VTU/STU Data 4-6                 0111
>   09 Reserved                         0000
>   0a ATU control                      0149
>   0b ATU operations                   4000
> @@ -90,10 +91,10 @@
>   08 Trunk mapping                    7800
>   09 Ingress rate command             1600
>   0a Ingress rate data                0000
> -0b Cross chip port VLAN addr        31ff
> -0c Cross chip port VLAN data        0000
> -0d Switch MAC/WoL/WoF               05c5
> -0e ATU Stats                        000f
> +0b Cross chip port VLAN addr        3010
> +0c Cross chip port VLAN data        007f
> +0d Switch MAC/WoL/WoF               05fe
> +0e ATU Stats                        001f
>   0f Priority override table          0f00
>   10 Reserved                         0000
>   11 Reserved                         0000
>
> Thanks in advance
> Etienne

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: mv88e6xxx / MV88E6176 + VLAN-aware unusable in 5.15.98 (ok in 5.10.168) (resend)
  2023-03-12 12:11 ` Tobias Waldekranz
@ 2023-03-13  3:13   ` Etienne Champetier
  0 siblings, 0 replies; 7+ messages in thread
From: Etienne Champetier @ 2023-03-13  3:13 UTC (permalink / raw)
  To: Tobias Waldekranz; +Cc: Linux Netdev List, Vladimir Oltean


Le 12/03/2023 à 08:11, Tobias Waldekranz a écrit :
> On sön, mar 12, 2023 at 00:41, Etienne Champetier 
> <champetier.etienne@gmail.com> wrote:
>> (properly formatted this time)
>>
>> Hello Vladimir, Tobias,
>>
>> Sending this email to both of you as reverting some of your patches 
>> 'fix' the issues I'm seeing.
>> I'm slowly investigating a regression in OpenWrt going from 22.03 
>> (5.10.168 + some backports)
>> to current master (5.15.98 + some backports). Using my Turris Omnia 
>> (MV88E6176) with the following network config:
>>
>> # bridge vlan
>> port vlan-id
>> lan0 6 PVID Egress Untagged
>> lan1 5 PVID Egress Untagged
>> lan2 4 PVID Egress Untagged
>> lan3 3 PVID Egress Untagged
>> lan4 2 PVID Egress Untagged
>> br-lan 2
>> 3
>> 4
>> 5
>> 6
>> wlan1 3 PVID Egress Untagged
>> wlan1-1 5 PVID Egress Untagged
>> wlan1-2 6 PVID Egress Untagged
>> wlan0 2 PVID Egress Untagged
>>
>> I get tagged frame with VID 3 on lan4 (at least some multicast & 
>> broadcast), but lan4 is not a member of VLAN 3
> Are these packets being sent to the CPU with a FORWARD tag or TO_CPU? If
> it is the latter, what is the CPU_CODE set to? Better yet, could you
> post some output from `tcpdump -Q in -evnli <YOUR-DSA-INTERFACE>`?

To clear out some possible confusion, I capturing on a laptop connected 
to lan4, not using `tcpdump -i lan4`

On the router,
root@turris:~# tcpdump -Q out -evnli eth1
tcpdump: listening on eth1, link-type DSA_TAG_EDSA (Marvell EDSA), 
snapshot length 262144 bytes
02:26:36.735092 c8:4a:a0:b7:1e:d7 > 33:33:00:01:00:02, Marvell EDSA 
ethertype 0xdada (Unknown), rsvd 0 0, mode Forward, dev 1, port 0, 
tagged, VID 3, FPri 0, ethertype IPv6 (0x86dd), length 118: ...
02:26:38.524915 ca:d0:2c:4f:ed:bb > 01:00:5e:7f:ff:fa, Marvell EDSA 
ethertype 0xdada (Unknown), rsvd 0 0, mode Forward, dev 1, port 0, 
tagged, VID 2, FPri 0, ethertype IPv4 (0x0800), length 175: ...
02:26:38.825569 ca:d0:2c:4f:ed:bb > 01:00:5e:7f:ff:fa, Marvell EDSA 
ethertype 0xdada (Unknown), rsvd 0 0, mode Forward, dev 1, port 0, 
tagged, VID 2, FPri 0, ethertype IPv4 (0x0800), length 175: ...
02:26:39.124409 ca:d0:2c:4f:ed:bb > 01:00:5e:7f:ff:fa, Marvell EDSA 
ethertype 0xdada (Unknown), rsvd 0 0, mode Forward, dev 1, port 0, 
tagged, VID 2, FPri 0, ethertype IPv4 (0x0800), length 175: ...
02:26:40.186939 d8:58:d7:00:4e:39 > ff:ff:ff:ff:ff:ff, Marvell EDSA 
ethertype 0xdada (Unknown), rsvd 0 0, mode Forward, dev 1, port 0, 
tagged, VID 3, FPri 0, ethertype ARP (0x0806), length 50: ...
02:26:41.218401 d8:58:d7:00:4e:39 > ff:ff:ff:ff:ff:ff, Marvell EDSA 
ethertype 0xdada (Unknown), rsvd 0 0, mode Forward, dev 1, port 0, 
tagged, VID 3, FPri 0, ethertype ARP (0x0806), length 50: ...
02:26:42.258393 d8:58:d7:00:4e:39 > ff:ff:ff:ff:ff:ff, Marvell EDSA 
ethertype 0xdada (Unknown), rsvd 0 0, mode Forward, dev 1, port 0, 
tagged, VID 3, FPri 0, ethertype ARP (0x0806), length 50: ...

On the laptop

[root@echampetier ~]# tcpdump -evnli enp0s31f6 -Q in
dropped privs to tcpdump
tcpdump: listening on enp0s31f6, link-type EN10MB (Ethernet), snapshot 
length 262144 bytes
22:26:36.757382 c8:4a:a0:b7:1e:d7 > 33:33:00:01:00:02, ethertype 802.1Q 
(0x8100), length 114: vlan 3, p 0, ethertype IPv6 (0x86dd), ...
22:26:38.547328 ca:d0:2c:4f:ed:bb > 01:00:5e:7f:ff:fa, ethertype IPv4 
(0x0800), length 167: ...
22:26:38.847746 ca:d0:2c:4f:ed:bb > 01:00:5e:7f:ff:fa, ethertype IPv4 
(0x0800), length 167: ...
22:26:39.146702 ca:d0:2c:4f:ed:bb > 01:00:5e:7f:ff:fa, ethertype IPv4 
(0x0800), length 167: ...
22:26:40.209365 d8:58:d7:00:4e:39 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
(0x8100), length 60: vlan 3, p 0, ethertype ARP (0x0806), ...
22:26:41.240603 d8:58:d7:00:4e:39 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
(0x8100), length 60: vlan 3, p 0, ethertype ARP (0x0806), ...
22:26:42.280428 d8:58:d7:00:4e:39 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q 
(0x8100), length 60: vlan 3, p 0, ethertype ARP (0x0806), ...


>> Also unicast frames from wifi to lan4 exit tagged with VID 2, 
>> broadcast frames are fine (verifed with scapy)
> If you're capturing on the lan4 interface, this is to be expected.

As clarified, I'm capturing on a laptop connected to lan4

> When forwarding offloading is enabled. In order for the tag driver to
> generate the correct DSA tag, we need to know to which VLAN the packet
> belongs (there could be more than one VLAN configured to egress
> untagged). Since a FORWARD tag is (should be) generated, the switch will
> handle the stripping of the VLAN tag for untagged members.
>
> If you tcpdump at the DSA interface, are the packet sent to the switch
> with a FORWARD tag or FROM_CPU?

If the dst mac is not in `bridge fdb` / the ATU, frame arrives untagged 
(as they should)
root@turris:~# tcpdump -Q out -evnli eth1
tcpdump: listening on eth1, link-type DSA_TAG_EDSA (Marvell EDSA), 
snapshot length 262144 bytes
02:39:02.835931 44:85:00:cf:86:45 > ff:ff:ff:ff:ff:ff, Marvell EDSA 
ethertype 0xdada (Unknown), rsvd 0 0, mode Forward, dev 1, port 0, 
tagged, VID 2, FPri 0, ethertype ARP (0x0806), length 50: Ethernet (len 
6), IPv4 (len 4), Request who-has 5.6.7.8 tell 1.2.3.4, length 28
02:39:04.089792 44:85:00:cf:86:45 > 50:7b:9d:f0:06:4e, Marvell EDSA 
ethertype 0xdada (Unknown), rsvd 0 0, mode Forward, dev 1, port 0, 
tagged, VID 2, FPri 0, ethertype ARP (0x0806), length 50: Ethernet (len 
6), IPv4 (len 4), Request who-has 5.6.7.8 tell 1.2.3.4, length 28
[root@echampetier ~]# tcpdump -evnnli enp0s31f6 -Q in
tcpdump: listening on enp0s31f6, link-type EN10MB (Ethernet), snapshot 
length 262144 bytes
22:39:02.859622 44:85:00:cf:86:45 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 
5.6.7.8 tell 1.2.3.4, length 46
22:39:04.113555 44:85:00:cf:86:45 > 50:7b:9d:f0:06:4e, ethertype ARP 
(0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 
5.6.7.8 tell 1.2.3.4, length 46

If the dst is not silent / present in `bridge fdb` / the ATU
root@turris:~# bridge fdb | grep ^50
50:7b:9d:f0:06:4e dev lan4 vlan 2 master br-lan
50:7b:9d:f0:06:4e dev lan4 vlan 2 self
(I see some entries with offload, not this one)

root@turris:~# mv88e6xxx_dump --atu
FID MAC T 0123456 Prio State
7 50:7b:9d:f0:06:4e 00001000000 0 Age 7

then we have
02:47:13.427645 44:85:00:cf:86:45 > ff:ff:ff:ff:ff:ff, Marvell EDSA 
ethertype 0xdada (Unknown), rsvd 0 0, mode Forward, dev 1, port 0, 
tagged, VID 2, FPri 0, ethertype ARP (0x0806), length 50: Ethernet (len 
6), IPv4 (len 4), Request who-has 5.6.7.8 tell 1.2.3.4, length 28
02:47:14.409168 44:85:00:cf:86:45 > 50:7b:9d:f0:06:4e, Marvell EDSA 
ethertype 0xdada (Unknown), rsvd 0 0, mode From CPU, target dev 0, port 
4, tagged, VID 2, FPri 0, ethertype ARP (0x0806), length 50: Ethernet 
(len 6), IPv4 (len 4), Request who-has 5.6.7.8 tell 1.2.3.4, length 28
02:47:15.383509 44:85:00:cf:86:45 > ff:ff:ff:ff:ff:ff, Marvell EDSA 
ethertype 0xdada (Unknown), rsvd 0 0, mode Forward, dev 1, port 0, 
tagged, VID 2, FPri 0, ethertype ARP (0x0806), length 50: Ethernet (len 
6), IPv4 (len 4), Request who-has 5.6.7.8 tell 1.2.3.4, length 28

22:47:13.440691 44:85:00:cf:86:45 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 
5.6.7.8 tell 1.2.3.4, length 46
22:47:14.422167 44:85:00:cf:86:45 > 50:7b:9d:f0:06:4e, ethertype 802.1Q 
(0x8100), length 60: vlan 2, p 0, ethertype ARP (0x0806), Ethernet (len 
6), IPv4 (len 4), Request who-has 5.6.7.8 tell 1.2.3.4, length 42
22:47:15.396450 44:85:00:cf:86:45 > ff:ff:ff:ff:ff:ff, ethertype ARP 
(0x0806), length 60: Ethernet (len 6), IPv4 (len 4), Request who-has 
5.6.7.8 tell 1.2.3.4, length 46


>> Reverting
>> 5bded8259ee3 "net: dsa: mv88e6xxx: isolate the ATU databases of 
>> standalone and bridged ports" from Vladimir
>> and
>> b80dc51b72e2 "net: dsa: mv88e6xxx: Only allow LAG offload on 
>> supported hardware"
>> 57e661aae6a8 "net: dsa: mv88e6xxx: Link aggregation support"
>> from Tobias allow me to get back to 5.10 behavior / working system.
>>
>> On the OpenWrt side, 5.15 is the latest supported kernel, so I was 
>> not able to try more recent for now.
>>
>> I'm happy to try to backport any patches that can help fix or narrow 
>> down the issue, or provide more infos / tests results.
>>
>> These issues affect other devices using mv88e6xxx: 
>> https://github.com/openwrt/openwrt/issues/11877
>> In the Github issue the reporter note that first packet is not tagged 
>> and the following are.
>>
>> Here a diff of "mv88e6xxx_dump --vtu --ports --global1 --global2" 
>> between 5.10 and 5.15 (without revert)
>>
>> @@ -9,18 +9,18 @@
>> 05 Port control 1 0000 0000 0000 0000 0000 0000 0000
>> 06 Port base VLAN map 007e 007d 007b 0077 006f 005f 003f
>> 07 Def VLAN ID & Prio 0006 0005 0004 0003 0002 0000 0000
>> -08 Port control 2 0c80 0c80 0c80 0c80 0c80 1080 2080
>> +08 Port control 2 0c80 0c80 0c80 0c80 0c80 1080 1080
>> 09 Egress rate control 0001 0001 0001 0001 0001 0001 0001
>> 0a Egress rate control 2 0000 0000 0000 0000 0000 0000 0000
>> -0b Port association vec 1001 1002 1004 1008 1010 1000 1000
>> +0b Port association vec 1001 1002 1004 1008 1010 1020 1040
>> 0c Port ATU control 0000 0000 0000 0000 0000 0000 0000
>> 0d Override 0000 0000 0000 0000 0000 0000 0000
>> 0e Policy control 0000 0000 0000 0000 0000 0000 0000
>> 0f Port ether type 9100 9100 9100 9100 9100 dada dada
>> 10 In discard low 0000 0000 0000 0000 0000 0000 0000
>> 11 In discard high 0000 0000 0000 0000 0000 0000 0000
>> -12 In filtered 0000 0000 0000 0000 0000 0000 0000
>> -13 RX frame count 0000 0000 0000 008c 0000 021a 0000
>> +12 In filtered 0000 0000 0000 0003 0000 0000 0000
>> +13 RX frame count 0000 0000 0000 008e 0000 04dd 0000
>> 14 Reserved 0000 0000 0000 0000 0000 0000 0000
>> 15 Reserved 0000 0000 0000 0000 0000 0000 0000
>> 16 LED control 0000 0000 0000 0000 0000 0000 0000
>> @@ -39,22 +39,23 @@
>> T - a member, egress tagged
>> X - not a member, Ingress frames with VID discarded
>> P VID 0123456 FID SID QPrio FPrio VidPolicy
>> -0 1 XXXXXVV 1 0 - - 0
>> -0 2 XXXXUVV 6 0 - - 0
>> -0 3 XXXUXVV 5 0 - - 0
>> -0 4 XXUXXVV 4 0 - - 0
>> -0 5 XUXXXVV 3 0 - - 0
>> -0 6 UXXXXVV 2 0 - - 0
>> +0 1 XXXXXVV 2 0 - - 0
>> +0 2 XXXXUVV 7 0 - - 0
>> +0 3 XXXUXVV 6 0 - - 0
>> +0 4 XXUXXVV 5 0 - - 0
>> +0 5 XUXXXVV 4 0 - - 0
>> +0 6 UXXXXVV 3 0 - - 0
>> +0 4095 UUUUUVV 1 0 - - 0
>> Global1:
>> 00 Global status c814
>> -01 ATU FID 0006
>> -02 VTU FID 0002
>> +01 ATU FID 0007
>> +02 VTU FID 0001
>> 03 VTU SID 0000
>> 04 Global control 40a8
>> -05 VTU operations 4000
>> -06 VTU VID 0fff
>> -07 VTU/STU Data 0-3 3331
>> -08 VTU/STU Data 4-6 0303
>> +05 VTU operations 4043
>> +06 VTU VID 1fff
>> +07 VTU/STU Data 0-3 1111
>> +08 VTU/STU Data 4-6 0111
>> 09 Reserved 0000
>> 0a ATU control 0149
>> 0b ATU operations 4000
>> @@ -90,10 +91,10 @@
>> 08 Trunk mapping 7800
>> 09 Ingress rate command 1600
>> 0a Ingress rate data 0000
>> -0b Cross chip port VLAN addr 31ff
>> -0c Cross chip port VLAN data 0000
>> -0d Switch MAC/WoL/WoF 05c5
>> -0e ATU Stats 000f
>> +0b Cross chip port VLAN addr 3010
>> +0c Cross chip port VLAN data 007f
>> +0d Switch MAC/WoL/WoF 05fe
>> +0e ATU Stats 001f
>> 0f Priority override table 0f00
>> 10 Reserved 0000
>> 11 Reserved 0000
>>
>> Thanks in advance
>> Etienne

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: mv88e6xxx / MV88E6176 + VLAN-aware unusable in 5.15.98 (ok in 5.10.168) (resend)
  2023-03-12  5:41 mv88e6xxx / MV88E6176 + VLAN-aware unusable in 5.15.98 (ok in 5.10.168) (resend) Etienne Champetier
  2023-03-12 12:11 ` Tobias Waldekranz
@ 2023-03-13 22:30 ` Vladimir Oltean
  2023-03-15  2:35   ` Etienne Champetier
  1 sibling, 1 reply; 7+ messages in thread
From: Vladimir Oltean @ 2023-03-13 22:30 UTC (permalink / raw)
  To: Etienne Champetier; +Cc: Tobias Waldekranz, Linux Netdev List

Hi Etienne,

On Sun, Mar 12, 2023 at 12:41:32AM -0500, Etienne Champetier wrote:
> I get tagged frame with VID 3 on lan4 (at least some multicast & broadcast), but lan4 is not a member of VLAN 3
> Also unicast frames from wifi to lan4 exit tagged with VID 2, broadcast frames are fine (verifed with scapy)
> Reverting
> 5bded8259ee3 "net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports" from Vladimir
> and
> b80dc51b72e2 "net: dsa: mv88e6xxx: Only allow LAG offload on supported hardware"
> 57e661aae6a8 "net: dsa: mv88e6xxx: Link aggregation support"
> from Tobias allow me to get back to 5.10 behavior / working system.
> 
> On the OpenWrt side, 5.15 is the latest supported kernel, so I was not able to try more recent for now.

I don't know and I am not able to reproduce this on Turris MOX with a linux-5.15.y
kernel from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git.

Could we approach this from the other end? I would like to try and
reproduce the issue with the kernel you are using. But I have no idea
how to use OpenWRT or to navigate through its build system. Could you
help me figure out which source code is built for the Omnia board (plus
additional OpenWRT patches, if any)?

I might also ask you to provide a reproducer for the issue using regular
iproute2 tools starting from an unconfigured system (bridge, ip, etc, as
opposed to the network manager from OpenWRT and its /etc/config/network
configuration file), if this wouldn't be too much effort.

Also, not clear which interface exactly you mean by "wifi" ("unicast
frames from wifi to lan4 exit tagged with VID 2").

Thanks.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: mv88e6xxx / MV88E6176 + VLAN-aware unusable in 5.15.98 (ok in 5.10.168) (resend)
  2023-03-13 22:30 ` Vladimir Oltean
@ 2023-03-15  2:35   ` Etienne Champetier
  2023-03-15  9:23     ` Vladimir Oltean
  0 siblings, 1 reply; 7+ messages in thread
From: Etienne Champetier @ 2023-03-15  2:35 UTC (permalink / raw)
  To: Vladimir Oltean; +Cc: Tobias Waldekranz, Linux Netdev List


Le 13/03/2023 à 18:30, Vladimir Oltean a écrit :
> Hi Etienne,
>
> On Sun, Mar 12, 2023 at 12:41:32AM -0500, Etienne Champetier wrote:
>> I get tagged frame with VID 3 on lan4 (at least some multicast & broadcast), but lan4 is not a member of VLAN 3
>> Also unicast frames from wifi to lan4 exit tagged with VID 2, broadcast frames are fine (verifed with scapy)
>> Reverting
>> 5bded8259ee3 "net: dsa: mv88e6xxx: isolate the ATU databases of standalone and bridged ports" from Vladimir
>> and
>> b80dc51b72e2 "net: dsa: mv88e6xxx: Only allow LAG offload on supported hardware"
>> 57e661aae6a8 "net: dsa: mv88e6xxx: Link aggregation support"
>> from Tobias allow me to get back to 5.10 behavior / working system.
>>
>> On the OpenWrt side, 5.15 is the latest supported kernel, so I was not able to try more recent for now.
> I don't know and I am not able to reproduce this on Turris MOX with a linux-5.15.y
> kernel fromhttps://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git.
>
> Could we approach this from the other end? I would like to try and
> reproduce the issue with the kernel you are using. But I have no idea
> how to use OpenWRT or to navigate through its build system. Could you
> help me figure out which source code is built for the Omnia board (plus
> additional OpenWRT patches, if any)?

OpenWrt doesn't support Turris Mox, but here is what is built for Omnia 
as far as I understand

- Linux 5.15.98: 
https://github.com/openwrt/openwrt/blob/0aedf916df364771be47ffda8ff3465250ecee77/include/kernel-5.15

- some generic patches (backport-5.15 / pending-5.15 / hack-5.15): 
https://github.com/openwrt/openwrt/tree/0aedf916df364771be47ffda8ff3465250ecee77/target/linux/generic

- some arch specific patches: 
https://github.com/openwrt/openwrt/tree/0aedf916df364771be47ffda8ff3465250ecee77/target/linux/mvebu/patches-5.15

(not 100% sure in what order they are applied)

- config is generated by taking config-5.15 in generic, mvebu and 
mvebu/cortexa9 and somehow merging them

The wifi code (mac80211 / ath10k) uses kernel backports, so it's 
actually 6.1-rc8 based 
https://github.com/openwrt/openwrt/blob/0aedf916df364771be47ffda8ff3465250ecee77/package/kernel/mac80211/Makefile


While writting this I stumbled upon 
https://github.com/openwrt/openwrt/blob/master/target/linux/generic/hack-5.15/600-bridge_offload.patch,

reverting it fixes half of the problem (frame tagged that should be 
untagged), but I still see frames with VID 3 on a port that is not a 
member of VLAN 3.

I'll continue to look at 'hack' and old 'pending' patches that were 
never accepted,

and loop back with the author of the bridge_offload patch.


> I might also ask you to provide a reproducer for the issue using regular
> iproute2 tools starting from an unconfigured system (bridge, ip, etc, as
> opposed to the network manager from OpenWRT and its /etc/config/network
> configuration file), if this wouldn't be too much effort.

I don't have a serial cable right now, but if reverting suspicious patches

is not enough I'll likely go down that route.


> Also, not clear which interface exactly you mean by "wifi" ("unicast
> frames from wifi to lan4 exit tagged with VID 2").

wifi interface here would be wlan0 / bridged to vlan2

> Thanks.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: mv88e6xxx / MV88E6176 + VLAN-aware unusable in 5.15.98 (ok in 5.10.168) (resend)
  2023-03-15  2:35   ` Etienne Champetier
@ 2023-03-15  9:23     ` Vladimir Oltean
  2023-03-16 15:40       ` Marek Behún
  0 siblings, 1 reply; 7+ messages in thread
From: Vladimir Oltean @ 2023-03-15  9:23 UTC (permalink / raw)
  To: Etienne Champetier; +Cc: Tobias Waldekranz, Linux Netdev List

On Tue, Mar 14, 2023 at 10:35:25PM -0400, Etienne Champetier wrote:
> OpenWrt doesn't support Turris Mox, but here is what is built for Omnia as
> far as I understand
> 
> - Linux 5.15.98: https://github.com/openwrt/openwrt/blob/0aedf916df364771be47ffda8ff3465250ecee77/include/kernel-5.15
> 
> - some generic patches (backport-5.15 / pending-5.15 / hack-5.15): https://github.com/openwrt/openwrt/tree/0aedf916df364771be47ffda8ff3465250ecee77/target/linux/generic
> 
> - some arch specific patches: https://github.com/openwrt/openwrt/tree/0aedf916df364771be47ffda8ff3465250ecee77/target/linux/mvebu/patches-5.15
> 
> (not 100% sure in what order they are applied)
> 
> - config is generated by taking config-5.15 in generic, mvebu and
> mvebu/cortexa9 and somehow merging them
> 
> The wifi code (mac80211 / ath10k) uses kernel backports, so it's actually
> 6.1-rc8 based https://github.com/openwrt/openwrt/blob/0aedf916df364771be47ffda8ff3465250ecee77/package/kernel/mac80211/Makefile

Yo, that's quite the patch count.

Would you mind putting for me all the patches that apply for your Omnia
build to a git branch that you share here? It's impossible to find the
needle in the haystack like this.

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: mv88e6xxx / MV88E6176 + VLAN-aware unusable in 5.15.98 (ok in 5.10.168) (resend)
  2023-03-15  9:23     ` Vladimir Oltean
@ 2023-03-16 15:40       ` Marek Behún
  0 siblings, 0 replies; 7+ messages in thread
From: Marek Behún @ 2023-03-16 15:40 UTC (permalink / raw)
  To: Vladimir Oltean, Etienne Champetier; +Cc: Tobias Waldekranz, Linux Netdev List

On Wed, 15 Mar 2023 11:23:40 +0200
Vladimir Oltean <vladimir.oltean@nxp.com> wrote:

> On Tue, Mar 14, 2023 at 10:35:25PM -0400, Etienne Champetier wrote:
> > OpenWrt doesn't support Turris Mox, but here is what is built for Omnia as
> > far as I understand
> > 
> > - Linux 5.15.98: https://github.com/openwrt/openwrt/blob/0aedf916df364771be47ffda8ff3465250ecee77/include/kernel-5.15
> > 
> > - some generic patches (backport-5.15 / pending-5.15 / hack-5.15): https://github.com/openwrt/openwrt/tree/0aedf916df364771be47ffda8ff3465250ecee77/target/linux/generic
> > 
> > - some arch specific patches: https://github.com/openwrt/openwrt/tree/0aedf916df364771be47ffda8ff3465250ecee77/target/linux/mvebu/patches-5.15
> > 
> > (not 100% sure in what order they are applied)
> > 
> > - config is generated by taking config-5.15 in generic, mvebu and
> > mvebu/cortexa9 and somehow merging them
> > 
> > The wifi code (mac80211 / ath10k) uses kernel backports, so it's actually
> > 6.1-rc8 based https://github.com/openwrt/openwrt/blob/0aedf916df364771be47ffda8ff3465250ecee77/package/kernel/mac80211/Makefile  
> 
> Yo, that's quite the patch count.
> 
> Would you mind putting for me all the patches that apply for your Omnia
> build to a git branch that you share here? It's impossible to find the
> needle in the haystack like this.

Or maybe Etienne can try to reproduce the issue with upstream kernel?
Building upstream kernel for Omnia and using it with OpenWRT / TurrisOS
does work, I am doing it all the time. Just take /proc/config.gz, put
it into .config of upstream Linux source, and then in make menuconfig
enable wifi drivers (since OpenWRT uses backports). You will get a
zImage which you can just replace in /boot. The modules you should put
in /lib/modules/KERNELRELEASE (all *.ko files directly in this
directory, without the directory structure created by make
modules_install). Basically

  On omnia:
    zcat /proc/config.gz
  and copy the output to linux/.config
  In linux/
    ARCH=arm CROSS_COMPILE=arm-none-eabi- make menuconfig
  enable wifi drivers in menuconfig and then
    ARCH=arm CROSS_COMPILE=arm-none-eabi- KERNELRELEASE=6.3-rc2 \
      make zImage
  copy arch/arm/boot/zImage to omnia /boot
    ARCH=arm CROSS_COMPILE=arm-none-eabi- KERNELRELEASE=6.3-rc2 \
      make modules
    ARCH=arm CROSS_COMPILE=arm-none-eabi- KERNELRELEASE=6.3-rc2 \
      make modules_install INSTALL_MOD_PATH=MODS
    mkdir MODS_FOR_OPENWRT
    find MODS -name '*.ko' -exec mv {} MODS_FOR_OPENWRT \;
    rm -rf MODS
  and copy the *.ko files from directory MODS_FOR_OPENWRT to omnia,
  directory /lib/modules/6.3-rc2

Marek

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2023-03-16 15:51 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-12  5:41 mv88e6xxx / MV88E6176 + VLAN-aware unusable in 5.15.98 (ok in 5.10.168) (resend) Etienne Champetier
2023-03-12 12:11 ` Tobias Waldekranz
2023-03-13  3:13   ` Etienne Champetier
2023-03-13 22:30 ` Vladimir Oltean
2023-03-15  2:35   ` Etienne Champetier
2023-03-15  9:23     ` Vladimir Oltean
2023-03-16 15:40       ` Marek Behún

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).