+ Rakesh/Nick -----Original Message----- From: Johannes Berg [mailto:johannes@xxxxxxxxxxxxxxxx] Sent: Thursday, March 29, 2012 7:40 AM To: Zhong, Hongbo Cc: wey-yi.w.guy@xxxxxxxxx; linux-wireless@xxxxxxxxxxxxxxx; Cao, Qingtao (Harry); Gao, Guijin; Cabuk, Yusuf; Foglia, Michael; Intel Linux Wireless; Zhan, Rongkai (Mark) Subject: Re: Dell E6400 + Windows XP can not work on intel N-6205 AP mode for compat-wireless-2012-03-18.tar.bz2 package Hi Zhong, > Mar 23 12:44:48 localhost hostapd: wlan0: STA 00:1f:e2:cc:f5:0a IEEE > 802.11: authenticated Mar 23 12:44:48 localhost hostapd: wlan0: STA > 00:1f:e2:cc:f5:0a IEEE 802.11: associated (aid 1) Mar 23 12:44:48 > localhost kernel: wlan0: STA 00:1f:e2:cc:f5:0a aid 1 sending 0 > filtered/0 PS frames since STA not sleeping anymore Mar 23 12:44:50 > localhost last message repeated 3 times Mar 23 12:44:51 localhost > hostapd: wlan0: STA 00:1f:e2:cc:f5:0a IEEE 802.11: deauthenticated due > to local deauth request Mar 23 12:44:53 localhost hostapd: wlan0: STA > 00:1f:e2:cc:f5:0a IEEE 802.11: authenticated Mar 23 12:44:53 localhost > hostapd: wlan0: STA 00:1f:e2:cc:f5:0a IEEE 802.11: associated (aid 1) > Mar 23 12:44:53 localhost kernel: wlan0: STA 00:1f:e2:cc:f5:0a aid 1 > sending 0 filtered/0 PS frames since STA not sleeping anymore Mar 23 > 12:44:55 localhost last message repeated 3 times This is a bit strange -- any idea what was happening at this time? It seems to repeat for quite a while until it finally associates properly: > Mar 23 12:45:16 localhost hostapd: wlan0: STA 00:1f:e2:cc:f5:0a IEEE > 802.11: authenticated Mar 23 12:45:16 localhost hostapd: wlan0: STA > 00:1f:e2:cc:f5:0a IEEE 802.11: associated (aid 1) Mar 23 12:45:17 > localhost kernel: wlan0: STA 00:1f:e2:cc:f5:0a aid 1 sending 0 > filtered/0 PS frames since STA not sleeping anymore Mar 23 12:45:17 > localhost kernel: wlan0: STA 00:1f:e2:cc:f5:0a aid 1 sending 0 > filtered/0 PS frames since STA not sleeping anymore Mar 23 12:45:17 > localhost kernel: br0: port 1(wlan0) entering forwarding state Mar 23 > 12:45:18 localhost kernel: wlan0: STA 00:1f:e2:cc:f5:0a aid 1 sending > 0 filtered/0 PS frames since STA not sleeping anymore Mar 23 12:45:18 > localhost kernel: wlan0: STA 00:1f:e2:cc:f5:0a aid 1 sending 0 > filtered/0 PS frames since STA not sleeping anymore Mar 23 12:45:18 > localhost hostapd: wlan0: STA 00:1f:e2:cc:f5:0a RADIUS: starting > accounting session 4F6C702C-00000000 Mar 23 12:45:18 localhost > hostapd: wlan0: STA 00:1f:e2:cc:f5:0a WPA: pairwise key handshake > completed (RSN) Is it possible that the system you're running the AP on doesn't have enough entropy to do the 4-way handshake earlier? > Mar 23 12:45:48 localhost dhcpd: Internet Systems Consortium DHCP > Server 4.2.1-P1 Mar 23 12:45:48 localhost dhcpd: Copyright 2004-2011 Internet Systems Consortium. > Mar 23 12:45:48 localhost dhcpd: All rights reserved. > Mar 23 12:45:48 localhost dhcpd: For info, please visit > https://www.isc.org/software/dhcp/ > Mar 23 12:45:48 localhost dhcpd: Wrote 0 leases to leases file. > Mar 23 12:45:48 localhost dhcpd: Listening on LPF/br0/a0:88:b4:18:64:a0/192.168.0.0/24 > Mar 23 12:45:48 localhost dhcpd: Sending on LPF/br0/a0:88:b4:18:64:a0/192.168.0.0/24 > Mar 23 12:45:48 localhost dhcpd: > Mar 23 12:45:48 localhost dhcpd: No subnet declaration for eth0 (128.224.163.192). > Mar 23 12:45:48 localhost dhcpd: ** Ignoring requests on eth0. If this is not what > Mar 23 12:45:48 localhost dhcpd: you want, please write a subnet declaration > Mar 23 12:45:48 localhost dhcpd: in your dhcpd.conf file for the network segment > Mar 23 12:45:48 localhost dhcpd: to which interface eth0 is attached. ** > Mar 23 12:45:48 localhost dhcpd: > Mar 23 12:45:48 localhost dhcpd: Sending on Socket/fallback/fallback-net Are you really starting dhcpd this late, after the client connected? Does the client then even get a proper IP address? > Mar 23 12:45:57 localhost dhcpd: DHCPDISCOVER from 00:1f:e2:cc:f5:0a > via br0 Mar 23 12:45:57 localhost kernel: wlan0: STA 00:1f:e2:cc:f5:0a > aid 1 exits power save mode Mar 23 12:45:57 localhost kernel: wlan0: > STA 00:1f:e2:cc:f5:0a aid 1 sending 0 filtered/0 PS frames since STA > not sleeping anymore Mar 23 12:45:57 localhost kernel: wlan0: STA > 00:1f:e2:cc:f5:0a aid 1 enters power save mode Mar 23 12:45:58 > localhost kernel: wlan0: STA 00:1f:e2:cc:f5:0a aid 1 exits power save > mode Mar 23 12:45:58 localhost kernel: wlan0: STA 00:1f:e2:cc:f5:0a > aid 1 sending 0 filtered/0 PS frames since STA not sleeping anymore > Mar 23 12:45:58 localhost dhcpd: DHCPOFFER on 192.168.0.52 to > 00:1f:e2:cc:f5:0a (PEK-IT-L5) via br0 Mar 23 12:45:58 localhost dhcpd: > DHCPREQUEST for 192.168.0.52 (192.168.0.1) from 00:1f:e2:cc:f5:0a > (PEK-IT-L5) via br0 Mar 23 12:45:58 localhost dhcpd: DHCPACK on > 192.168.0.52 to 00:1f:e2:cc:f5:0a (PEK-IT-L5) via br0 Ok, I guess it looks like it does get an IP address. The remainder of this log looks perfectly normal, just like you'd expect with a client in powersave. Do you think you could get a wireless sniffer and record over-the-air traffic? johannes ��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
