Wpa_supplicant: scan_ssid=1 needed only after 2.6.29 kernel upgrade?

Question

Like many others, I ran into wireless networking issues after the upgrade to kernel 2.6.29. Specifically, I use iwl3945 and experienced errors when attempting to connect to WPA-encrypted networks with hidden SSIDs via my usual netcfg profiles.
As described here, I finally found a solution to my problem. Like SubGothius in this thread, I found that that "magic" fix was to ensure that the network parameter scan_ssid=1 was used when attempting to connect to my network. Because the temporary wpa_supplicant config created by netcfg does not include this parameter, I created a small patch (see first thread referenced above) to use that parameter whenever the SCAN option is not enabled for a network profile.
As I said, I have fixed the error; however, now I am (extremely) curious. Here is a rundown of what I have witnessed:
- Before the kernel upgrade (2.6.29), I was able to connect to WPA-encrypted networks with hidden SSIDs successfully. (I use two different such networks.)
- After the kernel upgrade, I was unable to connect to these networks. netcfg returned "Network unavailable" errors (for at least one of the two networks I tried).
- I was able to connect manually (i.e., with ifconfig, iwlconfig, and wpa_supplicant); however, doing so required that I add the scan_ssid=1 parameter to my configuration for the network.
- I looked into the issue, and installed crda (as many users recommend). (I can't recall for sure, but I think that this led to netcfg changing to an "Unable to connect"-type error.)
- Following the advice in this thread, I created a "wpa-config" netcfg profile that did work; however, I wanted to use my normal profiles.
- After connecting with my wpa-config profile and then disconnecting, I could connect with my normal profile once (i.e., after disconnecting, I could no longer reconnect with my normal profile unless I again connected with the wpa-config profile and disconnected).
- I looked through the netcfg scripts and found that it generates a temporary config file for wpa_supplicant (for me, /tmp/wpa.wlan0) using wpa_passphrase, thus not including any value at all for scan_ssid.
- I made some modifications to the netcfg scripts, with the result being a netcfg that will include scan_ssid=1 in certain situations (see above). Using this modified netcfg, I can connect to the network.
Does anyone know why I was able to use netcfg successfully before the upgrade (i.e., without it needing scan_ssid=1 set)? I've seen (here) that others using iwl3945 have resolved the issue simply by installing and configuring crda, and it appears that (in that one example, at least), the solution worked for a network profile using SECURITY="wpa" (rather than "wpa-config").
If there's a more proper solution to my problem, please post it; otherwise, I'd just like to know why this need for scan_ssid=1 arose only after the kernel upgrade (and does not seem to affect all iwl3945 users).
Thanks!
Last edited by ssjlegendx (2009-04-20 23:26:36)

Answer 1

Like many others, I ran into wireless networking issues after the upgrade to kernel 2.6.29. Specifically, I use iwl3945 and experienced errors when attempting to connect to WPA-encrypted networks with hidden SSIDs via my usual netcfg profiles.
As described here, I finally found a solution to my problem. Like SubGothius in this thread, I found that that "magic" fix was to ensure that the network parameter scan_ssid=1 was used when attempting to connect to my network. Because the temporary wpa_supplicant config created by netcfg does not include this parameter, I created a small patch (see first thread referenced above) to use that parameter whenever the SCAN option is not enabled for a network profile.
As I said, I have fixed the error; however, now I am (extremely) curious. Here is a rundown of what I have witnessed:
- Before the kernel upgrade (2.6.29), I was able to connect to WPA-encrypted networks with hidden SSIDs successfully. (I use two different such networks.)
- After the kernel upgrade, I was unable to connect to these networks. netcfg returned "Network unavailable" errors (for at least one of the two networks I tried).
- I was able to connect manually (i.e., with ifconfig, iwlconfig, and wpa_supplicant); however, doing so required that I add the scan_ssid=1 parameter to my configuration for the network.
- I looked into the issue, and installed crda (as many users recommend). (I can't recall for sure, but I think that this led to netcfg changing to an "Unable to connect"-type error.)
- Following the advice in this thread, I created a "wpa-config" netcfg profile that did work; however, I wanted to use my normal profiles.
- After connecting with my wpa-config profile and then disconnecting, I could connect with my normal profile once (i.e., after disconnecting, I could no longer reconnect with my normal profile unless I again connected with the wpa-config profile and disconnected).
- I looked through the netcfg scripts and found that it generates a temporary config file for wpa_supplicant (for me, /tmp/wpa.wlan0) using wpa_passphrase, thus not including any value at all for scan_ssid.
- I made some modifications to the netcfg scripts, with the result being a netcfg that will include scan_ssid=1 in certain situations (see above). Using this modified netcfg, I can connect to the network.
Does anyone know why I was able to use netcfg successfully before the upgrade (i.e., without it needing scan_ssid=1 set)? I've seen (here) that others using iwl3945 have resolved the issue simply by installing and configuring crda, and it appears that (in that one example, at least), the solution worked for a network profile using SECURITY="wpa" (rather than "wpa-config").
If there's a more proper solution to my problem, please post it; otherwise, I'd just like to know why this need for scan_ssid=1 arose only after the kernel upgrade (and does not seem to affect all iwl3945 users).
Thanks!
Last edited by ssjlegendx (2009-04-20 23:26:36)