I've linked to some forum troubleshooting in the URL, but basically, wpa_supplicant will not connect to a virtual AP. The router I am trying to connect to is running DD-WRT in repeater-bridge mode ( i.e. it connects wirelessly to upstream internet and broadcasts it's own SSID for others to connect ). Reproducible: Always Steps to Reproduce: 1. start laptop (net.eth1 starts with wpa_supplicant) 2. 3. Actual Results: Never connects to the virtual AP, which broadcasts it's SSID. Expected Results: Automatic association according to /etc/wpa_supplicant/wpa_supplicant.conf With wpa_supplicant stable, I can then run 'iwconfig eth1 essid cookies' and it will connect instantly. With wpa_supplicant-1, this is not the case. It seems my driver, wl.ko (broadcom-sta) does not support ap_scan=1 as I have found from my troubleshooting in the forums. This is irrelevant though as NetworkManager in Fedora connects without using this. My theory is that adding a 'force_ssid=1' option, or even just relaxing the SSID mismatch error and trusting the wpa_supplicant.conf should fix this.
Created attachment 321408 [details] wpa_supplicant-1 log
Hmm, this is interesting. My best guess would be to take this upstream, and ask them for help, since they know the inner workings of wpa_supplicant better than I do, and have the required hardware to test that driver, which I dont. It working on Fedora most likely is due to some patches (wpa_supplicant or kernel patches). I'm pretty sure this is a bug triggered by a combination of the driver and wpa_supplicant, since wpa_supplicant should work fine with hidden SSID's. Could I get you to try and contact the people behind the software, and ask them to help looking into it? - You can find their mailing list here: http://lists.shmoo.com/mailman/listinfo/hostap (It works better than having someone relaying messages between them and you) Another option, which might point out when the problem was introduced would be to bisect the code between 0.7.3 and 1.0, but I would suggest going to upstream first, and see what they say (just in case they know what is wrong, and how to fix it)
Ok, I conversed with someone on the hostap list and discovered that v1 works fine. It was adding the bssid= line during troubleshooting that prevents it from connecting by forcing the ESSID. After removing the bssid from the configuration, ap_scan=2 will connect to the VAP. I also made the suggestion that by using the bssid and ssid from the config file, it should be possible to connect to any network (hidden or virtual) with the results of an ap_scan=1, as the bssid of those types of networks is returned in the scan and the only thing unknown is the ssid, which is in the file. That would speed up association for anyone that currently has to use scan_ssid=1.
Thats great, I'll close this bug as upstream then :)
