Re: [ath9k-devel] Wireless stalled after a few minutes with Linux Kernel 3.1

2011-12-09 Thread Haohui Liao
Dear Jouni Malinen,

 Regarding https://bugs.archlinux.org/task/27406

  The following is a portion of my wpa_supplicant.conf
 
     ssid=LINUX-LINK
     proto=WPA2
     key_mgmt=WPA-PSK
     pairwise=TKIP
     group=TKIP

 That's pretty strange configuration.. Do you have any
 particular reason for using TKIP as the pairwise cipher
 with WPA2? CCMP would be much more likely configuration
 for WPA2 in general..

The reason I am using TKIP is because my Wifi configuration
says the following:

Network Authentication: WPA2-PSK
WPA Encryption: TKIP

and I misunderstood the wpa_supplicant.conf and just change
the WPA-PSK to WPA2-PSK and have the TKIP remain.

 Just wondering if I am the only one still doing the following from command 
 line
 to connect to wifi?

 I'm sure you are not the only one.. And in this particular
 case, I don't
 see how that would make a difference.

It DOES.  I tried yesterday with my Fedora 16 (which is using
kernel 3.1.2).

With XFCE + NetworkManager, there is no issue with my wifi.
But when I performed init 3 (shutting down X11) and tried the
following

wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf -B
iwconfig wlan0 power off
dhclient wlan0

my wifi will ``stall''.  This is probably misleading because
my machine still runs, it is just that the following scenario
happens:

The debugging message wpa_supplicant is as follows:

WPA: Request PTK rekeying
WPA: Sending EAPOL-Key Request (en=0 pairwise=1 ptk_set=1 len=99)
WPA: TX EAPOL-Key-hexdump (len=99): 01 03 ...

And the is no more communication.  With Wireshark, I will
get the following (Reference:
https://bugs.archlinux.org/task/27406?getfile=7864):

Laptop Wifi (QuantaMi) will ask my wifi router (Shenzhen)
who has 192.168.1.1 tell 192.168.1.3 (my router) but the
process continues and all Internet connections seem broken.

So 10 minutes' connection to Internet will suddenly stop.

 Would you be able to provide some more details on what
 exactly you mean with wifi stall? Are you sure this is
 related to rekeying?

I am not sure if the term stall is correct.  But
wpa_supplicant seems to be hanging there asking (ARP protocol)
for response from my router but the router seems to be deaf
and is not responding.  So the ONLY way for me to get back
a connection is to kill the wpa_supplicant daemon and
the connection resumes.

This never happens to linux 3.0.7 but happens immediately
when I upgrade to linux 3.1. (This matter persists until
Linux 3.1.4)

 May I ask why you have configured the station to force PTK
 rekeying every 10 minutes? While TKIP is not really the
 most secure design out there, the proper way of addressing
 this would be to use CCMP instead of frequent rekeying with
 TKIP..

Thank you very much for pointing out this to me.  I did not
actually go through the wpa_supplicant.conf very thoroughly
and simply adapt the example I found below:

# WPA-Personal(PSK) with TKIP and enforcement for frequent PTK rekeying

I just change the WPA-PSK to WPA2 and everything just works.
So I thought I got things correct.   Apparently this is not
the case.  The PTK just happens to come from the
configuration.

Anyway, it is also good to learn that there is a TPK rekeying
since surrounding interference may cause wifi connection
to be broken and my wifi connection may be hanging at random.

I will change to CCMP as you suggested and inform you the
result.

A million thanks for all your suggestions and correction and
I hope you forgive my English.


Regards,
Liao Haohui
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


Re: [ath9k-devel] Wireless stalled after a few minutes with Linux Kernel 3.1

2011-12-09 Thread Jouni Malinen
On Fri, Dec 09, 2011 at 09:07:17PM +0800, Haohui Liao wrote:
  Just wondering if I am the only one still doing the following from command 
  line
  to connect to wifi?
 
  I'm sure you are not the only one.. And in this particular
  case, I don't
  see how that would make a difference.
 
 It DOES.  I tried yesterday with my Fedora 16 (which is using
 kernel 3.1.2).

I understand that you see different behavior between using
NetworkManager and stating wpa_supplicant from the command line.
However, I don't think this is because of the NM vs. manual
wpa_supplicant start, but because of configuration differences. In other
words, if your wpa_supplicant.conf in the manual start case would be
identical with the way NM configured wpa_supplicant, you would most
likely see the same behavior.

 The debugging message wpa_supplicant is as follows:
 
 WPA: Request PTK rekeying
 WPA: Sending EAPOL-Key Request (en=0 pairwise=1 ptk_set=1 len=99)
 WPA: TX EAPOL-Key-hexdump (len=99): 01 03 ...
 
 And the is no more communication.  With Wireshark, I will
 get the following (Reference:
 https://bugs.archlinux.org/task/27406?getfile=7864):

Do you know how quickly the connection dies after the PTK rekeying
request? The snapshot from wireshark has a gap of over one minute
without any traffic, so it is difficult to say whether that is because
of there really being no traffic or for some other reasons.

If this issue is indeed triggered by this EAPOL-Key request frame, it
would be useful to know what AP you are using. If I understood
correctly, it is the device with Shenzhen OUI in the MAC address. Do you
have a more detailed model number for the device?

It is interesting the hear that you see a difference between two kernel
versions. I could understand that if the process would actually go
through rekeying, but in this particular case, it looks like the AP just
refuses to do anything with the EAPOL-Key frame and as such, the
kernel/driver difference should not really have mattered.

 I am not sure if the term stall is correct.  But
 wpa_supplicant seems to be hanging there asking (ARP protocol)
 for response from my router but the router seems to be deaf
 and is not responding.  So the ONLY way for me to get back
 a connection is to kill the wpa_supplicant daemon and
 the connection resumes.

The ARP request is not from wpa_supplicant, but something else in the
system. wpa_supplicant not actually send any IP packets through the
connection. The EAPOL-Key Request was indeed from wpa_supplicant and for
some reason, the AP did not seem to react to it (it should have sent
EAPOL-Key msg 1/4). It is a bit difficult to figure out why exactly this
is happening, but this could be some kind of combination of a bug in the
AP and state or keys getting mixed up between the AP and station. Most
stations do not really use the explicit PTK rekeying request that you
happened to have enabled in this case and as such, I would not be too
surprised if that does not get tested properly with all APs.

If you would happen to have another WLAN device that could capture
frames in wireless sniffer mode (i.e., full IEEE 802.11 headers and not
just the data frames from the station), that could provide additional
information here.

 # WPA-Personal(PSK) with TKIP and enforcement for frequent PTK rekeying
 
 I just change the WPA-PSK to WPA2 and everything just works.
 So I thought I got things correct.   Apparently this is not
 the case.  The PTK just happens to come from the
 configuration.

Well, this is a valid configuration in theory, but not really something
that is normally used and I would recommend using WPA2 with CCMP and
leaving out the PTK rekeying (which is really just a workaround for not
so secure TKIP).

-- 
Jouni MalinenPGP id EFC895FA
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


Re: [ath9k-devel] Wireless stalled after a few minutes with Linux Kernel 3.1

2011-12-05 Thread Jouni Malinen
On Sat, Dec 03, 2011 at 10:55:40PM +0800, Haohui Liao wrote:
 Dear Linux Wifi developers,
 
 Regarding https://bugs.archlinux.org/task/27406
 
  The following is a portion of my wpa_supplicant.conf
 
     ssid=LINUX-LINK
     proto=WPA2
     key_mgmt=WPA-PSK
     pairwise=TKIP
     group=TKIP

That's pretty strange configuration.. Do you have any particular reason
for using TKIP as the pairwise cipher with WPA2? CCMP would be much more
likely configuration for WPA2 in general..

 Just wondering if I am the only one still doing the following from command 
 line
 to connect to wifi?

I'm sure you are not the only one.. And in this particular case, I don't
see how that would make a difference.

 wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf -B
 iwconfig wlan0 power off
 dhcpd wlan0
 
 If I do that, I will get wifi stall on wpa_supplicant when there is a
 rekeying with the Linux 3.1.x kernel.  It does not happen to Linux
 3.0.x.  I have been searching on Internet around with no indicator.
 Just trying to ask if I did anything wrong? or everyone just uses
 NetworkManager?

Would you be able to provide some more details on what exactly you mean
with wifi stall? Are you sure this is related to rekeying?

May I ask why you have configured the station to force PTK rekeying
every 10 minutes? While TKIP is not really the most secure design out
there, the proper way of addressing this would be to use CCMP instead of
frequent rekeying with TKIP..

-- 
Jouni MalinenPGP id EFC895FA
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


Re: [ath9k-devel] Wireless stalled after a few minutes with Linux Kernel 3.1

2011-12-03 Thread Haohui Liao
Dear Linux Wifi developers,

Regarding https://bugs.archlinux.org/task/27406

 The following is a portion of my wpa_supplicant.conf

    ssid=LINUX-LINK
    proto=WPA2
    key_mgmt=WPA-PSK
    pairwise=TKIP
    group=TKIP
    wpa_ptk_rekey=600

Just wondering if I am the only one still doing the following from command line
to connect to wifi?

wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf -B
iwconfig wlan0 power off
dhcpd wlan0

If I do that, I will get wifi stall on wpa_supplicant when there is a
rekeying with the Linux 3.1.x kernel.  It does not happen to Linux
3.0.x.  I have been searching on Internet around with no indicator.
Just trying to ask if I did anything wrong? or everyone just uses
NetworkManager?


Best Regards,
Liao Haohui
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


Re: [ath9k-devel] Wireless stalled after a few minutes with Linux Kernel 3.1

2011-12-03 Thread Adrian Chadd
Hi,

I can't help with this, except to say if you can bisect the
compat-wireless source until you find the offending commit, it can be
fixed.

I'd suggest creating a kernel.org bugzilla report, but it seems
bugzilla is still down.




adrian
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


[ath9k-devel] Wireless stalled after a few minutes with Linux Kernel 3.1

2011-11-19 Thread Haohui Liao
Dear Linux wifi developers,

I am using ArchLinux with Linux kernel 3.0.7.  I find that sometimes
the wifi connection will suddenly just disconnect itself but it will
quickly resume.  Some said on the Internet that this is due to
surrounding interference, is this normal?

When I upgraded to Linux kernel 3.1, I have even worst experience, the
wifi will stall a few minutes after connection and only killing
wpa_supplicant and running it all over again will I be able to
reconnect to the wifi.  The following are my hardware and software
status:

oftware: Linux-3.1-4  wpa_supplicant v0.7.3
Closely related but not the same problem (my system doesn't have have
the bcma as mentioned in the url):
https://bbs.archlinux.org/viewtopic.php?pid=1014217
Observation: No such network stall with linux-3.0.7-1.

I didn't encounter core dump problem with kernel 3.1. However, after
connecting for a few seconds or minutes, the connection with stall and
I can't assess Internet. I check my dmesg, it gave the following info:

[ 45.966602] wlan0: direct probe to f4:3f:61:06:22:21 (try 1/3)
[ 45.969213] wlan0: direct probe responded
[ 45.998789] wlan0: authenticate with f4:3f:61:06:22:21 (try 1)
[ 46.001234] wlan0: authenticated
[ 46.001270] wlan0: associate with f4:3f:61:06:22:21 (try 1)
[ 46.004102] wlan0: RX AssocResp from f4:3f:61:06:22:21 (capab=0x411
status=0 aid=1)
[ 46.004107] wlan0: associated
[ 93.007527] usb 1-1.3: USB disconnect, device number 3
[ 95.654157] NET: Registered protocol family 10
[ 106.263062] wlan0: no IPv6 routers present

Does this mean that the IPv6 in kernel 3.1 is affecting the wifi
connection?  Please advice.


Best Regards,
Liao Haohui
___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel


Re: [ath9k-devel] Wireless stalled after a few minutes with Linux Kernel 3.1

2011-11-19 Thread Arend van Spriel
On 11/19/2011 03:20 PM, Haohui Liao wrote:
 Dear Linux wifi developers,
 
 I didn't encounter core dump problem with kernel 3.1. However, after
 connecting for a few seconds or minutes, the connection with stall and
 I can't assess Internet. I check my dmesg, it gave the following info:
 
 [ 45.966602] wlan0: direct probe to f4:3f:61:06:22:21 (try 1/3)
 [ 45.969213] wlan0: direct probe responded
 [ 45.998789] wlan0: authenticate with f4:3f:61:06:22:21 (try 1)
 [ 46.001234] wlan0: authenticated
 [ 46.001270] wlan0: associate with f4:3f:61:06:22:21 (try 1)
 [ 46.004102] wlan0: RX AssocResp from f4:3f:61:06:22:21 (capab=0x411
 status=0 aid=1)
 [ 46.004107] wlan0: associated
 [ 93.007527] usb 1-1.3: USB disconnect, device number 3
 [ 95.654157] NET: Registered protocol family 10
 [ 106.263062] wlan0: no IPv6 routers present

Actually, this trace looks fine. The last message means that no IPv6
capable network equipment has been detected. Did you do unplug a USB device?

 Does this mean that the IPv6 in kernel 3.1 is affecting the wifi
 connection?  Please advice.

Provide hardware info.

Gr. AvS

___
ath9k-devel mailing list
ath9k-devel@lists.ath9k.org
https://lists.ath9k.org/mailman/listinfo/ath9k-devel