FS#27406 - [linux] 3.1.x wifi problem
Attached to Project:
Arch Linux
Opened by Liao Haohui (liaohaohui) - Friday, 02 December 2011, 08:45 GMT
Last edited by Tobias Powalowski (tpowa) - Wednesday, 22 February 2012, 16:38 GMT
Opened by Liao Haohui (liaohaohui) - Friday, 02 December 2011, 08:45 GMT
Last edited by Tobias Powalowski (tpowa) - Wednesday, 22 February 2012, 16:38 GMT
|
Details
Description:
With the following configuration in wpa_supplicant.conf: ssid="LINUX-LINK" proto=WPA2 key_mgmt=WPA-PSK pairwise=TKIP group=TKIP wpa_ptk_rekey=600 During rekeying process, the wifi to router process will break and I have to kill wpa_supplicant daemon again to reestabilish the connection. I thought this was the same problem as https://bugs.archlinux.org/task/26847 and has been complaining there but I was told that mine was a different issue. I made the issue known to Linux Atheros developer but their didn't reply, so I have to this issue here. Additional info: * package version(s): linux 3.1.4-1 Steps to reproduce: Wait for 10 minutes (wpa_ptk_rekey=600) and the rekeying will break the wifi network connection. In the attachment, I took a wireshark screenshot of this. |
This task depends upon
Closed by Tobias Powalowski (tpowa)
Wednesday, 22 February 2012, 16:38 GMT
Reason for closing: Upstream
Wednesday, 22 February 2012, 16:38 GMT
Reason for closing: Upstream
wpa_supplicant 0.7.3-4
The wifi problem doesn't exist with Linux 3.0.7. I knew from kernel.org that there are some changes to ath9k but until now the wifi breakage still persist. In thread https://bugs.archlinux.org/task/26847, someone mention that ipv6 might cause wifi problem. I have tested on my laptop, the ipv6 module is fine, it is not the cause of wifi disconnection from router during rekey.
wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf
iwconfig wlan0 power off
dhcpd wlan0
I think it is because even kernel developers uses GNOME or KDE or XFCE (I used XFCE in Fedora 16), that is why no one met with the problem I encountered and so none can response to this tread.
ssid="LINUX-LINK"
proto=WPA2
key_mgmt=WPA-PSK
pairwise=TKIP
group=TKIP
wpa_ptk_rekey=600
will have wifi reconnection problem during wifi re-keying with TKIP protocol. For linux 3.1.5, the rekeying will just turn my AP and ath9k wifi card to suddenly speak different language and one constantly ask who is 192.168.1.1 and my AP will say 192.168.1.1 is at some MAC address and a link never establish! No such problem for the connection with linux 3.0.7 using the TKIP protocol.
However, Linux kernel wifi developer Jouni Malinen suggested that the encryption protocol be changed to CCMP:
ssid="LINUX-LINK"
proto=WPA2
key_mgmt=WPA-PSK
pairwise=CCMP
group=CCMP
wpa_ptk_rekey=600 # For testing purpose, will comment out later
and it works with my access point (AP) innacomm w3400v, a brand used by Telekom Malaysia, see http://www.innacomm.com.my/?page_id=225.
I still put the `wpa_ptk_rekey=600' just to test if rekeying will affect it. From Internet search results, if there is interference, the wifi connection between AP and laptop will break. For CCMP, during rekeying, there is a break of approximately 10 seconds which may be the time for random key generation and reconnection.
However, if I resume back to TKIP (the ISP set this as default. Well, Malaysia still lacks skilful technicians), after 10 minutes (wpa_ptk_rekey=600), the connection will break and NEVER RESUME (I called it `stall' previously). I believe during the code improvement from kernel 3.0 to 3.1, the changes in TKIP has created some bug in 3.1 (3.0 works and 3.1 fails, i.e. TKIP connection will resume in 3.0 but not 3.1). I perform a diff to see the changes but can't make much sense (I have extremely limited knowledge about linux kernel):
### diff -r linux-3.0/drivers/net/wireless/ath/ath9k/
linux-3.1/drivers/net/wireless/ath/ath9k/|grep -i tki
< #define is_mc_or_valid_tkip_keyix ((is_mc || \
< test_bit(rx_stats->rs_keyix, common->tkip_keymap))))
> bool is_mc, is_valid_tkip, strip_mic, mic_error;
> is_valid_tkip = rx_stats->rs_keyix != ATH9K_RXKEYIX_INVALID &&
> test_bit(rx_stats->rs_keyix, common->tkip_keymap);
> strip_mic = is_valid_tkip && !(rx_stats->rs_status &
> mic_error = is_valid_tkip && !ieee80211_is_ctl(fc) &&
< * decrypted using a valid TKIP key.
< is_mc_or_valid_tkip_keyix)
< #define AR_KEYTABLE_TYPE_TKIP 0x00000004
Since changing from TKIP to CCMP (using AES encryption) works, I will just ignore the problem with TKIP. However, I don't think the TKIP problem is resolved.