Skip to content

ubus: do not reiterate bss_transition_request over each SSID - #269

Open
g0tar wants to merge 6 commits into
berlin-open-wireless-lab:masterfrom
g0tar:bss_transition_request
Open

ubus: do not reiterate bss_transition_request over each SSID#269
g0tar wants to merge 6 commits into
berlin-open-wireless-lab:masterfrom
g0tar:bss_transition_request

Conversation

@g0tar

@g0tar g0tar commented Jun 16, 2026

Copy link
Copy Markdown

When having multiple SSIDs, bss_transition_request is sent for each one subscribed despite the fact, that ubus_invoke() is invoked using id not sub->id.

This creates redundant copies of requests and BSS-TM-RESPs polluting the air.

Consider similar sanitization in del_client_interface().

When having multiple SSIDs, bss_transition_request is sent for each one subscribed despite the fact, that ubus_invoke() is invoked using id not sub->id.
This creates redundant copies of requests and BSS-TM-RESPs polluting air.
Consider similar sanitization in del_client_interface().
@g0tar

g0tar commented Jun 16, 2026

Copy link
Copy Markdown
Author

This fixes superfluous repetitions, but I'm not sure if the logic is proper here. Shouldn't his request be directed to kicking_ap only? What if client has just moved over to the better AP being other band on the same hostapd instance - it's going to be kicked again.

Edit: apparently the ID here is in fact kicking_ap so the logic holds.

g0tar added 4 commits June 16, 2026 13:49
The request is supposed to be send to kicking_ap only, no need to iterate over all SSIDs.
…tes list

Client asked to move using absolute RSSI kicking (method 2) should have at least some candidate_ap (on kick_nr_list), otherwise the request is futile and only torments client having weak signal already.

Do not waste air resources unless NR was deliberately disabled.

If the client doesn't provide beacons using 802.1k we cannot really do anything *polite* to help it make handover decision, it's up to the device to recognize weak signal and search for something better.
Comment thread src/utils/ubus.c Outdated
ubus_invoke(ctx, id, "bss_transition_request", b.head, NULL, NULL, timeout * 1000);
}
// do not ask to leave without providing candidates, unless NR explicitly disabled or unavailable (consider empty rrm_mode)
if (neighbors_added || (dawn_metric.disassoc_nr_length <= 0) || (dawn_metric.set_hostapd_nr <= 0) || (timeout_config.update_beacon_reports <= 0) ) {

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if update_beacon_reports condition shouldn't be coupled with set_hostapd_nr == 2, so that:

set_hostapd_nr '1'
update_beacon_reports '0'

with empty ap_nr_list won't spam either. I.e.

if (neighbors_added
    || (dawn_metric.disassoc_nr_length <= 0) || (dawn_metric.set_hostapd_nr <= 0)
    || ((timeout_config.update_beacon_reports <= 0) && (dawn_metric.set_hostapd_nr == 2)) ) {

…t with disabled 802.1k

update_beacon_reports '0' shouldn't make difference for set_hostapd_nr '1'
@g0tar

g0tar commented Jul 8, 2026

Copy link
Copy Markdown
Author

@PolynomialDivision, may I ask you for your opinion?

@PolynomialDivision

Copy link
Copy Markdown
Collaborator

I have to look closer again at this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants