I have a problem with sticky wifi clients.
They stay connected with a weak AP, even when they are quite near to the stronger AP.
Tests with FT were not sucessfull.
So I tried this solution:
It works quite well and as expected when I start the lua script
But when I try to install it as a service it crashes:
daemon.info procd: Instance wifi-disconnect-low-signal::instance1 s in a crash loop 10 crashes, 0 seconds since last crash
daemon.warn procd: Seccomp support for wifi-disconnect-low-signal::instance1 not available
Archer C7 OpenWrt 21.02.0
How are your APs set in terms of power and channels?
Same SSID in different channels (5 gHz Band).
One is AX (RT-3200), the other AC (Archer C7).
Windows client sticks to the Archer.
I tried to reduce the power of the Archer down to 6dBm without solving the problem.
When I disconnect the windows laptop from Archers Wifi via Luci, it connects to the RT-3200.
With the script I mentioned, I can kick-out the laptop automatically when the signal is weak.
Try reducing the power even more. Are sure the devices are set to use the same channel bandwidth and mode.
Did you try installing usteer or dawn?
I reduced the power to 0 dBm.
Now it works.
Any Ideas, why the script crashes?
I installed dawn, but I do not understand the underlying concept!?
Consider the cell_density setting. This prevents the AP from using slow data rates. The high data rates can only be received at closer distance, when the client moves out of that range it will have to drop. Turning down the power can affect the data rate to users who are actually on their closest AP.
There was some work by the hostapd developers to put some "disconnect low signal" logic into the core of hostapd, but I don't know if it was ever completed.
I turned the cell density to "very high".
Current connection speed is (with very poor performance):
|[Qualcomm Atheros QCA9880 802.11nac Wireless Controller (radio0)]
||260.0 Mbit/s, 80 MHz, VHT-MCS 3, VHT-NSS 2, Short GI
||13.5 Mbit/s, 40 MHz, VHT-MCS 0, VHT-NSS 1
So I don't think, this is the right screw.
The "wifi-disconnect-low-signal" works fine in my usecase - it only crashes when I try to run it as a service.
it uses neighbor reports to direct clients. It can kick badly connected clients (but that is kind of dangerous as in the end if the client doesnt want to connect elsewhere then it will just lose connection).
[OpenWrt Wiki] Setting up usteer and band-steering in OpenWrt
Thanks @Ramon, it looks quite complicated...
I think it looks more complicated then it is
It just helps clients to give them the information where they can connect, such that e.g. they do not need to continuously scan for a better access point. If they decide the signal is not good enough or the speed could be better (e.g. 5GHz) or they get a "disconnect imminent" (=kick) message from the AP, they know where to look for a better connection!
IEEE 802.11k-2008 - Wikipedia
IEEE 802.11v-2011 - Wikipedia
IEEE 802.11r-2008 - Wikipedia
Anyway if you want to try Dawn, pretty much you need all the stuff which is written on the usteer wiki page, except that you install dawn. Dawn does have a LuCi app which maybe makes it easer to configure (although I left everything on default), Pretty much the same with usteer, i left everything on default. Currently im using the latter.
I will give DAWN a try.
I installed it on both routers.
On RT3200 the radio did not come up.
Logread said (and another Line, which I did not capture):
daemon.err hostapd: Line 79: unknown configuration item 'bss_transition'
Found a post here:
Installing wpad-wolfssl ended with
Required dependency package libwolfssl5.3.0.ee39414e is not available in any repository.
So I replaced wpad-basic-wolfssl with wpad-openssl.
Dawn is now up and running.
I'll see, how it works.
Yes the usteer wiki page says you need this (under pre-reqs).
I also tweaked my 2.4GHz transmit power to lower values such that most clients just connect to the 5GHz. There is a post somewhere on this forum with a link to an iOS explanation where it says that iOS clients start looking for a better connection when the signal to noise drops below a certain value.
For me the combination works good most of the time, ok-ish for some clients (i still have sometimes that clients do not want to roam, but there is nothing much else i can do).
Anyway on the dawn luci app page you can see what AP sees what clients and they are rated in terms of their connection. For usteer you need to log into the router and issue the commands listed on the wiki page.
Oh i guess for 802.11r (fast BSS transision), you may need more configuration than what is on the usteer wiki page. Usually just checking "generate PMK locally" in the Luci config page is enough. The rest you can leave blank
I installed dawn and reduced the TX-Power of the archer to 14dBm.
Now my laptop doesn't stick to the archer anymore.
Thanks to all.
Concerning dawn and the Hearing-Map one question:
Should the hearing-map on both routers be identically?
On my routers, there are some differences.
The reason I suggested lowering power is that you want to minimize the overlap between APs as a means of encouraging the client devices to roam. Generally speaking, roaming is a client side process. There are standards such as 802.11r "fast roaming" that are supposed to help coordinate and direct the process, but not all clients play well with this technique.
I don't know why you've been seeing those crashes, but in general, it is possible to have a very well performing multi-AP roaming configuration purely based on appropriate tuning of channels and power (and sometimes the cell density settings). So sometimes using the KISS theory, you'll end up with a more performant system. Case in point -- my dad's home has 5 APs, and I have them tuned as I've just described -- the roaming works really well and he never has 'sticky' clients.
@psherman Thanks for your advice.
I really like the KISS concept!
My usecase atm is main-router (RT3200) for the first floor, the AP (Archer C7) for the second and third floor. Therfore I can't reduce the power of the AP too much.
Perhaps it would be better, to move the AP to the third floor, or add an additional AP in the third floor.
But unfortunately there is a little cabling problem.
So I'll make some experience with the actual setup. Looks good atm.
Ideally, having an AP on each floor with the power as low as reasonable will be the best option. But obviously that may have complications based on the physical considerations (such as ability to run cables, place APs in good locations, etc.).