New hardware, old problem: stuck beacon when here is WiFi traffic

[Adrian Chadd]

On 9 May 2013 12:48, Lev Serebryakov <lev at freebsd.org> 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