Bugzilla – Bug 629
scan_ssid=1 results in 'ioctl[SIOCSIWSCAN{,EXT}]: Operation not supported'
Last modified: 2005-10-09 11:20:29
You need to log in before you can comment on or make changes to this bug.
I'm can't get wpa_supplicant to automatically associate to access points that require scan_ssid=1 in wpa_supplicant.conf. (Ie, access points that do not broadcast their SSID.) I have a wpa_supplicant configuration like this: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 ap_scan=1 network={ scan_ssid=1 ssid="myssid" proto=WPA key_mgmt=WPA-PSK pairwise=CCMP TKIP group=CCMP TKIP WEP104 WEP40 psk="mypsk" priority=5 } [...] And wpa_supplicant just goes "ioctl[SIOCSIWSCAN{,EXT}]: Operation not supported Failed to initiate AP scan." over and over, and never manages to associate. If I run "iwconfig eth0 essid myssid", wpa_supplicant immediately associates/authenticates. When running wpa_supplicant with the -d option it shows that it is when wpa_supplicant tries to scan for specific ssids (those networks that have scan_ssid=1) that the above error appears. It says something like: Setting scan request: 5 sec 0 usec Starting AP scan (specific SSID) Scan SSID - hexdump_ascii(len=5): x x x x x myssid ioctl[SIOCSIWSCAN{,EXT}]: Operation not supported Failed to initiate AP scan. Is this a known issue? Can it be solved? ipw2100 works well on my system other than this (including WPA1/2), it's just that it can't associate without manual intervention.
This bug also exists on ipw2200.
I've workarounded it in our wpa_supplicant package in Mandriva with this patch : http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/wpa_supplicant/wpa_supplicant-0.3.8-hidden.patch?rev=1.1&content-type=text/x-cvsweb-markup It simply set the ssid before performing the scan. Probably not the best solution, but it can be used until SIOCSIWSCANEXT is supported.
Created an attachment (id=348) [details] patch to try Thanks for providing the workaround. Can you try this patch for ipw2100 resolve the problem? BTW, I've submitted bug 461 as feature request for WE 18 support.
(In reply to comment #3) > Thanks for providing the workaround. Can you try this patch for ipw2100 resolve > the problem? BTW, I've submitted bug 461 as feature request for WE 18 support. I'd love to try the patch immediately, as that's so far the only thing holding me back from full WLAN roaming. However, I only have ipw2200. Is it possible to create a patch for that driver as well? I'd try it out within 24 hours.
Created an attachment (id=378) [details] patch for ipw2200 (from Olivier Blin)
(In reply to comment #5) > Created an attachment (id=378) [edit] [details] > patch for ipw2200 (from Olivier Blin) Many thanks. I tried applying the patch to the 1.0.3 sources, but that failed (Hunk #1 failed). I don't know why it failed, the source looks quite much like the patch file. Then I applied the patch manually, adding the one added line of the diff to my source file; That resulted in a broken compile, where make stopped when some symbol in the patched file was undeclared (compiling the unpatched sources works). I can give more detailed logs of the failures, but at the moment I think it would suffice to know if I'm using the correct sources? I'm using the 1.0.3 from the website. I couldn't find any CVS repositories or nightly packages, and the SF CVS seems to be empty. Any ideas?
Created an attachment (id=382) [details] Please try this one
(In reply to comment #7) > Created an attachment (id=382) [edit] [details] > Please try this one I'm sorry, it didn't change anything. Here is wpa_supplicant's output: Starting AP scan (specific SSID) Scan SSID - hexdump_ascii(len=6): 69 6e 66 76 70 6e infvpn ioctl[SIOCSIWSCAN{,EXT}]: Operation not supported Failed to initiate AP scan. I checked explicitly if the patch changed the source file, and also changed the version so I could check the dmesg output for my patched version. So I hope nothing is wrong on my part. I'm still up for more debugging though, it would be great if this worked. :D
Sorry, I just found this patch doesn't work for old kernels don't support SIOCSIWSCANEXT ioctl. I'm convinced changing wpa_supplicant ipw module is the better solution. I'll submit below patch to wpa_supplicant. http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/wpa_supplicant/wpa_supplicant-0.3.8-hidden.patch?rev=1.1&content-type=text/x-cvsweb-markup
Yep, your patch for the ipw2200 driver looks correct, but it needs WE-18 support in the kernel, mainly the SIOCSIWSCANEXT ioctl definition in net/core/wireless.c See http://lists.shmoo.com/pipermail/hostap/2004-August/007820.html For now, it should be fine to do this in wpa_supplicant, but this is not ipw specific, it applies for any driver relying on the kernel wireless layer. Here's the patch I use now in Mandriva's wpa_supplicant package (it handles the essid setting in the wext driver, without modifying the error return code so that a new scan can be performed) : http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/wpa_supplicant/wpa_supplicant-0.3.8-hidden.patch?rev=1.3&content-type=text/x-cvsweb-markup
I got respond from Jouni: the patch may cause unexpected behavior since the scan command is not expected to break current association. We should use ap_scan=2 to resolve the problem. It works for me, how about you?
Yeah it does work... weird, I remember trying that configuration once, but I guess that was with the original Ubuntu ipw2200 drivers (v0.19) which had a lot less features and probably didn't work. Or I applied it in a wrong way. However, ap_scan=2 uses only the first configured network, and so doesn't allow wireless roaming. This makes the whole point of using wpa_supplicant void for me, because I don't have WPA on any network. I just want automatic scanning/association and key setting. For more info on ap_scan=2 and multiple networks, see http://hostap.epitest.fi/bugz/show_bug.cgi?id=16 Thanks for bringing so much insight into this issue though. :)
From scrub: logics_sbux in regard to this bug, we'll need to get we18 support integrated and tested w/ ipw2100 logics_sbux and then we can set as fixed w/ the resolution to move to we18 and the version if ieee80211 subsystem and ipw2100 combination that supports it
Hong, please mark the bug as fixed after your we18 is merged.
we-18 patch is merged in the git tree
we-18 have been added in ipw2100-1.1.2. mark as verified.