[Bug 546706] New: I often lose WiFi connection
http://bugzilla.novell.com/show_bug.cgi?id=546706 Summary: I often lose WiFi connection Classification: openSUSE Product: openSUSE 11.2 Version: Milestone 8 Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Mobile Devices AssignedTo: mobile-bugs@forge.provo.novell.com ReportedBy: nice@titanic.nyme.hu QAContact: qa@suse.de Found By: --- User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; hu-HU; rv:1.9.1.3) Gecko/20090909 SUSE/3.5.3-2.1 Firefox/3.5.3 For various reasons wpa_supplicant sometimes has to rekey, roam or reconnect. Sometimes it cannot reconnect, and thus network connection gets lost. Anyway wpa_supplicant seems to be able to connect slower (maybe only dhclient is slow) and lose connection easier than Windows. What I experience is that sometimes I have to reconnect manually despite that there is no high load on the AP, and signal quality is good. Here's an example from /var/log/wpa_supplicant.log depicting the losing of the connection: Trying to associate with 00:1d:70:27:6d:a1 (SSID='EIK2' freq=5220 MHz) Association request to the driver failed CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Associated with 00:1d:70:27:6d:a1 Authentication with 00:1d:70:27:6d:a1 timed out. Failed to initiate AP scan. CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys CTRL-EVENT-SCAN-RESULTS Trying to associate with 00:1d:70:93:05:b1 (SSID='EIK2' freq=2412 MHz) Association request to the driver failed Associated with 00:1d:70:93:05:b1 Authentication with 00:1d:70:93:05:b1 timed out. Failed to initiate AP scan. CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys Reproducible: Always -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c1
--- Comment #1 from Tamás Németh
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c2
--- Comment #2 from Tamás Németh
http://bugzilla.novell.com/show_bug.cgi?id=546706
Uwe Drechsel
http://bugzilla.novell.com/show_bug.cgi?id=546706
User vbotka@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c3
Vladimir Botka
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c4
--- Comment #4 from Tamás Németh
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c5
--- Comment #5 from Tamás Németh
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c6
Tamás Németh
http://bugzilla.novell.com/show_bug.cgi?id=546706
User vbotka@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c7
Vladimir Botka
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c8
--- Comment #8 from Tamás Németh
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c9
--- Comment #9 from Tamás Németh
Thank you for the report. There is a problem to find the AP. From the wpa_supplicant log many problems can be seen [1]. Your network is controlled with the Network Manager. To narrow the problem would it be possible to switch the network control to "traditional ifup/ifdown" method via Yast ? Fill the wlan configuration for the AP you want to connect to. Do you still observe the disconnections ?
I assume, some more tests are needed. Now I configured my network to be of ifup/ifdown type, copied the commend lines of wpa_supplicant & dhcpcd from /proc/<PID>/cmdline, I also copied the configuration file of wpa_supplicant, then stopped networking ad firewall, and started everything manually in order to see the output. I walked away from the AP to lose the signal for a few minutes. When I returned, wpa_supplicant was able to restore the connection: CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS Trying to associate with 00:1d:70:93:05:b1 (SSID='EIK2' freq=2412 MHz) Association request to the driver failed CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully (based on lower layer success) WPA: EAPOL-Key Replay Counter did not increase - dropping packet Associated with 00:1d:70:93:05:b1 Authentication with 00:1d:70:93:05:b1 timed out. CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys CTRL-EVENT-SCAN-RESULTS ioctl[SIOCSIWSCAN]: Device or resource busy Failed to initiate AP scan. CTRL-EVENT-SCAN-RESULTS CTRL-EVENT-SCAN-RESULTS Trying to associate with 00:1d:70:27:6d:a1 (SSID='EIK2' freq=5220 MHz) Association request to the driver failed Associated with 00:1d:70:27:6d:a1 Authentication with 00:1d:70:27:6d:a1 timed out. CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys CTRL-EVENT-SCAN-RESULTS Trying to associate with 00:1d:70:93:05:b1 (SSID='EIK2' freq=2412 MHz) Association request to the driver failed Associated with 00:1d:70:93:05:b1 CTRL-EVENT-EAP-STARTED EAP authentication started CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0) EAP-MSCHAPV2: Authentication succeeded EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully WPA: Key negotiation completed with 00:1d:70:93:05:b1 [PTK=CCMP GTK=TKIP] CTRL-EVENT-CONNECTED - Connection to 00:1d:70:93:05:b1 completed (reauth) [id=0 id_str=] It seems to be fairly stable, but NetworkManager was also almost usable (but not a perfect as I expected, and I observed how Windows clients behave). BTW, the wpa_supplicant.conf I get from YaST, and used in this test was the following: ctrl_interface=/var/run/wpa_supplicant network={ scan_ssid=1 ssid="EIK2" key_mgmt=WPA-EAP eap=PEAP identity="nice" password="*************" ca_cert="/etc/ssl/certs/nyme.pem" phase1="peaplabel=0" } -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c10
Tamás Németh
http://bugzilla.novell.com/show_bug.cgi?id=546706
User vbotka@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c11
Vladimir Botka
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c12
--- Comment #12 from Tamás Németh
There are still bugs in the Network Manager (NM). At present I am working on this one [1]
I'm not authorized to access bug #547572 . I would like to provide you with the hints how to get more
information. For example you can switch the running wpa_supplicant into the debug mode by sending the signal SIGUSR1 to the wpa_supplicant process. This and more info is described in an articel "Tracking down wireless problems" [2].
I've read that, and as far as I can remember I ried everything reasonable except sending that signal. I will try that later.
Btw. RC1 is released.
I'm already using it. Thank you for developing openSUSE. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c13
--- Comment #13 from Tamás Németh
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c14
Tamás Németh
http://bugzilla.novell.com/show_bug.cgi?id=546706
User vbotka@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c15
Vladimir Botka
-Unsuccessful connection attempt
TX EAPOL: dst=00:1d:70:27:6d:a1 EAPOL: SUPP_BE entering state RECEIVE wpa_driver_wext_disassociate No keys have been configured - skip key clearing State: ASSOCIATED -> DISCONNECTED
-Succesful connection attempt
TX EAPOL: dst=00:1d:70:27:6d:a1 EAPOL: SUPP_BE entering state RECEIVE RX EAPOL from 00:1d:70:27:6d:a1 EAPOL: Received EAP-Packet frame EAPOL: SUPP_BE entering state REQUEST
-Working and losing connection
TX EAPOL: dst=00:1d:70:27:6d:a1 EAPOL: SUPP_BE entering state RECEIVE RTM_NEWLINK: operstate=0 ifi_flags=0x11003 ([UP][LOWER_UP]) RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added EAPOL: startWhen --> 0 wpa_driver_wext_disassociate No keys have been configured - skip key clearing State: ASSOCIATED -> DISCONNECTED -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c16
--- Comment #16 from Tamás Németh
(In reply to comment #13)
Thank yo for the details. I see that the SSID='EIK2' is assigned to 2 APs. Could you switch one of them off, or even better assign different SSID to them ?
I will do that tomorrow, but some more info: -The test, described in comment #13 was carried out with a NetworkManager controlled wpa_supplicant process, not a standalone one as before. I think I forgot to mention this. -Physically EIK2 is served by a single AP, but... That AP is a Cisco Aironet 1250 which has two radio interfaces: a 2.4GHz one, and a 5GHz one. Both interfaces run on one single channel, but both interfaces serve more SSIDs. It means that there are multiple SSIDs operating on the same frequency, and every SSID is operating simultaneously on two different channels (an 802.11g channel and an 802.11a) channel. Moreover, both interfaces are 802.11n capable, currently working in some pre-standard 802.11n mode. And to make it even more complex, there are 7 fully operating Cisco Aironet 1250 APs in the building and at least 2 or 3 is within the reach of my notebook, not to mention a few ones which can be seen by my machine but are in nearby buildings. I can limit EIK2 (which is an SSID for IT sysadmins) to a sinle frequency, but I can not remove other SSIDs from that frequency. Anyway, bare wpa_supplicand seemed to be able to easily cope with this situation, and Windows clients are also able to do that. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=546706
User vbotka@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c17
--- Comment #17 from Vladimir Botka
And to make it even more complex, there are 7 fully operating Cisco Aironet 1250 APs in the building and at least 2 or 3 is within the reach of my notebook, not to mention a few ones which can be seen by my machine but are in nearby buildings.
Anyway, bare wpa_supplicand seemed to be able to easily cope with this situation, and Windows clients are also able to do that.
Interesting test-case. The wpa_supplicant disconnects when it does not receive a response from the AP, but this is not very usual with Cisco. To see what is really going on we will have to see the tcpdump of the packets and check the debug output of the iwl3945 driver. If you have another box with wlan card you can try to get the test file [1] and analyze the traffic with wireshark [2]. The tcpdump file can grow pretty fast. It is good idea to have dmesg and wpa_supplicant log either. Set the iwl3945 debug output [3] and reload the iwl3845. Set wpa_supplicant debug output. Truncate the logs [4]. Synchronize the clocks on all boxes with ntp. Post the tarball with "ifconfig","iwlist scan", "iwconfig", /var/log/messages, /var/log/wpa_supplicant and tcpdump test file. If this file is too big for Bugzilla to swallow post it anywhere else. [1] iw dev wlan0 del #change the insterface iw phy phy0 interface add mon0 type monitor iwconfig mon0 channel 5 #change the channel iw dev mon0 info ifconfig mon0 up tcpdump -i mon0 -w test -s 0 [2] wireshark filter example (((wlan.sa contains 19:6b:36) && (wlan.da contains AA:C9:90)) || ((wlan.da contains 19:6b:36) && (wlan.sa contains AA:C9:90))) [3] # cat modprobe.d/iwl3945 options iwl3945 debug=0x43fff [4] #logrotate -f /etc/logrotate.conf -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c18
--- Comment #18 from Tamás Németh
(In reply to comment #16)
Interesting test-case.
The same SSID on multiple frequencies&channels (and on multiple APs) is necessary for roaming. Multiple SSIDs on the same channel (but on the same AP) may seem be more disturbing, but I think it's not much different from the case where where two APs try to occupy the same channel (in fact even better, because in this case the transmission from APs of the SSIDs never collides). I'm not a WiFi expert - like you - but I think 802.11 stuff has to be able to handle this situation perfectly. Sorry for saying that, but I will only be able to carry out on the next week the test requested by you, because tomorrow is a national holiday in Hungary, and I have to finish some other tasks today. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c19
--- Comment #19 from Tamás Németh
(In reply to comment #16)
And to make it even more complex, there are 7 fully operating Cisco Aironet 1250 APs in the building and at least 2 or 3 is within the reach of my notebook, not to mention a few ones which can be seen by my machine but are in nearby buildings.
Anyway, bare wpa_supplicand seemed to be able to easily cope with this situation, and Windows clients are also able to do that.
Interesting test-case. The wpa_supplicant disconnects when it does not receive a response from the AP, but this is not very usual with Cisco. To see what is really going on we will have to see the tcpdump of the packets and check the debug output of the iwl3945 driver. If you have another box with wlan card you can try to get the test file [1] and analyze the traffic with wireshark [2]. The tcpdump file can grow pretty fast. It is good idea to have dmesg and wpa_supplicant log either. Set the iwl3945 debug output [3] and reload the iwl3845. Set wpa_supplicant debug output. Truncate the logs [4]. Synchronize the clocks on all boxes with ntp.
Post the tarball with "ifconfig","iwlist scan", "iwconfig", /var/log/messages, /var/log/wpa_supplicant and tcpdump test file. If this file is too big for Bugzilla to swallow post it anywhere else.
[1] iw dev wlan0 del #change the insterface iw phy phy0 interface add mon0 type monitor iwconfig mon0 channel 5 #change the channel iw dev mon0 info ifconfig mon0 up tcpdump -i mon0 -w test -s 0
[2] wireshark filter example (((wlan.sa contains 19:6b:36) && (wlan.da contains AA:C9:90)) || ((wlan.da contains 19:6b:36) && (wlan.sa contains AA:C9:90)))
[3] # cat modprobe.d/iwl3945 options iwl3945 debug=0x43fff
[4] #logrotate -f /etc/logrotate.conf
OK, I found another machine, but that I cannot issue the commands you wrote me, because it always gives the error message "nl80211 not found". Sorry for saying that but I have so much work in the last months (in fact years), that I'm exhausted now beyond my capacity. I won't be able to carry out this test in the foreseeable future. I don't even consider it to be a bug now. Thank you for your efforts :( -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=546706
User nice@titanic.nyme.hu added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c20
Tamás Németh
(In reply to comment #16)
And to make it even more complex, there are 7 fully operating Cisco Aironet 1250 APs in the building and at least 2 or 3 is within the reach of my notebook, not to mention a few ones which can be seen by my machine but are in nearby buildings.
Anyway, bare wpa_supplicand seemed to be able to easily cope with this situation, and Windows clients are also able to do that.
Interesting test-case. The wpa_supplicant disconnects when it does not receive a response from the AP, but this is not very usual with Cisco. To see what is really going on we will have to see the tcpdump of the packets and check the debug output of the iwl3945 driver. If you have another box with wlan card you can try to get the test file [1] and analyze the traffic with wireshark [2]. The tcpdump file can grow pretty fast. It is good idea to have dmesg and wpa_supplicant log either. Set the iwl3945 debug output [3] and reload the iwl3845. Set wpa_supplicant debug output. Truncate the logs [4]. Synchronize the clocks on all boxes with ntp.
Post the tarball with "ifconfig","iwlist scan", "iwconfig", /var/log/messages, /var/log/wpa_supplicant and tcpdump test file. If this file is too big for Bugzilla to swallow post it anywhere else.
[1] iw dev wlan0 del #change the insterface iw phy phy0 interface add mon0 type monitor iwconfig mon0 channel 5 #change the channel iw dev mon0 info ifconfig mon0 up tcpdump -i mon0 -w test -s 0
[2] wireshark filter example (((wlan.sa contains 19:6b:36) && (wlan.da contains AA:C9:90)) || ((wlan.da contains 19:6b:36) && (wlan.sa contains AA:C9:90)))
[3] # cat modprobe.d/iwl3945 options iwl3945 debug=0x43fff
[4] #logrotate -f /etc/logrotate.conf
OK, I found another machine, but that I cannot issue the commands you wrote me, because it always gives the error message "nl80211 not found". Sorry for saying that but I have so much work in the last months (in fact years), that I'm exhausted now beyond my capacity. I won't be able to carry out this test in the foreseeable future. I don't even consider it to be a bug now. Thank you for your efforts :( -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugzilla.novell.com/show_bug.cgi?id=546706
User vbotka@novell.com added comment
http://bugzilla.novell.com/show_bug.cgi?id=546706#c21
Vladimir Botka
OK, I found another machine, but that I cannot issue the commands you wrote me, because it always gives the error message "nl80211 not found".
JFYI. This card and driver does not support nl80211.
I won't be able to carry out this test in the foreseeable future. I don't even consider it to be a bug now.
I close as a WONTFIX then. Reopen if you have more time. Thank you. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com