This bug is a mix of smaller bugs. (Should I create a bug report for each?) At the university I have two wireless networks available from the same AP's. One of them ("guest-e-U") is open but just displays a help webpage. It has a broadcasted essid. The other network doesn't broadcast the essid ("e-U"), and requires wpa_supplicant for the authentication. Currentyl wpa_supplicant 0.5.7 doesn't honor the "scan_ssid=1" option (using ipw3945-1.2.0, krnel 2.6.20-r6), so always connects to the guest-e-U network, even if it's set for a low priority. Even if I manually select the network it never authenticates. For this to happen I have to do "iwconfig eth1 essid e-U enc open". Current baselayout doesn't do this even if I tell it to, which worked before 1.12.10 (my config should explain this better). As a workaround I've defined a post-up function that calls iwconfig, but it doesn't work all the time (seems to be wpa_supplicant's fault) and is somewhat ugly. The relevant configs go on annex. Should I supply any other info?
Created attachment 116645 [details] My wpa_supplicant config file fr eth1
Created attachment 116646 [details] My /etc/conf.d/net
Could you attach debug output from wpa_supplicant? Either add -dd to your options or run it manually with -dd.
I don't seem to get any debug output by adding -dd to wpa_supplicant_eth1. On the other hand, bringing net.eth1 down and starting wpa_supplicant by hand does work with the hidden essid! So it must be something with baselayout, wpa_supplicant behaves correctly!
Created attachment 116730 [details] The wpa_supplicant log This is the log file obtained by running wpa_supplicant -i eth1 -w -D wext -c /etc/wpa_supplicant/wpa_supplicant-eth1.conf -dd > wpa_log
Oh, forget the previous comment, I did a modprobe -r ipw3945 && modprobe ipw3945 and it automatically started net.eth1. So the post-up commands were called and it obvisously connected. I did another test removing the post-up function and this time it did connect to the guest network...
Created attachment 116731 [details] The relevant wpa_supplicant log This is the correct log from wpa_supplicant, this time without the post-up hack.
Hum this may be related to this bug from ipw3945: http://bughost.org/bugzilla/show_bug.cgi?id=972 I guess it may be a driver bug, but I believe the network scripts used to circumvent this issue - at least it worked before. Not sure if it's worth it though, more than half a month has passed since the last message in the intel bug tracker so maybe their solution is under way?
Ok, I found another workaround that doesn't involve using wireless-tools: Putting ap_scan=2 in the wpa config and just running "wpa_cli select_network 0" works, but I still need to manually select the network. I found that sometimes I have to select a different network (for instance the SSID='' network) and then reselect the SSID='e-U'. Running wpa_supplicant manually shows that with ap_scan=2 it tries to associate with SSID='e-U' (the first entry), but it keeps showing me this message and doesn't associate: <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
Ok, now I found something unusual!!! Still with ap_scan=2, starting the network normally (/etc/init.d/net.eth1 restart gives me lots of those <2>CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys messages in wpa_cli. The weird part: if I run "dhclient eth1" then wpa_supplicant suddenly associates with e-U!!! This is WEIRD, and something is broken. Maybe baselayout could run dhclient as right after wpa_supplicant is started, but this sounds like a hack...
Fixed in baselayout-2.0.0_alpha2
