The signal parameters are per interface, not global. You can have different interfaces with different signal levels. The default signal level is -128 which will work like normal and accept all connections. Signal polls will not be conducted unless the signal_stay has been raised above -128.
(On a dual band router, each radio runs under a completely independent instance of hostapd, so "global" settings are actually per radio.)
I do see some auth requests with a plausible signal level reported, and those below -50 are getting denied. This is a good sign that it is likely to work. You need log_level 0 (global) to see the signal results on each poll.
Note that with the default strikeout policy, a client needs to stay continuously in a weak signal condition for 40 seconds before being dropped. The use case I was interested in is outdoor festivals, where users are moving around rather slowly.
The result seems better. logread -f shows me that both bands are being scanned correctly. If my client is below -65 dBm, it doesn't connect with the access point.
Also option signal_stay seemed to work, but it was a little unresponsive. My client was at an area with - 78 dB but it took around 10 seconds to disconnect with above values.
You could go to shorter polling or fewer strikes, though that is likely to cause more unwarranted disconnects.
When a mobile phone or tablet is not actively exchanging data, it puts its wifi system to sleep. It may not transmit any wifi packets for a minute or more. In that case in the signal poll, the AP's wifi driver repeats the last received signal report, as it is the only information available but will be completely wrong if the phone or tablet has been moved.
Tested it again with the default values for the signal polls, and it works great so far.
I thank you really much for you help. It would be great to get the packages added at the software repository in future.
There is also a "distance" option that should have similar effect - disconnect clients that are further than you would like them to be. Distance is directly linked to RSSI.
Is there still a need for this stuff?
I could just copy code together and give u a daemon that is exactly doing this functionality.
I would use iwinfo to poll for rssi and add it to a uloop...
I have updated the patch for Hostapd up to current version used by master.
It works, but ubus needs to be used to set thresholds.
Also, I am working on getting rid of ubus dependecy so this could be upstreamed.
But, hostapd is quite complex.
It also looks like hostapd already has support to set RSSI threshold but only for STA when connecting, its not monitored after.
Its called Optimized Connectivity Experience (OCE)
The hostapd used by master is still version 2.7 from December 2018 (with numerous official patches brought in). Uncharacteristically, the hostapd group announced a major release 2.8 at the end of April 2019. OpenWrt developer Hauke has made a branch with this port, I would expect it to be mainstream soon. https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/hostpad
I have been working from the Hauke git and updated my patch to work with 2.8. Testing has only just begun though.
If you also modify the hostapd.sh script, it is possible to put the settings in /etc/config/wireless and have them translated to the new parameters parsed by config_file.c
The implementation code is placed in ubus.c (since there is a "hook" where the main part of hostapd will call every time a station attempts to connect) but it isn't necessary to use ubus per se.
This is a big step in the right direction but I haven't tested it yet. It seems to have two major limitations:
Won't drop stations that move away or fade
Doesn't ignore probe requests from weak potential clients (that generally would prevent the AP from being shown to the user as available, which is a good thing).
A benefit of this has been that more hostapd data structures now include RSSI and pass it around for potential consideration.
It looks like the official "refuse associate" adds one config file parameter, which OpenWrt should support. All of this logic is still present and available in the patched version.
I know that we are still at 2.7, I mentioned that upstream solution as I did not see it before at all.
I have been working on removing the ubus being required to be able to push this upstream with your permission if it works.
That way it can use hostapd.conf like everything else and can be backported to OpenWrt.
But, I am now kinda stuck on getting the function triggered as hostapd code is now getting quite complex.
Its still lacking in functionality as it is part of OCE and has a relative stupid requirement that threshold can be only set from -60 to -90dBm, and like you mentioned it only checks when associating.
