wpa_supplicant will not connect to VAP: skip - SSID mismatch
Kyle Evans
kevans
Mon Aug 20 08:41:44 PDT 2012
> Have you verified that this driver works with ap_scan=2? It does indeed
> "force" the SSID in the sense that it asks the driver to select the BSS
> rather than assuming the network is going to be visible in the scan
> results.
Yes, it will connect with ap_scan=2.
I need to correct a statement I made earlier about v1 not working where
v0.7.3 did. I found that it was the use of bssid= that caused it to not
connect when forcing the essid. I triple checked that the bssid was
correct and matched what the wpa_supplicant log shows in the scan
results, which is where the ID was copied from. For some reason when
configuring the bssid, neither v0.7.3, nor v1 will connect, either via
ap_scan=2 or with iwconfig. I did a lot of testing on this and do not
understand it. Seems like a bug as far as I can tell.
> In this particular case, the driver should really be enhanced to support
> scans for a specific SSID if you want to use ap_scan=1. It sounds like
> it expects ap_scan=2 style operations.
I agree that the driver should have a feature parity with other linux
drivers. I have sent Broadcom feedback. Aside from my personal pitfall
though, wpa_supplicant could be improved significantly when dealing with
ambiguous networks. scan_ssid=1 takes a fair amount of time and if one
connects to several networks that require it's use, startup is
significantly slowed down. ap_scan=2 is not much better. Matching the
bssid with these ambiguous networks in an ap_1 scan, then connecting in
an ap_2 manner would cut all of that time out and make wpa_supplicant a
more robust application.
At any rate, thank you for the conversation. Those extra tests that I
ran unravelled the truth and supplicant is now connecting to a VAP
thanks to ap_scan=2.
-Kyle
More information about the Hostap
mailing list