qca8x DSA: Configured Switch Sends Packets Out Wrong Interface
Using qca8k and ipqess on an EA8300 (ipq40xx) under Linux 4.19 based
on patches from chunkeey's staging tree[1] as well as a patch to
resolve the NPE issue[2].
Once the switch has been configured (this is *after* the power-on
config has been overridden), I see that packets are being sent out
over ports that aren't associated with the bridge. As these packets
are not seen with tcpdump on the underlying interface, I believe that
they are traveling through the switch fabric.
* Am I configuring the bridge as expected?
* Are there patches that I am missing?
I have tried configuring the bridge both using /etc/config/network (no
switch-related sections) as well as "manually" with iproute2
commands and see the same behavior in both cases. In both cases,
`brctl show` and `bridge link` output is consistent with that
expected; the expected interfaces are present and those not involved
in the bridge are not present.
The initial test was for the "desired" configuration:
* lan1 -------- stand-alone 192.168.1.1/24
* lan2 -|
* lan3 -| -- bridged
* lan4 -|
* wan0.10 -|
* wan0.NNNN -- other trunked VLANs -- to Cisco SG300
config interface 'lan'
option type 'bridge'
option ifname 'lan2 lan3 lan4 wan0.10'
option proto 'static'
option stp '1'
option ipaddr '10.X.Y.Z'
option netmask '255.255.255.0'
(wan0.10 configured and brought up elsewhere)
This appeared to work for connectivity to the device itself, but a
wired client plugged into lan2 was unable to obtain a DHCP lease from
the DHCP server connected to the Cisco SG300, leading to this exploration.
Examining the packets seen by this client suggested that they were
being sent out lan2-4 as tagged VLAN 10 (unexpected).
(I need to re-confirm this as the EA8300 at the time "won" STP root.)
I then removed wan.10 from the bridge and connected lan4 to
an untagged source of the 10.X.Y.Z/24 traffic from the SG300
* lan1 ----- stand-alone 192.168.1.1/24
* lan2 -|
* lan3 -| -- bridged
* lan4 -|
config interface 'lan'
option type 'bridge'
option ifname 'lan2 lan3 lan4'
option proto 'static'
option stp '1'
option ipaddr '10.X.Y.Z'
option netmask '255.255.255.0'
Looking at the packets on the lan1 port, traffic that was clearly from
the subnet associated with the 10 VLAN was being seen (unexpected).
Looking at lan1 with `tcpdump -ni lan1` only showed an occasional ARP
related to the 192.168.1.1/24 subnet (as expected).
This suggests to me that the packets are flowing through the switch
fabric, not the CPU.
Configuring lan1 as a bridge rather than a direct-accessed interface
did not change the behavior.
(This continued to occur after changing the STP priority of the SG300,
rebooting the router, and confirming that the SG300 was the STP root.)
Configuring with iproute2 commands after removing the applicable
interface section from /etc/config/network did not change the behavior
#!/bin/sh
ip addr add 192.168.1.1/24 dev lan1
for if in lan1 lan2 lan3 lan4 wan0 ; do
ip link set ${if} up
done
ip link add name lan-br type bridge
ip link set lan-br type bridge stp_state 1
ip addr add 10.X.Y.Z/24 dev lan-br
ip link set lan-br up
for if in lan2 lan3 lan4 ; do
ip link set ${if} master lan-br
done
Based on these observations, I believe that the switch fabric is not
being properly configured, that I am missing patches causing the
former, or that I am somehow not configuring the bridge properly.
Any suggestions as to how to proceed?
Jeff
[1] Patches from chunkeey's staging tree:
f42d8ea703 ipq40xx: include ipq40xx-ized qca8k version
35cacbdc1e ipq40xx: fix NPE related to bogus use of fixed phy
b696da2763 ipq40xx: extend DT mdio node to be more accessible
1c8d4e491b ipq40xx: add ipqess ethernet driver
23cf41880f ipq40xx: add resets for individual MAC1-5 and PSGMII
7bf4edca65 ipq40xx: decouple mdio-ipq40xx and ar40xx
415f2c04c4 phytool: add phytool utility
merge-base with master is b61495409b
CommitDate: Thu Mar 14 22:55:06 2019 +0100
[2] 730-HACK-prevent-panic-adding-vlan-to-bridge.patch
after Florian Fainelli,
[PATCH] net: dsa: Add ndo_vlan_rx_{add, kill}_vid implementation
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -255,7 +255,10 @@ int dsa_port_vlan_add(struct dsa_port *d
if (netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
- if (br_vlan_enabled(dp->bridge_dev))
+ /* Can be called from dsa_slave_port_obj_add() or
+ * dsa_slave_vlan_rx_add_vid()
+ */
+ if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))
return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_ADD, &info);
return 0;
@@ -270,10 +273,13 @@ int dsa_port_vlan_del(struct dsa_port *d
.vlan = vlan,
};
- if (netif_is_bridge_master(vlan->obj.orig_dev))
+ if (vlan->obj.orig_dev && netif_is_bridge_master(vlan->obj.orig_dev))
return -EOPNOTSUPP;
- if (br_vlan_enabled(dp->bridge_dev))
+ /* Can be called from dsa_slave_port_obj_del() or
+ * dsa_slave_vlan_rx_kill_vid()
+ */
+ if (!dp->bridge_dev || br_vlan_enabled(dp->bridge_dev))
return dsa_port_notify(dp, DSA_NOTIFIER_VLAN_DEL, &info);
return 0;
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
