wpa_supplicant will not connect to VAP: skip - SSID mismatch

[Kyle Evans]

> 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