| 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
| ||
|
Date: Mon, 15 Jan 2024 17:37:21 +1300
From: Simon Waterer <simon.waterer@...il.com>
To: netdev@...r.kernel.org
Subject: DSA switch: VLAN tag not added on packets directed to a PVID,untagged switchport
Hello,
I'm using a DSA switch with vlan_filtering enabled.
When tcpdumping on the DSA master interface, and looking at the
packets egressing the Linux host towards the CPU port of the switch,
I'm observing that 802.1q vlan tags are only being added on packets
directed towards a trunk port of the switch. VLAN tags are not being
added on packets directed to a PVID,untagged switchport. The VLAN tags
are seen when tcpdumping the br0 device, but are lost by the time they
reach the DSA master interface. This is an issue as the switch
hardware proceeds to tag the packet with the default VLAN id 1 when
the untagged packet ingresses the switch via the CPU port.
Is this behaviour expected of DSA switch integration with VLANs?
Please may anyone offer a suggestion on what further I may look into
to troubleshoot this issue?
More information:
The DSA switch consists of 2 Microchip LAN9373 switches in cascade mode.
The system is iMX8 running Linux 6.1.36.
The master interface is eth1.
The user ports are labelled afe0, afe1, afe2, etc.
Setup is as follows:
ethtool -K eth1 rx-vlan-offload off # in order to see vlan tags on
eth1 ingress traffic
ip link add br0 type bridge
ip link add link br0 name br0.10 type vlan id 10
ip addr add 192.168.10.1/24 dev br0.10
ip link add link br0 name br0.20 type vlan id 20
ip addr add 192.168.20.1/24 dev br0.20
ip link add link br0 name br0.30 type vlan id 30
ip addr add 192.168.30.1/24 dev br0.30
ip link set dev afe0 master br0
ip link set dev afe1 master br0
ip link set dev br0 type bridge vlan_filtering 1
bridge vlan add dev br0 vid 10 self
bridge vlan add dev br0 vid 20 self
bridge vlan add dev br0 vid 30 self
bridge vlan add vid 10 dev afe0
bridge vlan add vid 30 dev afe0
bridge vlan add vid 20 dev afe0
bridge vlan add vid 30 dev afe1 pvid untagged
ip link set dev br0 up
ip link set dev br0.10 up
ip link set dev br0.20 up
ip link set dev br0.30 up
ip link set dev afe0 up
ip link set dev afe1 up
Example showing expected behaviour:
-----------------------------------
When sending a ping to 192.168.30.1 from another device (IP:
192.168.30.251) that is connected to the tagged port "afe0", behaviour
is as expected:
tcpdump on device sending the ping:
listening on enx00e04c3ff8c2, link-type EN10MB (Ethernet), capture
size 262144 bytes
13:23:37.412278 00:e0:4c:3f:f8:c2 > ff:ff:ff:ff:ff:ff, ethertype
802.1Q (0x8100), length 46: vlan 30, p 0, ethertype ARP, Request
who-has 192.168.30.1 tell 192.168.30.251, length 28
13:23:37.414159 ea:38:5b:06:97:75 > 00:e0:4c:3f:f8:c2, ethertype
802.1Q (0x8100), length 60: vlan 30, p 0, ethertype ARP, Reply
192.168.30.1 is-at ea:38:5b:06:97:75, length 42
13:23:37.414170 00:e0:4c:3f:f8:c2 > ea:38:5b:06:97:75, ethertype
802.1Q (0x8100), length 102: vlan 30, p 0, ethertype IPv4,
192.168.30.251 > 192.168.30.1: ICMP echo request, id 48, seq 1, length
64
13:23:37.415247 ea:38:5b:06:97:75 > 00:e0:4c:3f:f8:c2, ethertype
802.1Q (0x8100), length 102: vlan 30, p 0, ethertype IPv4,
192.168.30.1 > 192.168.30.251: ICMP echo reply, id 48, seq 1, length
64
Here, the ping is successful with the device receiving the ARP
reply and ICMP echo reply with vlan id 30 (as expected).
tcpdump on DSA master interface eth1:
listening on eth1, link-type NULL (BSD loopback), snapshot length
262144 bytes
13:27:46.917763 AF Unknown (4294967295), length 65:
0x0000: ffff 00e0 4c3f f8c2 8100 001e 0806 0001 ....L?..........
0x0010: 0800 0604 0001 00e0 4c3f f8c2 c0a8 1efb ........L?......
0x0020: 0000 0000 0000 c0a8 1e01 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 00 .............
13:27:46.917905 AF Unknown (14699583), length 63:
0x0000: f8c2 ea38 5b06 9775 8100 001e 0806 0001 ...8[..u........
0x0010: 0800 0604 0002 ea38 5b06 9775 c0a8 1e01 .......8[..u....
0x0020: 00e0 4c3f f8c2 c0a8 1efb 0000 0000 0000 ..L?............
0x0030: 0000 0000 0000 0000 2000 01 ...........
13:27:46.918932 AF Unknown (3929561862), length 103:
0x0000: 9775 00e0 4c3f f8c2 8100 001e 0800 4500 .u..L?........E.
0x0010: 0054 022e 4000 4001 7a2e c0a8 1efb c0a8 .T..@.@.........
0x0020: 1e01 0800 28d1 0030 0001 097b a465 0000 ....(..0...{.e..
0x0030: 0000 5c4a 0600 0000 0000 1011 1213 1415 ..\J............
0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$%
0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345
0x0060: 3637 00 67.
13:27:46.919035 AF Unknown (14699583), length 105:
0x0000: f8c2 ea38 5b06 9775 8100 001e 0800 4500 ...8[..u......E.
0x0010: 0054 f562 0000 4001 c6f9 c0a8 1e01 c0a8 .T.b..@.........
0x0020: 1efb 0000 30d1 0030 0001 097b a465 0000 ....0..0...{.e..
0x0030: 0000 5c4a 0600 0000 0000 1011 1213 1415 ..\J............
0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$%
0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345
0x0060: 3637 2000 01 67...
Here, the vlan tag (81 00 00 1e) is shown on both the ingress and
egress packets with expected vid 30 (0x1e).
Here also, the tailtags from/to the switch hardware (tag_ksz) are observed:
- ingress tailtags (the 00 octet at end of ingress packets).
- egress tailtags (the 20 00 01 octets at end of egress packets)
tcpdump on br0:
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:27:46.917815 00:e0:4c:3f:f8:c2 > ff:ff:ff:ff:ff:ff, ethertype
802.1Q (0x8100), length 64: vlan 30, p 0, ethertype ARP (0x0806),
Request who-has 192.168.30.1 tell 192.168.30.251, length 46
13:27:46.917869 ea:38:5b:06:97:75 > 00:e0:4c:3f:f8:c2, ethertype
802.1Q (0x8100), length 46: vlan 30, p 0, ethertype ARP (0x0806),
Reply 192.168.30.1 is-at ea:38:5b:06:97:75, length 28
13:27:46.918945 00:e0:4c:3f:f8:c2 > ea:38:5b:06:97:75, ethertype
802.1Q (0x8100), length 102: vlan 30, p 0, ethertype IPv4 (0x0800),
192.168.30.251 > 192.168.30.1: ICMP echo request, id 48, seq 1, length
64
13:27:46.919016 ea:38:5b:06:97:75 > 00:e0:4c:3f:f8:c2, ethertype
802.1Q (0x8100), length 102: vlan 30, p 0, ethertype IPv4 (0x0800),
192.168.30.1 > 192.168.30.251: ICMP echo reply, id 48, seq 1, length
64
Here, vlan tag IDs have been decoded as the ingress packets passes
up to br0 and same vlan id 30 is shown on the reply packets.
Example showing the erroneous behaviour:
----------------------------------------
But, when connecting the other device to the PVID,untagged port
"afe1", the following is observed:
tcpdump on device sending the ping:
listening on enx00e04c3ff8c2, link-type EN10MB (Ethernet), capture
size 262144 bytes
13:31:23.862699 00:e0:4c:3f:f8:c2 > ff:ff:ff:ff:ff:ff, ethertype
ARP (0x0806), length 42: Request who-has 192.168.30.1 tell
192.168.30.251, length 28
13:31:23.864551 ea:38:5b:06:97:75 > 00:e0:4c:3f:f8:c2, ethertype
802.1Q (0x8100), length 64: vlan 1, p 0, ethertype ARP, Reply
192.168.30.1 is-at ea:38:5b:06:97:75, length 46
13:31:24.890952 00:e0:4c:3f:f8:c2 > ff:ff:ff:ff:ff:ff, ethertype
ARP (0x0806), length 42: Request who-has 192.168.30.1 tell
192.168.30.251, length 28
13:31:24.892810 ea:38:5b:06:97:75 > 00:e0:4c:3f:f8:c2, ethertype
802.1Q (0x8100), length 64: vlan 1, p 0, ethertype ARP, Reply
192.168.30.1 is-at ea:38:5b:06:97:75, length 46
13:31:25.910959 00:e0:4c:3f:f8:c2 > ff:ff:ff:ff:ff:ff, ethertype
ARP (0x0806), length 42: Request who-has 192.168.30.1 tell
192.168.30.251, length 28
13:31:25.912828 ea:38:5b:06:97:75 > 00:e0:4c:3f:f8:c2, ethertype
802.1Q (0x8100), length 64: vlan 1, p 0, ethertype ARP, Reply
192.168.30.1 is-at ea:38:5b:06:97:75, length 46
Here, the reply packet errorneously contains vlan tag for vlan id
1, when it was expected to be untagged-on-egress from the switch, and
was expected to have vlan id 30.
tcpdump on DSA master interface eth1:
listening on eth1, link-type NULL (BSD loopback), snapshot length
262144 bytes
13:35:33.363982 AF Unknown (4294967295), length 65:
0x0000: ffff 00e0 4c3f f8c2 8100 001e 0806 0001 ....L?..........
0x0010: 0800 0604 0001 00e0 4c3f f8c2 c0a8 1efb ........L?......
0x0020: 0000 0000 0000 c0a8 1e01 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 01 .............
13:35:33.364186 AF Unknown (14699583), length 63:
0x0000: f8c2 ea38 5b06 9775 0806 0001 0800 0604 ...8[..u........
0x0010: 0002 ea38 5b06 9775 c0a8 1e01 00e0 4c3f ...8[..u......L?
0x0020: f8c2 c0a8 1efb 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 2000 02 ...........
13:35:34.392257 AF Unknown (4294967295), length 65:
0x0000: ffff 00e0 4c3f f8c2 8100 001e 0806 0001 ....L?..........
0x0010: 0800 0604 0001 00e0 4c3f f8c2 c0a8 1efb ........L?......
0x0020: 0000 0000 0000 c0a8 1e01 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 01 .............
13:35:34.392385 AF Unknown (14699583), length 63:
0x0000: f8c2 ea38 5b06 9775 0806 0001 0800 0604 ...8[..u........
0x0010: 0002 ea38 5b06 9775 c0a8 1e01 00e0 4c3f ...8[..u......L?
0x0020: f8c2 c0a8 1efb 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 2000 02 ...........
13:35:35.412251 AF Unknown (4294967295), length 65:
0x0000: ffff 00e0 4c3f f8c2 8100 001e 0806 0001 ....L?..........
0x0010: 0800 0604 0001 00e0 4c3f f8c2 c0a8 1efb ........L?......
0x0020: 0000 0000 0000 c0a8 1e01 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 0000 0000 01 .............
13:35:35.412384 AF Unknown (14699583), length 63:
0x0000: f8c2 ea38 5b06 9775 0806 0001 0800 0604 ...8[..u........
0x0010: 0002 ea38 5b06 9775 c0a8 1e01 00e0 4c3f ...8[..u......L?
0x0020: f8c2 c0a8 1efb 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 2000 02 ...........
Here, the vlan tag (81 00 00 1e) is *ONLY* present on the *ingress*
packets (the ARP requests), and *ABSENT* from the *egress* packets
(the ARP replies).
Here also, the tailtags from/to the switch hardware (tag_ksz) are
observed and are as expected, this time corresponding to switch-port
"afe1".
tcpdump on br0:
listening on br0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
13:35:33.364069 00:e0:4c:3f:f8:c2 > ff:ff:ff:ff:ff:ff, ethertype
802.1Q (0x8100), length 64: vlan 30, p 0, ethertype ARP (0x0806),
Request who-has 192.168.30.1 tell 192.168.30.251, length 46
13:35:33.364154 ea:38:5b:06:97:75 > 00:e0:4c:3f:f8:c2, ethertype
802.1Q (0x8100), length 46: vlan 30, p 0, ethertype ARP (0x0806),
Reply 192.168.30.1 is-at ea:38:5b:06:97:75, length 28
13:35:34.392307 00:e0:4c:3f:f8:c2 > ff:ff:ff:ff:ff:ff, ethertype
802.1Q (0x8100), length 64: vlan 30, p 0, ethertype ARP (0x0806),
Request who-has 192.168.30.1 tell 192.168.30.251, length 46
13:35:34.392356 ea:38:5b:06:97:75 > 00:e0:4c:3f:f8:c2, ethertype
802.1Q (0x8100), length 46: vlan 30, p 0, ethertype ARP (0x0806),
Reply 192.168.30.1 is-at ea:38:5b:06:97:75, length 28
13:35:35.412300 00:e0:4c:3f:f8:c2 > ff:ff:ff:ff:ff:ff, ethertype
802.1Q (0x8100), length 64: vlan 30, p 0, ethertype ARP (0x0806),
Request who-has 192.168.30.1 tell 192.168.30.251, length 46
13:35:35.412355 ea:38:5b:06:97:75 > 00:e0:4c:3f:f8:c2, ethertype
802.1Q (0x8100), length 46: vlan 30, p 0, ethertype ARP (0x0806),
Reply 192.168.30.1 is-at ea:38:5b:06:97:75, length 28
Here, vlan tag IDs have been decoded as the packet passes up to
br0, and vlan id 30 is present on the replies, yet the vlan tag appear
to be dropped when the packet is sent down from br0 to eth1, as not
visible in the tcpdump of eth1 above.
I have checked and confirmed that "tx-vlan-offload" is "off" for eth1.
Other information:
------------------
root@...8qxp-var-som:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 br0.10
192.168.20.0 0.0.0.0 255.255.255.0 U 0 0 0 br0.20
192.168.30.0 0.0.0.0 255.255.255.0 U 0 0 0 br0.30
root@...8qxp-var-som:~# bridge vlan
port vlan-id
afe0 1 PVID Egress Untagged
10
20
30
afe1 1 Egress Untagged
30 PVID Egress Untagged
afe3 1 Egress Untagged
30 PVID Egress Untagged
afe4 1 Egress Untagged
20 PVID Egress Untagged
afe2 1 Egress Untagged
30 PVID Egress Untagged
afe5 1 Egress Untagged
30 PVID Egress Untagged
afe6 1 Egress Untagged
30 PVID Egress Untagged
afe8 1 Egress Untagged
30 PVID Egress Untagged
afe9 1 Egress Untagged
30 PVID Egress Untagged
afe7 1 Egress Untagged
30 PVID Egress Untagged
br0 1 PVID Egress Untagged
10
20
30
Note: Another observation is that even after running "bridge vlan del
dev afe0 vid 1" or "bridge vlan del dev afe1 vid 1", the entry for
vlan-id 1 never disappears from the ouput of "bridge vlan show"
root@...8qxp-var-som:~# bridge fdb
33:33:00:00:00:01 dev eth0 self permanent
01:00:5e:00:00:01 dev eth0 self permanent
33:33:00:00:00:01 dev eth1 self permanent
01:00:5e:00:00:01 dev eth1 self permanent
f8:dc:7a:bb:54:a1 dev afe0 vlan 20 master br0 permanent
f8:dc:7a:bb:54:a1 dev afe0 vlan 30 master br0 permanent
f8:dc:7a:bb:54:a1 dev afe0 vlan 10 master br0 permanent
f8:dc:7a:bb:54:a1 dev afe0 vlan 1 master br0 permanent
f8:dc:7a:bb:54:a1 dev afe0 master br0 permanent
00:e0:4c:3f:f8:c2 dev afe1 vlan 30 master br0
00:e0:4c:3f:f8:c2 dev afe1 vlan 10 self
00:e0:4c:3f:f8:c2 dev afe1 vlan 20 self
00:e0:4c:3f:f8:c2 dev afe1 vlan 30 self
33:33:00:00:00:01 dev br0 self permanent
01:80:c2:00:00:21 dev br0 self permanent
01:00:5e:00:00:6a dev br0 self permanent
33:33:00:00:00:6a dev br0 self permanent
01:00:5e:00:00:01 dev br0 self permanent
ea:38:5b:06:97:75 dev br0 vlan 30 master br0 permanent
ea:38:5b:06:97:75 dev br0 vlan 20 master br0 permanent
ea:38:5b:06:97:75 dev br0 vlan 10 master br0 permanent
ea:38:5b:06:97:75 dev br0 vlan 1 master br0 permanent
ea:38:5b:06:97:75 dev br0 master br0 permanent
33:33:00:00:00:01 dev br0.10 self permanent
01:00:5e:00:00:01 dev br0.10 self permanent
33:33:00:00:00:01 dev br0.20 self permanent
01:00:5e:00:00:01 dev br0.20 self permanent
33:33:00:00:00:01 dev br0.30 self permanent
01:00:5e:00:00:01 dev br0.30 self permanent
root@...8qxp-var-som:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP
group default qlen 1000
link/ether f8:dc:7a:bb:54:a0 brd ff:ff:ff:ff:ff:ff
inet 10.10.1.4/24 brd 10.10.1.255 scope global eth0
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1507 qdisc mq state UP
group default qlen 1000
link/ether f8:dc:7a:bb:54:a1 brd ff:ff:ff:ff:ff:ff
4: afe0@...1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether f8:dc:7a:bb:54:a1 brd ff:ff:ff:ff:ff:ff
5: afe1@...1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
master br0 state UP group default qlen 1000
link/ether f8:dc:7a:bb:54:a1 brd ff:ff:ff:ff:ff:ff
6: afe3@...1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether f8:dc:7a:bb:54:a1 brd ff:ff:ff:ff:ff:ff
7: afe4@...1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether f8:dc:7a:bb:54:a1 brd ff:ff:ff:ff:ff:ff
8: afe2@...1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether f8:dc:7a:bb:54:a1 brd ff:ff:ff:ff:ff:ff
9: afe5@...1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether f8:dc:7a:bb:54:a1 brd ff:ff:ff:ff:ff:ff
10: afe6@...1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether f8:dc:7a:bb:54:a1 brd ff:ff:ff:ff:ff:ff
11: afe8@...1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether f8:dc:7a:bb:54:a1 brd ff:ff:ff:ff:ff:ff
12: lan1@...1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
group default qlen 1000
link/ether f8:dc:7a:bb:54:a1 brd ff:ff:ff:ff:ff:ff
13: lan2@...1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
group default qlen 1000
link/ether f8:dc:7a:bb:54:a1 brd ff:ff:ff:ff:ff:ff
14: afe9@...1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether f8:dc:7a:bb:54:a1 brd ff:ff:ff:ff:ff:ff
15: afe7@...1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc
noqueue master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether f8:dc:7a:bb:54:a1 brd ff:ff:ff:ff:ff:ff
16: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue
state UP group default qlen 1000
link/ether ea:38:5b:06:97:75 brd ff:ff:ff:ff:ff:ff
17: br0.10@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP group default qlen 1000
link/ether ea:38:5b:06:97:75 brd ff:ff:ff:ff:ff:ff
inet 192.168.10.1/24 scope global br0.10
valid_lft forever preferred_lft forever
18: br0.20@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP group default qlen 1000
link/ether ea:38:5b:06:97:75 brd ff:ff:ff:ff:ff:ff
inet 192.168.20.1/24 scope global br0.20
valid_lft forever preferred_lft forever
19: br0.30@br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP group default qlen 1000
link/ether ea:38:5b:06:97:75 brd ff:ff:ff:ff:ff:ff
inet 192.168.30.1/24 scope global br0.30
valid_lft forever preferred_lft forever
Best Regards,
Simon
Powered by blists - more mailing lists