Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved Wireless
    4 Posts 2 Posters 2.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      Per Hansson
      last edited by

      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
      pfsense.png_thumb

      1 Reply Last reply Reply Quote 0
      • S
        shaqan
        last edited by

        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.

        1 Reply Last reply Reply Quote 0
        • P
          Per Hansson
          last edited by

          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!

          1 Reply Last reply Reply Quote 0
          • S
            shaqan
            last edited by

            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..

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.