[BUG] Stale FDB entries after WLAN roaming with mt7530 DSA on untagged ports
nick
vincent at systemli.org
Tue May 27 13:53:24 PDT 2025
Hi,
OpenWrt users are observing an issue on OpenWrt (22.03+) with the mt7530 DSA
switch, where roaming wireless clients leave behind stale FDB entries when
using *untagged* VLAN ports. The client's MAC address remains associated
with both the old and new AP interfaces, causing traffic to be misrouted
or dropped until the stale entry expires.
People describe the steps to reproduce it differently; however, I share what
I observe, and the result is the same.
Steps to reproduce:
1. Bridge WLAN to a VLAN via mt7530 DSA, using *untagged* ports.
2. Connect a wireless client to AP1 (mt7530 switch).
3. Roam the client to AP2 (no mt7530 switch).
4. Roam back to AP1 (now connectivity breaks).
5. Observe that AP1 (where the client is now connected) FDB still lists the
client MAC on the ethernet, e.g. dev lan4 vlan 40 self (pointing to AP2)
and the wlan interface, but does not route traffic to the wlan (dev
wlan5-ff used 127/0 master br-dhcp). So two entries are available.
Topology diagram illustrating the setup:
+--------+ +------+
| Router | | AP2 |
| (DHCP) | +------+
+--------+ |
\ |
\ /
\ /
+---------------+
| AP1 |
| mt7530 DSA |
+---------------+
Expected behavior:
The FDB should update immediately to reflect the new interface.
Actual behavior:
The stale entry persists, breaking connectivity until it times out.
Notes:
- This connectivity breakdown does *not* occur using tagged ports; only
untagged ports are affected.
- It did not occur with `swconfig` (pre-DSA switch framework).
- For some users, a user-space FDB cleanup script worked (however, it does
not work for me).
- The issue is still present with kernel version 6.12 (latest tested).
More discussion and technical details can be found here:
https://github.com/openwrt/openwrt/issues/11650
Any help or insights would be greatly appreciated. This issue has been
present for quite a long time, and that’s why I’m reaching out for help
via this mailing list.
Best regards,
Nick
More information about the Linux-mediatek
mailing list