Wireless speed drops to zero at repeating interval on 802.11N (with fix)

Per Hansson

Hi, I've been troubleshooting why my Atheros AR9227 based TP-Link TL-WN851ND gets dropouts in speed.
I have been getting the famous stuck beacon messages and that is what I've assumed was the problem.
I even tried to change hardware completely but it was just the same, I also have some other Atheros adapters and it was the same with them too.
All through pfsense 2.2.6 > 2.3.1

ath0: stuck beacon; resetting (bmiss count 4)
ath0_wlan0: discard frame w/o leading ethernet header (len 6 pkt len 6)

Recently I considered defeat and bought a Marvell 88W8363 based card since that was listed in the supported wireless cards as one of the best 802.11N adapters to get.
It works but the speed is crap, linkspeed is 144Mbps in 802.11N mode and 300Mbps in 802.11A mode. (Yes, 5Ghz on pfsense!)
But the actual throughput is ~3MB or ca 20Mbps, my old WRT54GL does better than that :D

So I put back the Atheros card and did some more tests, I realized the dropouts per the attached screenshot occur at 60 second intervals.
I looked in the webinterface and there are two settings for the WiFi security:
"Group Key Rotation" & "Group Master Key Regeneration"
The latter is set to 3600 seconds (1 hour) by default which is sane.
The former setting "Group Key Rotation" just so happens to be set at 60 seconds by default.
The interface does not allow to set it to zero so I increased it and that caused the dropouts to also increase by the same amount!
Not admitting defeat so easily I tried setting it to zero in the /var/etc/hostapd_ath0_wlan0.conf file and reloaded hostapd on the CLI.
It worked a treat, no more dropouts and great speed!
I then made the changes permanent by modifying /usr/local/www/interfaces.php to allow me to set a value of zero.

Now this is related to security, we all know we should not run TKIP encryption because that is just a bandaid for WEP.
But it's my understanding that "Group Key Rotation" was a bandaid fix for the broken TKIP security.
But AFAIK no exploits exists for AES which is the recommended and default encryption method.
So why is the value set so low or am I wrong? If I remember right my IPCOP box had it set to 600 seconds.

pfsense.png_thumb

shaqan

going to give it a try..

Got 2 Atheros cards in pfSense box, one for "gn" (ordinary AR9462), second high-power Mikrotik "an" card (AR9580). Beacon errors should make their appearance twice as fast if it doesn't work.. Gonna give at least 2-3 days to let it work itself out, then I'm going to report back.

Per Hansson

The fix does not solve the stuck beacon issue.
But it does solve the problem with the 60 second dropouts in speed as shown in the screenshot in my original post.

I have now switched to the Marvell 88W8363 card, even though I get poor speeds from it (~54G speeds even though the link rate is 300Mbps)
Because with a specific LG phone I got these issues which caused the WiFi to drop and eventually the pfSense box to lockup completely:
ath0: ath_tx_default_comp: bf 0xfffffe00009db8b8: seqno 1736: bf_next not NULL!
ath0: ath_tx_default_comp: bf 0xfffffe00009e44f8: seqno 1739: bf_next not NULL!
ath0: ath_tx_default_comp: bf 0xfffffe00009d2fa8: seqno 1808: bf_next not NULL!
ath0: ath_tx_default_comp: bf 0xfffffe00009ddd60: seqno 329: bf_next not NULL!

shaqan

well, the dropouts are also half of the problem.

For me, beacon errors appear generally only on 2,4Ghz because there are bunch of other stations in air plus hell knows how many microwave ovens, car alarms etc which are all sitting on that band..

5-5,8Ghz band hasn't been an issue, except for some devices not "seeing" it..

if your method allows me solve half ot, it deserves hearty "Thank you".

at the moment log is clean..