Messages in this thread | | | From | Frank Wunderlich <> | Subject | Aw: Re: [BUG] vlan-aware bridge breaks vlan on another port on same gmac | Date | Sun, 5 Feb 2023 14:48:55 +0100 |
| |
Hi,
sorry for the delay, i'm very busy recently :(
noticed that i missed 2 commands ("bridge vlan add vid ..." below) when testing the vlan-aware bridge...now both ports are working with vlan-tagging...the one inside (lan0) the bridge (lanbr0) and the one outside (wan).
BRIDGE=lanbr0 netif=lan0 vid=500 #ip link add name ${BRIDGE} type bridge ip link add name ${BRIDGE} type bridge vlan_filtering 1 vlan_default_pvid 1 ip link set ${BRIDGE} up ip link set $netif master ${BRIDGE} ip link set $netif up bridge vlan add vid $vid dev ${BRIDGE} self bridge vlan add vid $vid dev $netif
#extract vlan from bridge to own netdev ip link add link ${BRIDGE} name vlan$vid type vlan id $vid ip a a 192.168.110.5/24 dev vlan$vid ip link set vlan$vid up
btw can i see somehow if a bridge is vlan-aware (the flag itself)..."bridge vlan" command also lists non-vlan-aware bridges with vlan-id "1 pvid egress untagged"
so vladimir your last patch works well, thx for it. you can add my tested-by when upstreaming
regards Frank
> Gesendet: Dienstag, 31. Januar 2023 um 17:23 Uhr > Von: "Frank Wunderlich" <frank-w@public-files.de> > An: "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> > Betreff: Aw: Re: [BUG] vlan-aware bridge breaks vlan on another port on same gmac > > Hi Vladimir, > > > > Gesendet: Montag, 30. Januar 2023 um 13:58 Uhr > > Von: "Vladimir Oltean" <olteanv@gmail.com> > > 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
| |