Bugzilla – Bug 1024
Cannot connect to non-WPA AP after WPA connection and v.v.
Last modified: 2006-07-12 01:12:46
You need to log in before you can comment on or make changes to this bug.
After a successful WPA-PSK connection I cannot connect to a non-WPA AP anymore without reloading the driver. I get the following error message in the log: Apr 21 16:04:04 f24 kernel: ipw3945: U ipw_associate_network Association attempt [BSS]: 'open', channel 6, 802.11g [12], short[:short], enc=off. Apr 21 16:04:04 f24 kernel: ipw3945: U ipw_associate_network Beacon interval for the network is 100 Apr 21 16:04:04 f24 kernel: ipw3945: U ipw_queue_tx_hcmd Sending command DAEMON (#10), seq: 0x046D, 48 bytes* at 109[13]:4 Apr 21 16:04:04 f24 kernel: ipw3945: U ipw_send_rx_config Returned from ipw_send_daemon_cmd. Apr 21 16:04:04 f24 kernel: ipw3945: U ipw_add_station Adding STA ID 0: 00:0b:86:c2:28:00 Apr 21 16:04:04 f24 kernel: ipw3945: U ipw_queue_tx_hcmd Sending command ADD_STA (#18), seq: 0x046E, 68 bytes at 110[14]:4 Apr 21 16:04:04 f24 kernel: ipw3945: U ipw_send_add_station REPLY_ADD_STA PASSED Apr 21 16:04:04 f24 kernel: ipw3945: U ipw_queue_tx_hcmd Sending command RATE_SCALE (#47), seq: 0x046F, 56 bytes at 111[15]:4 Apr 21 16:04:04 f24 kernel: ipw3945: U ipw_queue_tx_hcmd Sending command RATE_SCALE (#47), seq: 0x0470, 56 bytes at 112[16]:4 Apr 21 16:04:04 f24 kernel: ipw3945: U ipw_associate_network associating: 'open' 00:0b:86:c2:28:00 Apr 21 16:04:04 f24 kernel: ipw3945: I ipw_handle_auth auth frame algorithm 0 transaction 2 status 0 Apr 21 16:04:04 f24 kernel: ipw3945: I ipw_handle_assoc_response association failed: 'open' 00:0b:86:c2:28:00 Reason: Cannot support all requested capabilities in the Capability information field (10) After reloading the driver I can connect to 'open' without problems, but then not to my WPA-PSK AP again. I used wpa_supplicant 0.4.8 with ap_scan=1 for both connections.
Bump to P1.
Test environment: ipw3945-1.0.2, ieee-1.1.13,ucode-1.13,deamon-1.7.18,kernel-2.6.15.3, AP-asus(WPA),Linksys(open mode) I can't reproduce this bug in my environment. My steps: %load the driver %associate to WPA-PSK ap %ping --> verify all the packets received. %disconnect with WPA-PSK AP %associate to no-WPA ap(linksys) %iwconfig -->verify associated with linksys I can associate DUT with AP without reloading the driver &V.V .
I also encounter the problem when using ipw3945-1.0.2 and ieee-1.1.13. I'm using kernel 2.6.16. What wpa_supplicant version did you use?
I tested on ipw3945-1.0.3 and still can't reproduce this problem. My wpa_supplicant is 0.4.6 .
Hi Joachim, Would you please apply the following the patch and attach the debug log? And what are the configs of your non-WPA and WPA APs, i.e., 11b/11g, channel, short preamble/long preamble ...? diff -urp ipw3945-1.0.3/ipw3945.c ipw3945-1.0.3-assoc/ipw3945.c --- ipw3945-1.0.3/ipw3945.c 2006-05-03 08:28:38.000000000 +0800 +++ ipw3945-1.0.3-assoc/ipw3945.c 2006-05-09 16:56:24.000000000 +0800 @@ -3718,6 +3718,9 @@ static int ipw_fill_association_req(stru if (priv->config & CFG_PREAMBLE_LONG) frame->capability &= ~WLAN_CAPABILITY_SHORT_PREAMBLE; + printk("assoc request capability: 0x%x\n", priv->assoc_request.capability); + printk("frame capability: 0x%x\n", frame->capability); + frame->listen_interval = 10; info_element = frame->info_element;
May 9 11:30:20 linux kernel: ipw3945: U ipw_associate_network associating: 'onenet' 00:0b:86:c2:11:e0 May 9 11:30:20 linux kernel: ipw3945: I ipw_handle_auth auth frame algorithm 0 transaction 2 status 0 May 9 11:30:20 linux kernel: assoc request capability: 0x21 May 9 11:30:20 linux kernel: frame capability: 0x21 May 9 11:30:20 linux kernel: ipw3945: I ipw_handle_assoc_response association failed: 'onenet' 00:0b:86:c2:11:e0 Reason: Cannot support all requested capabilities in the Capability information field (10)
Sorry for not making it clear. Would you please attach the log for the following cases: 1. wpa -> non-wpa (both the logs for the successful association when first using WPA, and the failed case when changing to non-WPA) 2. non-wpa -> wpa 3. successful association to the open AP after loading the driver Thanks, Hong
Created an attachment (id=806) [details] Log of successful assocation to open AP
Created an attachment (id=807) [details] Log of successful assocation to WPA-PSK AP
Created an attachment (id=808) [details] Log of failed association to open AP after WPA connection
Created an attachment (id=809) [details] Log of failed association to WPA-PSK AP after unencrypted connection In that case wpa_supplicant does not find the access point in the scan results (at least, it does not select it), so there is no association all.
Created an attachment (id=810) [details] Dump auth and assoc request frames Can you apply the attached patch and capture the debug logs during the successful association to the open network, and then the unsuccessful association to the open network after you have associated to the WPA-PSK AP. The patch will dump the auth frame received from the AP and the association request frame being sent to the AP. Thanks, James
Created an attachment (id=811) [details] Dumped frames of successful association
Created an attachment (id=812) [details] Dumped frames of failed association In case that's important: The access point is an Aruba Networks AP70, controlled by an Aruba Networks Mobility Controller 2400.
Created an attachment (id=813) [details] patch to try
change bug status
The patches fixes the problem here. Thanks!
Sorry, but I have to reopen this bug. The patch fixes only association after WPA has been used, but using WPA after a WEP connection still does not work. It seems CAP_PRIVACY_ON flag is not set in that case. I'll attach the logs.
Created an attachment (id=826) [details] Debug messages of success association
Created an attachment (id=827) [details] Debug messages of failed association after WEP connection
FYI: It works when enabling the disabled code at line 15400 ff in shim__set_security().
Ok, it nearly works. It does not work when using wpa_supplicant with ap_scan=1. The log shows the driver still being locked to the old SSID and therefore does not return the right SSID (I used a hidden one) in the scan results. I've added "priv->config &= ~CFG_STATIC_ESSID;" to ipw_disassociate(), which fixes the problem for me. I don't know whether it's a sane way, though.
Created an attachment (id=831) [details] debug patch
(In reply to comment #22) > I've added > "priv->config &= ~CFG_STATIC_ESSID;" to ipw_disassociate(), which fixes the > problem for me. I don't know whether it's a sane way, though. This may leaves the roaming functionality not working. From the debug log, we are suspecting that other processes are modifying the secrutiy option of the driver cocurrently with the second wpa_supplicant which are trying to operating with the wpa-psk-hidden network. would you please: 1. manually test the case (not using the ifup ifdown scripts) to see if the problem exists? 2. apply the debug patch and provide the log
This indeed breaks roaming. I've repeated the test without using ifup, I just ran 'iwconfig eth1 essid onenet' and called wpa_supplicant configured for SSID 'wpa-psk-hidden' directly afterwards. The log looks equal to me, but I will attach it, of course.
Created an attachment (id=832) [details] Debug messages with patch (attachement 831) applied
Sorry, I accidentally used SSID 'psk-hidden' while generating the log, correct would have been 'wpa-psk-hidden'. I have re-tested it with wpa-psk-hidden, but the log messages did not change (AP still does not show up in the scan results). I can attach the log anyway, if you wish.
Created an attachment (id=833) [details] patch to try
(In reply to comment #25) > ran 'iwconfig eth1 essid onenet' and called wpa_supplicant configured for > SSID > 'wpa-psk-hidden' directly afterwards. The log looks equal to me, but I will > attach it, of course. This is another problem. This problem is caused by scanning while associated. You are associated with "onenet" when starting wpa_supplicant trying to associate with another network. The driver can't find the network when performing scan while associated. Please apply the patch (id=833) and use "iwconfig eth1 essid off" before starting wpa_supplicant. Thanks, Hong
When calling "iwconfig eth1 essid off" before running wpa_supplicant, it even works without the patch. Is there any reason why direct scanning shall not work when associated?
(In reply to comment #30) > When calling "iwconfig eth1 essid off" before running wpa_supplicant, it even > works without the patch. Is there any reason why direct scanning shall not work > when associated? When associated, you can't leave the associated channel too long or you will lose beacons/data. So when scanning while associated, the dwell time on the being scanned channel may be not enough. I think for this problem, document it should be enough: "iwconfig essid off" before you attempt to associate with another AP while associated.