wpa_supplicant will fire new scans as needed when it fails to find its own preferred networks in the results. We were breaking way too early on the first results, which caused us to prematurely announce failure, while, in fact, wpa_supplicant was dutifully working hard in the background to actually Do It!
Noticed on IPv6-aware platforms, because they manage to get assigned a valid and sane IPv6 somehow (me no speak network!), which meant our frontend thought isConnected was true, because: hey, an IP! (and, for funsies, you could then SSH over said address and call obtain-ip.sh manually to "fix" it for IPv4 plebs).
Fix it by actually iterating on the event queue in the order it came in, matching the amount of started/finished/expected scans, and waiting until there's no longer any pending data to assume success. In practice, we mostly always wait until CTRL-EVENT-CONNECTED now.
wpa_supplicant will fire new scans as needed when it fails to find its own preferred networks in the results. We were breaking way too early on the first results, which caused us to prematurely announce failure, while, in fact, wpa_supplicant was dutifully working hard in the background to actually Do It!
Noticed on IPv6-aware platforms, because they manage to get assigned a valid and sane IPv6 somehow (me no speak network!), which meant our frontend thought isConnected was true, because: hey, an IP! (and, for funsies, you could then SSH over said address and call obtain-ip.sh manually to "fix" it for IPv4 plebs).
Fix it by actually iterating on the event queue in the order it came in, matching the amount of started/finished/expected scans, and waiting until there's no longer any pending data to assume success. In practice, we mostly always wait until
CTRL-EVENT-CONNECTED
now.TL;DR: Make connecting to Wi-Fi reliable.
This change is