I previously reported an issue with my clients having issues roaming. See here.
I first thought I had solved the issue, but I was wrong. And now I stumbled upon the following topic. And the description fits my issue perfectly, however I think the root cause wasn't identified.
Here is my setup:
router (Archer C6v3) => PoE-Switch (TL-SG105PE) |=> ap-1 (EAP235-WALL)
OpenWrt 22.03.3 Stock FW (latest) | OpenWrt 22.03.3
10.0.10.1 10.0.10.2 | 10.0.10.3
DHCP-Server | Dumb AP (No FW OR DHCP)
|=> ap-2 (EAP235-WALL)
Dumb AP (No FW OR DHCP)
There are also multiple VLANs, but I don't believe these are the root cause as the primary VLAN is able to reproduce the DHCP issue.
The SSIDs do indeed show +FT and roaming works fine. However if any mobile device is switching the AP, the DHCPDISOCVER & DHCPOFFER lopp starts as previously stated:
C6 | Wed Mar 15 09:50:03 2023 daemon.info dnsmasq-dhcp: DHCPDISCOVER(br-lan.10) de:ad:be:ef:d3:3c
C6 | Wed Mar 15 09:50:03 2023 daemon.info dnsmasq-dhcp: DHCPOFFER(br-lan.10) 10.0.10.149 de:ad:be:ef:d3:3c
[...] 14 more repetitions
C6 | Wed Mar 15 09:52:35 2023 daemon.info dnsmasq-dhcp: DHCPDISCOVER(br-lan.10) de:ad:be:ef:d3:3c
C6 | Wed Mar 15 09:52:35 2023 daemon.info dnsmasq-dhcp: DHCPOFFER(br-lan.10) 10.0.10.149 de:ad:be:ef:d3:3c
After some minutes the device then magically receives the DHCPOFFER and DHCPREQUEST & DHCPACK are exchanged and the client is back onlione.
I also tried to tcpdump on the different devices to narrow the issue down, but as stated by @overmyhead in his post the packets just do not seem to arrive at the "latest" AP of the device until some time expires.
Is there a common sulotion for this scenario?
I also read about the cron script of @Brain2000, but I'm not sure which device this script is supposed to be running on. On the router or on all of the devices?
Yes, but keep in mind that this is just a guess and I could be totally wrong.
When a wireless client moves from one AP to another, the host MAC address learned on one switch port appears on another switch port (where the other AP is connected). A good quality switch should immediately update its L2 forwarding table by replacing the existing entry with the same MAC address but with the more current port number.
I think the TP-Link switch continues to forward the frames over the old interface (where the previous AP is connected) for a while longer.
Sorry, I'm not familiar with your device.
I would assign a static IP to a test wifi device, start a ping session from the router and check the packet losses when switching between APs and the router.
Based on the suggestion by @Brain2000 I also applied the adjustment of the bridge ageing, and it seems to solve the issue for now. At least for most situations.
However, I want to further analyze the switching behavior of the TL-SGE105PE.
This series of switches is really poorly designed (I know, I have used them) and they have a number of major flaws in the implementation. My general advice is to avoid them entirely (as well as the entry level Netgear equivalents), and to move up towards the mid-range TP-Link managed switches and/or other brands.
That said, it may not be worth your time to do additional analysis. But, if you do go to the trouble, please do share your findings - it may be interesting and useful for future readers.
This all depends on your required number of ports (general and how many with PoE), features needed, management methods, etc.. On the 8 port and higher range, you can look at the TP-Link JetStream/Omada series, ZyXel 1900 series, Unifi, and some of the Netgear models (again, stay away from the entry level). I haven't used any switches with OpenWrt yet... for but search the forums for recommendations on that front.