wpa_supplicant will not connect to VAP: skip - SSID mismatch

[Dan Williams]

On Mon, 2012-08-20 at 11:41 -0400, Kyle Evans wrote:
> > 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.

Part of the issue here is WEXT, which isn't as flexible as the new
nl80211 API that kernel wifi drivers use.  If the driver is written
correctly, and isn't limited to using older kernel APIs (ie, WEXT),
there shouldn't be a problem with scan_ssid=1/ap_scan=1.  And indeed,
there isn't with most of the in-kernel drivers that use nl80211.  But
given that wl.o isn't using the right kernel APIs, I'm not surprised
these problems occur.

Dan

> 
> 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
> _______________________________________________
> HostAP mailing list
> HostAP at lists.shmoo.com
> http://lists.shmoo.com/mailman/listinfo/hostap