Lan ports aren't accessible for WiFi client for the first 250-330 seconds after connection

General discussion
,
21
attempt at a potential explanation
  • two address databases are at work and one perhaps superseding the other
    • switch address database
      • ageing of 300 seconds
      • learning on its downstream ports
      • no learning on the WLan ports (by design)
    • bridge fdb
      • learning on switch downstream ports
      • learning on WLan ports

If the switch address database is superseding the bridge fdb it would explain why clients that move from a Lan port to a WLan port in less than 300 seconds are exhibiting the connectivity issue.

22

Hi. This happens on my Turris MOX as well. At first the workaround seem to be working, but testing again it doesn’t. I am not sure why it did seem to work before.

Even when WDS AP enabled on all of my APs (as to my surprise I have read that it may be necessary to get the bridging even working at all)

I have three APs:

[Turris MOX]
|  L ethernet -- [ Openwrt on TPLink WR1043ND]
L_   ethernet -- [ Openwrt on D-Link DIR 825 ]  -- wireless -- [raspberry-pi]

Each device has a linux bridge over eth and wlan devices With my mobile phone I am roaming between them. When I roam from the D-Link to MOX, it seem to not work until some timeout . When roaming from TP-Link to D-Link, it seems OK just handover to new AP and pings to RPi are going no problem.

This is on my MOX at the moment

lan1	 11 Egress Untagged

lan2	 12 Egress Untagged

lan3	 13 Egress Untagged

lan4	 14 Egress Untagged

lan5	 15 Egress Untagged

lan6	 16 Egress Untagged

lan7	 17 Egress Untagged

lan8	 18 Egress Untagged

br-guest_turris	 1 PVID Egress Untagged

br-lan	 1 PVID Egress Untagged

wlan0	 20 Egress Untagged

wlan1	 21 Egress Untagged
24

There is someone else aparently having the same issue:

1 Like
25

Indeed I’m encountering the same issue.

Could it be related to ARP caching somehow? I only seem to get it when roaming from my other APs to the Turris, and not when I turn on my device in the Turris range.

I’m sure it’s not ARP caching on the main router, because everything works fine switching between other APs.

26

I just took my laptop and phone in Turris range, the laptop had no issues and the phone was blocked for a while.

The phone was visible in the wireless clients list with its IP address, but could not be pinged. From the phone, none of the other wireless clients could be reached. After a while the phone disconnected from wifi and tried again but didn’t get a DHCP response. Shortly after that it did get a DHCP response and everything worked.

I think the above behavior matches the phone MAC address being cached and any packets for it going to the LAN interface (that it was on before) and not to the WiFi interface.

27

This sounds very similar to this issue: OMNIA: Vlan on DSA port breaks arp responses (TOS 4.0.5). There is a script that someone posted which monitors the wifi interface and removes stale entries from the lan bridge when a client roams to wifi. That completely solved the issue for me.

28

Thanks! I installed it (from https://github.com/stanojr/tempfix_fdb_dsa) and let’s hope it works.

I hope Turris will fix this properly at some point, is there any way to track that?

29

You can follow the issue on their gitlab issue tracker: https://gitlab.nic.cz/turris/turris-build/-/issues/165

1 Like