Don't alter roam-sm stats when remaining idle. Previously, a
roam-sm-event was registered when keeping the idle-state.
Signed-off-by: David Bauer <mail@david-bauer.net>
Always increase the kick-counter when usteer de-associates a STA. This
was previously exclusively done when kicking clients due to insufficient
SNR.
Signed-off-by: David Bauer <mail@david-bauer.net>
Usteer imposes minimum intervals for steering actions in order to avoid
creating endless roam-kick loops due to the decentral aspect of usteer.
Make these basic limits to roamsteering usable across band-steering and
signal-based roam-steering.
Signed-off-by: David Bauer <mail@david-bauer.net>
Onky trigger the roaming-sm after a client becomes roamable. This is the
case when a STA is connected for longer than roam_trigger_interval.
Signed-off-by: David Bauer <mail@david-bauer.net>
Probe suppression is mostly useful in high density deployments, where
all APs responding to all client probes would result in all channels
being saturated. It effectively hides APs from clients, and can cause
problems in normal density deployments.
Add an option for it, so it can be disabled.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: David Bauer <mail@david-bauer.net>
Increasing ev.type by one for these event types works due to the order
of the elements in enum uevent_type, but makes the code harder to
understand and debug. Imagine seeing the following event log:
Mon Jun 27 22:08:43 2022 user.info usteer: usteer event=probe_req_deny node=hostapd.wl24-iot sta=e4:5f:01:00:92:b6 reason=better_candidate signal=-79 assoc=1 load=27 select_reason=signal remote=fe80::b2a7:b9ff:fecb:eeba#hostapd.wl24-iot remote_signal=-39 remote_assoc=13 remote_load=20
Trying to find probe_req_deny (UEV_PROBE_REQ_DENY) in the code will not
yield any useful results. Assigning the enum element to ev.type makes it
much easier to find where exactly the above log event comes from.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: David Bauer <mail@david-bauer.net>
Load-balancing only makes sense where multiple APs are deployed in the
same area. Enabling load-balancing between APs in different rooms might
steer clients to APs with a much lower signal strength, resulting in
lower data rates and inefficient use of airtime.
Allow disabling load balancing by setting the threshold to 0.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: David Bauer <mail@david-bauer.net>
The candidate is never set in this loop. Fix it by setting it
to the first valid entry.
Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@westermo.com>
The roam-kick-delay was not honored prior this patch. Because of this, a
client got kicked immediately.
Signed-off-by: David Bauer <mail@david-bauer.net>
Only send the preferred candidate with a BSS transition request.
Otherwise, unsuitable candidates might be included in the neighbor-list
of a transition request.
Signed-off-by: David Bauer <mail@david-bauer.net>
Add a timeout in case a STA rejected a transition request. For this
configurable timeframe, usteer will refrain from steering the client
another time.
Signed-off-by: David Bauer <mail@david-bauer.net>
While usteer tries it's best to determine the availability of a better
node for a certain client, it might still attempt to direct the client
to a unsuitable AP.
Transition away from using BSS-Transition-Requests with the
disassoc-imminent bit set and instead unset this bit.
This way, the client can inform the AP it will not transition to a
different BSS but instead wishes to remain connected to the current AP.
usteer will still kick clients in case they either accepted the
BSS-transition-request and do not roam or ignore the request completely.
Signed-off-by: David Bauer <mail@david-bauer.net>
Currently the min_snr option will result in kicking clients the first
time their SNR dips below.
This might not be desirable, as drivers (notably ath10k) sometimes
report a much lower RSSI for a short timeframe after returning to
sensible values. Also, a device might be in the process of roaming just
to be kicked before.
Add the min_snr_kick_delay option. A client will be kicked after this
timeframe when it's SNR is below the min_snr threshold value over the
complete timeframe.
Signed-off-by: David Bauer <mail@david-bauer.net>
Don't determine a finished client scan based on whether the current node
has seen a beacon or not.
This works surprisingly bad on 5 GHz nodes, as clients may refuse to
perform active scanning on this frequency band. In case the clients does
refuse to scan the 5 GHz band but scans the 2.4 GHz band actively, we
might have a good indication about a better node on this band at least.
However, as the roam state-machine requires to have seen a probe request
from the client to direct him to a better node, thi process will not
continue, which either ends the node in being kicked due to exceeding
the number of max tries or the scan cooldown to kick in.
The solution to this is fairly simple: Don't track the roam_scan_done
state but instead just determine a better candidate after the scan
interval finished.
To ensure the indicated signal levels are as recent as 2 *
scan-interval, add a max_age parameter to find_better_candidate.
Signed-off-by: David Bauer <mail@david-bauer.net>
The logic guarding entering of the SCAN state of the roam state-machine
was incorrect in case the scan-timeout was not enabled.
Signed-off-by: David Bauer <mail@david-bauer.net>
Add an optional timeout when a better roaming candidate is not found
after the scan-retry limit. The roam state-machine will not retry
scanning before this timeout has expired.
If the timeout is set to 0, the client is kicked instead, which
resembles the behavior prior this commit.
This is added, as without this patch, if a forced disconnect
is not desired before roam_scan_trigger is exceeded the client will
repeatedly be asked to return active beacon-reports. For battery powered
clients this can result in a noticeable battery drain.
Signed-off-by: David Bauer <mail@david-bauer.net>
Don't select a node as a better candidate where a STA has insufficient
signal to. This is the case when the roam_trigger_snr is greater than
the projected signal of the client.
This stops clients from being selected to roam to a node where the
signal is not sufficient to maintain the connection. A selection might
otherwise happen e.g. due to better channel load on the remote node.
Signed-off-by: David Bauer <mail@david-bauer.net>
Export snr_to_signal to other source files. This will be necessary to
determine reported signal strengths from beacon-report throughout the
code base.
Signed-off-by: David Bauer <mail@david-bauer.net>
When kicking clients due to high channel load, explicitly only select
new candidates in case their channel load is an improvement over the
current node.
Signed-off-by: David Bauer <mail@david-bauer.net>
It is not necessary to check if the candidate is not considered
reverse-better, as this is already done inside is_better_candidate for
all relevant criteria.
Signed-off-by: David Bauer <mail@david-bauer.net>
A unset bitmask leads to the candidate selection always return no
candidate, even if there is one.
To select a better candidate regardless of it's classification, provide
a bitmask containing all selection criteria.
Signed-off-by: David Bauer <mail@david-bauer.net>
When determining a new node within the roam state machine, require the
destination node to have a better reported signal from the client.
Otherwise, the roam state machine might trigger a roam action for a
unsuitable destination node.
Signed-off-by: David Bauer <mail@david-bauer.net>
When checking whether a client is allowed to associate to a node, the
lower ceiling for kicking clients was not taken into account when
assoc-steering is disabled.
The problem behind this is, that a configured lower barrier for
disassociating clients (kicking) would kick the client immediatly after
association. In the worst scenario the client immediatly associates
again to the station and ends up in a kick loop.
Don't allow associating when a min_snr is configured and the client
signal is below this value.
Signed-off-by: David Bauer <mail@david-bauer.net>
Make the connection state of a sta-info more readable by introducing an
enum for the STA connection state.
Also switch come comparison cases to use the explicit enum values to
make the code more readable.
Signed-off-by: David Bauer <mail@david-bauer.net>
- make logging events more structured
- add fine grained control over log events
- make it possible to receive more detailed events via ubus
Signed-off-by: Felix Fietkau <nbd@nbd.name>
