On 9 May 2013 12:48, Lev Serebryakov <[email protected]> wrote: > f0:a2:25:ec:38:c6 is Kindle. > c4:85:08:3f:9e:c2 is Windows client, UDP stream receiver.
Ok. So this is a different problem. May 9 23:39:18 gateway kernel: wlan0: [f0:a2:25:ec:38:c6] RSN ie: mc 3/0 uc 3/0 key 2 caps 0x0 May 9 23:39:18 gateway kernel: wlan0: [f0:a2:25:ec:38:c6] switch station to HT20 channel 2422/0x10480 May 9 23:39:18 gateway kernel: wlan0: [f0:a2:25:ec:38:c6] station associated at aid 1: short preamble, short slot time, QoS, HT20 (+AMPDU) May 9 23:39:18 gateway kernel: wlan0: [f0:a2:25:ec:38:c6] station unauthorize via MLME May 9 23:39:19 gateway kernel: wlan0: [c4:85:08:3f:9e:c2] RSN ie: mc 3/0 uc 3/0 key 2 caps 0x3c May 9 23:39:19 gateway kernel: wlan0: [c4:85:08:3f:9e:c2] station associated at aid 2: short preamble, short slot time, QoS, HT40 (+AMPDU) (+SMPS-DYN) May 9 23:39:19 gateway kernel: wlan0: _ieee80211_crypto_delkey: AES-CCM keyix 5 flags 0x103 rsc 0 tsc 222188 len 16 May 9 23:39:19 gateway kernel: wlan0: [c4:85:08:3f:9e:c2] pwr save q overflow, drops 59924 (size 50) May 9 23:39:20 gateway kernel: wlan0: [c4:85:08:3f:9e:c2] pwr save q overflow, drops 59925 (size 50) May 9 23:39:21 gateway kernel: wlan0: [c4:85:08:3f:9e:c2] pwr save q overflow, drops 59926 (size 50) May 9 23:39:21 gateway kernel: wlan0: [f0:a2:25:ec:38:c6] station deauth via MLME (reason 2) May 9 23:39:21 gateway kernel: wlan0: [f0:a2:25:ec:38:c6] station with aid 1 leaves May 9 23:39:22 gateway kernel: wlan0: [c4:85:08:3f:9e:c2] pwr save q overflow, drops 59927 (size 50) May 9 23:39:23 gateway kernel: wlan0: [c4:85:08:3f:9e:c2] station deauth via MLME (reason 2) May 9 23:39:23 gateway kernel: wlan0: [c4:85:08:3f:9e:c2] station with aid 2 leaves .. now, see how it's kicking you off? The transmit queue is filled _and_ the station is asleep. We're still trying to send it stupid amounts of data even though we can't get to the sleeping station. So: Try setting wpa_group_rekey in hostapd.conf to something low, like say 15 seconds. See if that immediately triggers things to go pear-shaped. Then, if it does, try running hostapd in debug mode in the foreground: # hostapd -d -d /etc/hostapd.conf 2>&1 | tee /tmp/hostapd.log .. and then watch what goes on with rekeying as it gets booted off. I bet that it's missing the group rekey notification from the remote station, and it's being disconnected. If that's the case - great! We've fixed the hardware bug. You'll be a perfect test candidate for my power-save queue handling changes, which look to address this saxact problem. (yay! I hope we've fixed the TX queue hangs!) adrian _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "[email protected]"
