No suitable APs about minibase

[arsv]

The message might be a bit misleading, it could not connect to the AP for some reason and there are no more matching APs left.

What kind of Wi-Fi device is this? If neither wsupp nor wifi write anything to stderr, chances are there's something wrong with the netlink commands. Maybe I could try reproducing it.

Current version of wsupp can report the reason why connection attempt was aborted, but those tend to not be particularly useful. Might be still worth adding to the client tool. I need to think how to output it well.

The majority of changes to minibase this summer were related to wsupp. Mostly to let it work with FullMAC drivers, but that was still a lot of changes.

[rofl0r]

This worked with minibase back in jan/feb this year

sounds like a perfect case for git bisect

[bkauler]

The laptop is an Acer Aspire1, model A114-31-C014. lsmod shows:

iwlwifi               217088  1 iwlmvm
cfg80211              311296  3 iwlmvm,iwlwifi,mac80211
rfkill                 24576  5 acer_wmi,bluetooth,cfg80211
r8169                  73728  0
realtek                20480  1

That is, iwlwifi kernel driver, and dmesg shows:

[   25.745716] iwlwifi 0000:03:00.0: Detected Intel(R) Dual Band Wireless AC 3168, REV=0x220
[   25.769913] iwlwifi 0000:03:00.0: base HW address: 48:a4:72:b9:3e:85
[   25.800411] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'

I am currently connected to the Internet on same laptop, same phone as hotspot, using NetworkManager (as used in Debian and other distros). dmesg shows:

[   43.157032] wlan0: authenticate with 04:79:70:48:e4:f3
[   43.159903] wlan0: send auth to 04:79:70:48:e4:f3 (try 1/3)
[   43.172753] wlan0: authenticated
[   43.174333] wlan0: associate with 04:79:70:48:e4:f3 (try 1/3)
[   43.202611] wlan0: RX AssocResp from 04:79:70:48:e4:f3 (capab=0x1631 status=0 aid=3)
[   43.205085] wlan0: associated
[   43.278033] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   43.294458] wlan0: Limiting TX power to 20 (20 - 0) dBm as advertised by 04:79:70:48:e4:f3

[arsv]

Interesting. I expected some exotic hardware, but iwlwifi is exactly what I'm working with for the most part. Looking at dmesg, the connection does succeed with no issues whatsoever. Most likely some sort of EAPOL issue then, which is really strange because the EAPOL code did not change.

I'm going to try running it against some Android APs a bit, maybe I'll figure it out. And I need to check failure handling paths, too. The plan was to let it report failed connection attempts in cases like this.

[bkauler]

Correcting an earlier statement: I have four laptops, and I am not 100% certain that this one was working with an earlier version of minibase. That was back in January/February, and perhaps I used one of the others when testing minibase.

[bkauler]

Ah ha, trying it today:

# wifi scan
wifi: scanning device wlan0
AP -59   6b  04:79:70:48:E4:F3  2CC  HUAWEINova2x *
AP -76  11b  18:90:D8:7A:2D:D1  2CC  Telstra7A2DCB
AP -78  11b  7A:30:D9:A5:25:60       Telstra Air
# wifi connect HUAWEINova2x
wifi: connected to 04:79:70:48:E4:F3

The fault might be what I am doing. Notice the "*" on the end, which was not there before. ...but that would be from yesterday, when I had entered the passphrase.
In which case your code might be fine, and it is my usage that needs fixing.
Though, it didn't work yesterday, so something seems to be wrong.

I am trying to do things manually, to understand the sequence, but that might not be the best approach with the way dhconf now works.

[arsv]

Regarding dhconf, try running it manually from a terminal and killing it with ^C. That's pretty much how it works now, interactively or not. Both ifmon and wsupp attempt to spawn it when link goes up and send SIGINT/SIGTERM/SIGHUP to the running process when link goes down. There's a short description of the signals involved in dhconf.8.

EAPOL issue still looks weird, it should not have saved the PSK without a successful connection. Anyway, I really need to get some better reporting there.