On 18.06.20 08:18, Shay Bar wrote:
On 18.06.20 07:11, Shay Bar wrote:
Thinking about it, channel switch announcement IE can also be added in kernel the same way.
Hostapd will be informed once channel switch is done (counter reached 0) so it will update the new channel parameters.
This will make the code easier without the need for the counter offset being sent from hostapd to kernel.
would that not break the kernel if you run it with an older version of
hostapds, unless we add 2 APIs for this in parallel, which would be
undesirable ? I see your point but the current patchset makes the
feature aligned with what we already have. Also keep in mind that there
are !mac80211 drivers out there and hostapd can run on !linux systems.
So maybe channel switch flow will be more difficult to change now after
already integrated with many vendors/users.
But for BSS color, I really don’t see why it must go through hostapd.
Kernel can add the IE (after __ieee80211_beacon_add_tim()), handle
the counter decrement and notify hostapd with the new color once done.
I mean, _If_ we all agree this is a better design, than we shouldn’t follow the
Channel switch implementation.
What do you think ?
In the current setup hostapd creates the beacons, probe responses, the
IEs within and does the handling. Only TIM is done in the kernel as it
requires state which is not present inside hostapd. I am aware that many
closed source vendors put their whole supplicant into the kernel, yet
this is not how the current opensource design works, which is to do it
in the userspace, thus being able to share the functionality across
several wifi stacks and operating systems.
John
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
