[0/3] Support fallback if FT fails

Message

James Prestwood Aug. 22, 2023, 3:29 p.m. UTC

Its explained as well in the commit description, but we have
run into several cases where IWD continually fails to FT due to
the (only) AP rejecting it with "Invalid PMKID". It appears to
be due to APs failing to communicate current associations e.g.
after one is rebooted.

If IWD can manage to see another AP it will roam, but in cases
of poor coverage eventually the link gets so bad IWD will
disconnect and then successfully associate to the AP that was
rejecting it. This can take some time though and results in
many dropped frames and/or virtually no connectivity.

To try and remedy this we can instead fall back to reassociation
if FT fails with a specific status (53).

One caveat I can think of is there may be additional BSS to FT
to which this logic won't consider until the fallback/reassoc
also fails. This leaves out potential BSS's that could very well
have worked fine. I do think this is a tradeoff though, since
the first/best candidate likely still has the best signal/link
quailty. In addition reassociation is certainly better than
getting disconnected.

An alternative would be to attempt FT to all BSS's, then fall
back to reassociation although I could see this backfiring with
IWD connecting to a better but still poor BSS rather than a good
BSS that just hasn't gotten its act together quite yet.

James Prestwood (3):
  ft: track FT auth/action response status
  station: fall back to reassociation under certain FT failures
  auto-t: add fallback to reassociate test

 autotests/testPSK-roam/failed_roam_test.py |  70 ++++++++++-
 autotests/testPSK-roam/ft-psk-ccmp-1.conf  |   1 +
 autotests/testPSK-roam/ft-psk-ccmp-2.conf  |   1 +
 autotests/testPSK-roam/ft-psk-ccmp-3.conf  |   1 +
 src/ft.c                                   |  37 ++++--
 src/station.c                              | 129 +++++++++++++--------
 6 files changed, 180 insertions(+), 59 deletions(-)