[snip]
I still don't like the parsing though. Like I said above, that's a lot
of complexity that simply doesn't even exist when hostapd controls all
the updates.
I really would have envisioned this much more along the lines of having
hostapd start the channel switch (WLOG on link 1 out of links 1 and 2)
with an nl80211 message that has:
- post-switch beacon for link 1
- during-switch beacon for link 1
- CSA counter offsets for CSA, eCSA, etc. elements
- post-switch beacon for link 2 (?)
- during-switch beacon for link 2
- CSA counter offsets for link 1's CSA counter
(for all the per-STA profile link 1 elements)
isn't that pretty much it? All the BPCC is well-contained within that
and maintained by hostapd.
I'll agree that this limits to only doing a single channel switch at a
time across the whole MLD, but maybe that's not the most problematic
thing?
OK I guess I'll have to think about this more ...
I've also spent some time thinking through the idea of handling frame
formation at the hostapd level and simply notifying the kernel. Here are
the key points I arrived at:
1. Using a single Netlink (NL) command:
----------------------------------------
The average beacon size is around 500 bytes. During Channel Switch
Announcement (CSA), we need to send two beacons—one for CSA and one
post-CSA resulting in approximately 1000 bytes per link. If we apply
this across all 14 additional links (MLD can have max 15 links), the
total data sent via NL becomes roughly 15,000 bytes. This is quite large
and may exceed what the NL socket buffer can reasonably handle.
2. Using multiple NL command for each link:
-------------------------------------------
In the case of a 3-link AP MLD, where Link 1 initiates a Channel Switch
Announcement (CSA), the sequence would look like this:
Link 1 starts CSA via NL command:
* csa_beacon
* CSA and ECSA offsets
* after_beacon
Link 2 beacon update via NL:
* Beacon data
* Partner offsets
* CSA and ECSA offsets
Link 3 beacon update via NL:
* Beacon data
* Partner offsets
* CSA and ECSA offsets
Once CSA is completed on Link 1, both Link 2 and Link 3 will require
another beacon update via NL to reflect the new state.
The complexity increases when, during Link 1’s ongoing CSA, either Link
2 or Link 3 initiates a CSA or a Color Change Announcement (CCA). In
such cases, Link 1 must update its beacon to include elements from Link
2 or Link 3’s per-STA profile. However, since Link 1 is already
undergoing CSA, it cannot perform a beacon update at that time, leading
to a conflict in update handling.
To keep things simple, one might suggest allowing only one Channel
Switch Announcement (CSA) at a time within an MLD. However, this
approach isn't feasible. For instance, consider a 5 GHz link that's part
of an MLD. If another link is performing a CSA and the 5 GHz link
detects radar, it must immediately initiate its own CSA and vacate the
radar channel. In such scenarios, enforcing a single CSA per MLD is
impractical and could lead to regulatory non-compliance or operational
issues.
Even if we somehow manage to address the earlier issues, a new challenge
arises with managing moving offsets and tracking which offset
corresponds to which link relative to the reporting link.
For example, consider an AP MLD with three links. Suppose Link 3
initiates a CSA. As a result, Link 2 receives a beacon update that
includes a CSA element in Link 3’s per-STA profile. Let’s assume the
counter offset for this CSA is at position 200.
Now, if Link 1 also starts a CSA, the next time Link 2’s beacon is
updated, it will iterate through all partner links from Link 0 to the
maximum. Since Link 1 comes before Link 3, its CSA element will be added
first, followed by Link 3’s. This causes Link 3’s CSA element to shift
down in the beacon, and its counter offset may now move to position 400.
This dynamic shifting of offsets makes it difficult to reliably track
which offset belongs to which link, especially when multiple CSAs are
active and beacon contents are updated frequently.
Another challenge with handling multiple NL (non-link-specific) beacon
updates is the need to wait until all beacon updates are received by the
kernel. This requires implementing a "wait for completion" mechanism.
However, since waiting indefinitely isn't practical, there must be a
timeout or fallback threshold. This introduces a few critical questions:
* What happens if one of the links fails to send its beacon update
within the timeout?
* Should the CSA proceed with the updates received so far, or should
the entire CSA process be aborted?
These decisions are non-trivial. Continuing the CSA without all updates
might lead to inconsistent behavior across links, while aborting the CSA
could delay critical operations like radar avoidance. A well-defined
policy or fallback strategy is essential to handle such partial update
scenarios gracefully.
-------------
Considering all the challenges discussed, I still believe that handling
beacon manipulation at the kernel level is the most effective approach
especially for critical updates. This method offers the best possible
way to manage the critical update feature purely through software,
ensuring reliability and consistency across links.
Let me know your thoughts on this?
--
Aditya
