tree 674988e0070046dd05925ec9565a10ba3d0b5931
parent 0c5cffc9af83498a2265ed705b639a935dfd171f
author Richard Frankel <rofrankel@google.com> 1426637660 -0400
committer Richard Frankel <rofrankel@google.com> 1427254076 -0400

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