[Bug 949510] New: wireless lan deauthentication
http://bugzilla.suse.com/show_bug.cgi?id=949510 Bug ID: 949510 Summary: wireless lan deauthentication Classification: openSUSE Product: openSUSE Distribution Version: 42.1 Beta 1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening@forge.provo.novell.com Reporter: rommel@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- It seems that after transferring a few megabyte of data my wireless connection is always dropped. In dmesg I get: [ 1253.168846] wlan0: authenticate with 00:24:fe:ac:6e:e1 [ 1253.177179] wlan0: send auth to 00:24:fe:ac:6e:e1 (try 1/3) [ 1253.180669] wlan0: authenticated [ 1253.180732] ath5k 0000:02:08.0 wlan0: disabling HT/VHT due to WEP/TKIP use [ 1253.181344] wlan0: associate with 00:24:fe:ac:6e:e1 (try 1/3) [ 1253.185252] wlan0: RX AssocResp from 00:24:fe:ac:6e:e1 (capab=0x411 status=0 aid=1) [ 1253.185397] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 1253.190762] wlan0: associated [ 1309.812699] wlan0: deauthenticated from 00:24:fe:ac:6e:e1 (Reason: 1=UNSPECIFIED) [ 1309.825404] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA This happens with a 02:08.0 Ethernet controller: Qualcomm Atheros AR5212/AR5213 Wireless Network Adapter (rev 01) The kernel driver used is 'ath5k'. Other messages regarding ath5k or cfg80211: [ 11.849116] cfg80211: Calling CRDA to update world regulatory domain [ 13.086344] ath5k 0000:02:08.0: registered as 'phy0' [ 13.852701] ath5k: phy0: Atheros AR2414 chip found (MAC: 0x79, PHY: 0x45) [ 13.852815] cfg80211: Calling CRDA to update world regulatory domain [ 35.883396] ath5k 0000:02:08.0 wlan0: disabling HT/VHT due to WEP/TKIP use [ 37.056068] cfg80211: Calling CRDA to update world regulatory domain [ 483.049422] cfg80211: Exceeded CRDA call max attempts. Not calling CRDA [ 1784.524063] ath5k: ath5k_hw_get_isr: ISR: 0x00040001 IMR: 0x00000000 [ 1784.599781] ath5k 0000:02:08.0 wlan0: disabling HT/VHT due to WEP/TKIP use On the same machine, a SLES12 system was running without problems for months. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=949510
Chenzi Cao
http://bugzilla.suse.com/show_bug.cgi?id=949510
http://bugzilla.suse.com/show_bug.cgi?id=949510#c1
--- Comment #1 from Heiko Rommel
On the same machine, a SLES12 system was running without problems for months.
This might not be true after all. I was able to reproduce this on a SLES 12 and on a openSUSE 13.2. However, it works just nicely on WindowsXP and Windows 7. After some research on different forums, I tried one of the suggested work-arounds of changing the wireless access point from supporting Authentication: WPA-PSK Encryption: TKIP to Authentication: WPA-PSK, WPA2-PSK Encryption: TKIP, AES-CCMP All my Linux systems switched to using WPA2-PSK + AES-CCMP after that and I have not seen the error since than (including large data transfers). Seems the error protection/correction is much better with AES-CCMP. Anyway, the frightning part is that our network stack (wicked, wpa_supplicant, cfg80211, ath5k, ...) seems unable to recover from such errors. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=949510
http://bugzilla.suse.com/show_bug.cgi?id=949510#c2
--- Comment #2 from Takashi Iwai
http://bugzilla.suse.com/show_bug.cgi?id=949510
Takashi Iwai
http://bugzilla.suse.com/show_bug.cgi?id=949510
http://bugzilla.suse.com/show_bug.cgi?id=949510#c3
--- Comment #3 from Heiko Rommel
http://bugzilla.suse.com/show_bug.cgi?id=949510
http://bugzilla.suse.com/show_bug.cgi?id=949510#c4
Takashi Iwai
http://bugzilla.suse.com/show_bug.cgi?id=949510
http://bugzilla.suse.com/show_bug.cgi?id=949510#c5
--- Comment #5 from Luis Rodriguez
http://bugzilla.suse.com/show_bug.cgi?id=949510
Luis Rodriguez
http://bugzilla.suse.com/show_bug.cgi?id=949510
http://bugzilla.suse.com/show_bug.cgi?id=949510#c6
--- Comment #6 from Luis Rodriguez
http://bugzilla.suse.com/show_bug.cgi?id=949510
http://bugzilla.suse.com/show_bug.cgi?id=949510#c7
--- Comment #7 from Takashi Iwai
WPA management is handled by the supplicant and issues based on the short logs shown typically are associated with supplicant issues in my experience. If we're not using the latest and greatest wpa_supplicant my recommendation is try that. On the kernel front at least for ath5k specifically I only see this commit which may help since v4.1 (leap 42.1 should be based on this).
mac80211: extend get_tkip_seq to all keys
Testing the latest supplicant requires compiling though, so it may be easier for you to try the latest ath5k driver first. To do that please try this:
https://www.kernel.org/pub/linux/kernel/projects/backports/2015/09/23/ backports-20150923.tar.xz
Documentation:
https://backports.wiki.kernel.org/index.php/Documentation/packaging
There is an opensuse package available for this but I haven't been updating it as I wanted to see if there was a seamless way to do auto packaging for new releases. Since there is no way to do that I think one way is to make the project host a symlink to the latest though and just use that for daily builds, but I haven't done that yet, and then I'd have to rename the package (this will take time, but if there is interest in this I can do it).
IMO, the easiest way would be just to install 4.3 kernels on the Leap system. The kernel must be backward compatible, so should work as is. You can download the latest kernel package from OBS Kernel:stable or Kernel:HEAD repo.
I *think* leap 42.1 source repo should be at:
http://download.opensuse.org/distribution/leap/42.1/repo/src-oss
but that doesn't exist, so we need that. Takashi do you what it is?
The source rpms of Leap packages are found in a different URL, http://download.opensuse.org/source/distribution/leap/42.1/repo/oss/ -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=949510
http://bugzilla.suse.com/show_bug.cgi?id=949510#c8
--- Comment #8 from Takashi Iwai
http://bugzilla.suse.com/show_bug.cgi?id=949510
http://bugzilla.suse.com/show_bug.cgi?id=949510#c9
--- Comment #9 from Luis Rodriguez
(In reply to Luis Rodriguez from comment #5)
WPA management is handled by the supplicant and issues based on the short logs shown typically are associated with supplicant issues in my experience. If we're not using the latest and greatest wpa_supplicant my recommendation is try that. On the kernel front at least for ath5k specifically I only see this commit which may help since v4.1 (leap 42.1 should be based on this).
mac80211: extend get_tkip_seq to all keys
Testing the latest supplicant requires compiling though, so it may be easier for you to try the latest ath5k driver first. To do that please try this:
https://www.kernel.org/pub/linux/kernel/projects/backports/2015/09/23/ backports-20150923.tar.xz
Documentation:
https://backports.wiki.kernel.org/index.php/Documentation/packaging
There is an opensuse package available for this but I haven't been updating it as I wanted to see if there was a seamless way to do auto packaging for new releases. Since there is no way to do that I think one way is to make the project host a symlink to the latest though and just use that for daily builds, but I haven't done that yet, and then I'd have to rename the package (this will take time, but if there is interest in this I can do it).
IMO, the easiest way would be just to install 4.3 kernels on the Leap system. The kernel must be backward compatible, so should work as is. You can download the latest kernel package from OBS Kernel:stable or Kernel:HEAD repo.
That's another reasonable option instead of using the backports package.
I *think* leap 42.1 source repo should be at:
http://download.opensuse.org/distribution/leap/42.1/repo/src-oss
but that doesn't exist, so we need that. Takashi do you what it is?
The source rpms of Leap packages are found in a different URL, http://download.opensuse.org/source/distribution/leap/42.1/repo/oss/
I had tried that and it didn't seem to work as a repo url, so I was not sure what was the right one. The one I am looking for would enable the user to use zypper si -d to install build-dependencies. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=949510
http://bugzilla.suse.com/show_bug.cgi?id=949510#c10
--- Comment #10 from Luis Rodriguez
I guess testing the latest wpa_supplicant from OBS hardware project would be OK, too? It's equivalent with what we have on FACTORY.
http://download.opensuse.org/repositories/hardware/openSUSE_Leap_42.1/x86_64...
That's wpa_supplicant 2.4 -- could still work but IMHO this is just ancient for my own taste. To enable users to get the best experience we want the latest and greatest supplicant. Just my $0.02. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=949510
http://bugzilla.suse.com/show_bug.cgi?id=949510#c11
--- Comment #11 from Takashi Iwai
(In reply to Takashi Iwai from comment #8)
I guess testing the latest wpa_supplicant from OBS hardware project would be OK, too? It's equivalent with what we have on FACTORY.
http://download.opensuse.org/repositories/hardware/openSUSE_Leap_42.1/x86_64...
That's wpa_supplicant 2.4 -- could still work but IMHO this is just ancient for my own taste. To enable users to get the best experience we want the latest and greatest supplicant. Just my $0.02.
We need to upgrade there at first, then ;) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=949510
http://bugzilla.suse.com/show_bug.cgi?id=949510#c12
--- Comment #12 from Takashi Iwai
I *think* leap 42.1 source repo should be at:
http://download.opensuse.org/distribution/leap/42.1/repo/src-oss
but that doesn't exist, so we need that. Takashi do you what it is?
The source rpms of Leap packages are found in a different URL, http://download.opensuse.org/source/distribution/leap/42.1/repo/oss/
I had tried that and it didn't seem to work as a repo url, so I was not sure what was the right one. The one I am looking for would enable the user to use zypper si -d to install build-dependencies.
It works on my machine, and actually the source repo has been existing from the beginning, but it's not enabled as default. You need to turn it on at first, do refresh, then do si (all as root). zypper mr -e repo-source zypper ref repo-source zypper si -d wpa_supplicant -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=949510
http://bugzilla.suse.com/show_bug.cgi?id=949510#c16
Tomáš Chvátal
participants (1)
-
bugzilla_noreply@novell.com