Aw: Re: [BUG] vlan-aware bridge breaks vlan on another port on same gmac
From: Frank Wunderlich <hidden>
Date: 2023-01-31 16:24:12
Also in:
lkml
Hi Vladimir,
Gesendet: Montag, 30. Januar 2023 um 13:58 Uhr Von: "Vladimir Oltean" [off-list ref] Hi Frank, Sorry for the delay and thanks again for testing. I simply didn't have time to sit down with the hardware documentation and (re)understand the concepts governing this switch.
no problem, same here...not have every day time to dive into it :)
I now have the patch below which should have everything working. Would you mind testing it?
thanks for your Patch, but unfortunately it looks like does not change behaviour (have reverted all prevously applied patches,
only have felix series in).
i can ping over software-vlan on wan-port (and see tagged packets on other side), till the point i setup the vlan-aware bridge over lan-ports. ping works some time (imho till arp-cache is cleared) and i see untagged packets leaving wan-port (seen on other end) which should be tagged (wan.110).
and before anything ask: yes, i have set different mac to wan-port (and its vlan-interfaces) and lanbr0
15: lanbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 96:3f:c5:84:65:f0 brd ff:ff:ff:ff:ff:ff
17: wan.140@wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 02:11:02:03:01:40 brd ff:ff:ff:ff:ff:ff
inet 192.168.140.1/24 brd 192.168.140.255 scope global wan.140
valid_lft forever preferred_lft forever
inet6 fe80::11:2ff:fe03:140/64 scope link
valid_lft forever preferred_lft forever
18: wan.110@wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 02:11:02:03:01:10 brd ff:ff:ff:ff:ff:ff
inet 192.168.110.1/24 brd 192.168.110.255 scope global wan.110
valid_lft forever preferred_lft forever
inet6 fe80::11:2ff:fe03:110/64 scope link
valid_lft forever preferred_lft forever
have not yet defined any vlans in the bridge...only set vlan_awareness...maybe i need to add the wan-vlan
to the lan bridge too to pass filtering?
i'm unsure if tcpdump on the host interface should see vlan-traffic too (but do not show the vlan itself)...
in working state i see icmp in both tcpdump modes (pinging the full time without the bridge enabled only
changed tcpdump on the other side):
# tcpdump -nni lanbr0 | grep '\.110\.'
17:13:36.071047 IP 192.168.110.1 > 192.168.110.3: ICMP echo request, id 1617, seq 47, length 64
17:13:36.071290 IP 192.168.110.3 > 192.168.110.1: ICMP echo reply, id 1617, seq 47, length 64
and
tcpdump -nni lanbr0 -e vlan | grep '\.110\.'
17:16:35.032417 02:11:02:03:01:10 > 08:02:00:00:00:10, ethertype 802.1Q (0x8100), length 102: vlan 110, p 0, ethertype IPv4, 192.168.110.1 > 192.168.110.3: ICMP echo request, id 1617, seq 219, length 64
17:16:35.032609 08:02:00:00:00:10 > 02:11:02:03:01:10, ethertype 802.1Q (0x8100), length 102: vlan 110, p 0, ethertype IPv4, 192.168.110.3 > 192.168.110.1: ICMP echo reply, id 1617, seq 219, length 64
after the vlan_aware bridge goes up i see packets in the non-vlan-mode
if needed here is my current codebase:
https://github.com/frank-w/BPI-Router-Linux/commits/6.2-rc
regards Frank