AP: Redesign of bandsteering.
hostapd now takes two arguemnts:
1) -L (request_logging_path): If set, per-MAC probe and associate requests will
be logged here, with the same timestamp format as before.
2) -S (steering_timestamp_path): If set, per-MAC probe requests here will
enable bandsteering. The duration for which bandsteering is active begins
when the first associate is rejected.
The intended use is that the -S argument of one hostapd instance will be the -L
argument of another. For example, if you wanted to bandsteer to 5GHz, you might
run the 2.4GHz hostapd instance with:
-L /tmp/wifi/steering/2.4 -S /tmp/wifi/steering/5
...and run the 5GHz instance with:
-L /tmp/wifi/steering/5
This design takes some bandsteering logic out of hostapd, giving users more
control. It also addresses the problem that some devices probe even when they
have WiFi turned off (meaning that the duration between probe and associate
requests may be arbitrary, rather than just a few seconds (as previously
assumed)).
There are also two bugfixes in this change:
1) The bandsteering code in handle_assoc() was previously executing
goto fail before all necessary arguments to the send_assoc_resp()
call directly after fail: were initialized. This has been fixed by
moving the bandsteering code down a few lines.
2) Bandsteering timestamp files were being created for the wrong
interface. This is now obsolete.
Change-Id: I52111598aab13cb99c59855b4c7e58c5615131e5
5 files changed
