I’m running a CAPsMAN network on three APs (resulting in 6 “cells” due to 2g and 5g) with same SSID(s). That works very well for most devices as expected.
But I’m observing two devices (same vendor = Dyson) which are hopping between all 3 access points every few seconds. Sometimes they stay connected for almost a minute but sometimes a lot less.
Overall they “work” as expected which means they apparently have working connection to their cloud service but still this is a bit weird.
Probably that is just a broken wifi client and I cannot do anything? Are there any workarounds to that from the AP side?
And a second part where I’m not sure about is the Mikrotik behavior:
Once the device switched from one AP to the other it gets its IP deassigned from DHCP and reassigned immediately again.
Is that expected? According to the log the DHCP server deassigned the IP. That reads as if it’s a server decision?
Roaming between APs is completely up to wireless client. Usually they roam from one AP to another when other AP’s signal gets better than signal of current AP. Seems like some don’t apply no hysteresis (meaning: new AP should be at least a few dB better than current) which makes roaming a bit less “nervous”. I’d say that those devices happen to be located in a spot where all APs offer signal of comparable level (and keep in mind that wireless signal fluctuates by a few dB due to subtle changes in environment, such as people passing by).
Regarding DHCP deassignments/assignments: AFAIK it’s normal to see a pair of those messages in logs when device renews DHCP lease. That can either happen due to lease age reaching half of expiry time or if client decides that it might be connecting another network and it needs to obtain a new lease. While most devices when roaming between APs with same SSID don’t do it, some (flakey ones?) might decide to renew the lease in any case. Again these procedures are mostly driven by client. Even if DHCP server decides to nuke the lease, it can’t force client to re-new the lease.
I meanwhile verified via DHCP debug logging that the clients send a DHCP discover in that case which triggers the reassignment.
I’m wondering if the “Access List” feature could help so I can allow a client only to connect to the closest AP. I think that would be possible but what would likely happen in reality? The client would see the other wifi and would try to switch but then is not accepted. I assume it would not improve at all since it still would try just to get rejected?
Seems like some clients remeber being rejected from connecting certain BSSID (SSID served by a particular AP) and keep away from it for a while. The flakey ones will keep trying never the less.
You could try to play with Tx powers on all APs to move the “equal signal area” away from location where those devices usually stay, but be prepared to see some other weirdnesses.
If you have the APs spread out you could use the access list and have accept rules for those MAC addresses to each AP with a signal level that is really good i.e. (-50..120). This way if the device gets too far away from any one AP it will only connect to one of the APs. This won’t help though if the signals overlap too much and if you need to go further out from any one AP.
There is only so much you can do to mitigate issues with broken wifi implementations.
This log, IMO, indicates that wireless client is misbehaving. It’s disconnecting from perfect cell (signal strength of -57 dBm is nothing to frown at) in less than a second to connect to a 18 dB weaker cell?
I don’t know if you can do something about it though.
