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>
Fetch the age of the association for STAs in order to implement minimum
intervals after which a STA is considered kickable.
Signed-off-by: David Bauer <mail@david-bauer.net>
Query client MBO support from hostapd and display it in the output of
the connected_clients ubus method as "multi-band-operation".
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
As probe steering only makes sense in specific deployments, it should be
disabled by default.
Update the example config to reflect this change.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-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>
As load-balancing only makes sense in specific deployments, it should be
disabled by default.
Update the example config to reflect this change.
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>
Send link-measurement requests to every supporting local-sta in order to
acquire information to assess the link-quality bi-directional.
The link-measurement request is sent each configurable interval. It can
be disabled by configuring the interval to 0.
Signed-off-by: David Bauer <mail@david-bauer.net>
If the timeout is not reset here, it will expire based on its initial
creation regardless whether it was updated in the meantime.
Signed-off-by: David Bauer <mail@david-bauer.net>
Generalize measurement handling in a way that RCPi and RSNI are stored
regardless of the specific measurement type. This allows us to handle
link-measurement reports the same way as we already handle
beacon-reports.
Signed-off-by: David Bauer <mail@david-bauer.net>
Request hostap to enable the link-measurement capability in the BSS
beacons. Otherwise, STAs might reject link-measurement requests despite
being capable of performing such.
Signed-off-by: David Bauer <mail@david-bauer.net>
This adds a new band-steering component to usteer.
With band-steering enabled, usteer will attempt to move clients with a
consistently good SNR / signal from 2.4 GHz to the 5 GHz band.
In contrast to existing policies usteer tracks, band-steering is
non-invasive and will not lead to forceful connection termination.
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>
This prevents communication with other usteer nodes and allows it to be
used for purely local band steering / load balancing
Signed-off-by: Felix Fietkau <nbd@nbd.name>
BSS transition management as well as RRM capabilities have to be
considered not for the STA but per STA connection.
Most prominently, a STA might not support BSS-TM when connected without
PMF.
Signed-off-by: David Bauer <mail@david-bauer.net>
This causes segfaults on OpenWrt 21.02 which is missing the op-class
field.
Reported-by: John Crispin <john@phrozen.org>
Signed-off-by: David Bauer <mail@david-bauer.net>
Save the latest BSS-transition management response received from a STA.
This information can later be used to prevent kicking STAs when they
rejected a transition request.
Signed-off-by: David Bauer <mail@david-bauer.net>
Add a method to obtain local-host specific state data about usteers
internal logic for each connected STA.
Signed-off-by: David Bauer <mail@david-bauer.net>
Add logic for saving measurement-reports from STAs.
This commit does not yet save the measurement-reports received from
clients but adds the necessary code to do so. Currently the codes can
only handle beacon-reports, but link measurements can be added to it in
the future.
It also adds the new config-key measurement_report_timeout which
controls how long measurements are saved upon they are received by a
STA.
Signed-off-by: David Bauer <mail@david-bauer.net>
Add methods which returns a given node for a provided BSSID. This is
required to retrieve the node object from information available with
a neighbor report.
Signed-off-by: David Bauer <mail@david-bauer.net>
In order to send passive beacon-requests, channel and op-class of nodes
are required. Obtain this information per local-node from hostapd.
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>
Make usteer handle incoming BSS-transition requests. Update with the
most active roaming neighbors like we already do for imminent
disassociations.
Create a new ubus method which calls hostapds bss_transition_request
method. This does not set the disassoc imminent bit, thus will not
automatically disassoc the requesting STA.
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>
