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

    Wifi loop after running 3-4 days "deauthenticated due to local deauth request"

    Wireless
    2
    5
    10733
    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.
    • J
      jvin248
      last edited by

      pfSense box will run 3 to 4 days with wireless and then the clients get kicked off and cannot reconnect.
      Clients are logging in occasionally, pfSense box is continuously on. 
      Clients are 2 Ubuntu 9.10 and 1 windows 7 that can log into other local signals during the same session the pfSense box won't link up.  SSID continues to show in the wifi lists, Ubuntu clients try to link and sometimes request manual WPA password re-entry but don't finish linking until the pfSense box is power cycled.

      Logs are filled with:
      …
      Dec 16 03:02:28 hostapd: ral0: STA 00:1c:bf:1d:yy:zz IEEE 802.11: deauthenticated due to local deauth request
      Dec 16 03:02:25 hostapd: ral0: STA 00:1c:bf:1d:yy:zz IEEE 802.11: associated
      Dec 16 03:02:24 hostapd: ral0: STA 00:1c:bf:1d:yy:zz IEEE 802.11: deassociated
      Dec 16 03:02:24 hostapd: ral0: STA 00:1c:bf:1d:yy:zz IEEE 802.11: deauthenticated due to local deauth request
      Dec 16 03:02:21 hostapd: ral0: STA 00:1c:bf:1d:yy:zz IEEE 802.11: associated
      Dec 16 02:00:01 check_reload_status: check_reload_status is starting
      Dec 16 01:26:20 hostapd: ral0: STA 00:1c:bf:1d:yy:zz IEEE 802.11: deassociated
      Dec 16 01:26:20 hostapd: ral0: STA 00:1c:bf:1d:yy:zz IEEE 802.11: associated
      Dec 16 01:26:19 hostapd: ral0: STA 00:1c:bf:1d:yy:zz IEEE 802.11: deassociated
      Dec 16 01:26:19 hostapd: ral0: STA 00:1c:bf:1d:yy:zz IEEE 802.11: deauthenticated due to local deauth request
      Dec 16 01:26:16 hostapd: ral0: STA 00:1c:bf:1d:yy:zz IEEE 802.11: associated
      ...
      Physically rebooting the pfSense box will allow it to immediately work again for another 3-4 days before requiring another manual power cycle.

      Based on some googling I changed the "State Timeout in seconds" to 180 in edit_firewall_rules for OPT1 (wifi)
      Is this going to fix the problem?

      Do I have a flaky wifi card on the pfSense box?

      Or some/which setting I should double-check?

      1 Reply Last reply Reply Quote 0
      • D
        DamienD
        last edited by

        Hello,

        Same problem here…

        running pfsense 1.2.3 on ALIX mb

        somebody have a solution?

        Do you need more infos?

        Could it be related to the key rotation value?  http://forum.pfsense.org/index.php/topic,32038.0.html

        With the default value of 60 It holds up for about 4 days before starting to bug... I changed to 1800 to see if it improves anything.

        regards

        1 Reply Last reply Reply Quote 0
        • J
          jvin248
          last edited by

          Issue continues…  Client is in continuous loop trying to reconnect and issue Wifi password.

          I found that rather than rebooting the whole pfSense machine, just going into the Opt1 (the wifi card) and removing the checkmark from the "Opt1/WPA:Enable WPA" option, saving, and then putting in the checkmark to enable WPA and saving again, allows the wifi to start working.

          I'll try changing the Key Rotation (currently at 60 default) and Master Key Regeneration (3600 default) to see if that helps as noted in the referenced forum; though I suspect that just delays the time between resets rather than fixing the root cause...

          Here's the log file from before resetting, cycling the WPA, and after:

          ======================
          Failed Wifi connection (client system asks to put in correct password, but never connects)

          ... a lot of these ...:
          Jun 14 10:44:12 hostapd: ral0: STA 00:1c:bf:xx:xx:xx IEEE 802.11: associated
          Jun 14 10:44:15 hostapd: ral0: STA 00:1c:bf:xx:xx:xx IEEE 802.11: deassociated
          Jun 14 10:44:15 hostapd: ral0: STA 00:1c:bf:xx:xx:xx IEEE 802.11: deauthenticated due to local deauth request
          Jun 14 10:44:17 hostapd: ral0: STA 00:1c:bf:xx:xx:xx IEEE 802.11: associated
          Jun 14 10:44:20 hostapd: ral0: STA 00:1c:bf:xx:xx:xx IEEE 802.11: deassociated
          Jun 14 10:44:20 hostapd: ral0: STA 00:1c:bf:xx:xx:xx IEEE 802.11: deauthenticated due to local deauth request
          Jun 14 10:44:22 hostapd: ral0: STA 00:1c:bf:xx:xx:xx IEEE 802.11: associated
          Jun 14 10:44:23 hostapd: ral0: STA 00:1c:bf:xx:xx:xx IEEE 802.11: deassociated

          .... (Disable) Uncheck box at "WPA:Enable WPA" Opt 1 interface

          Jun 14 10:48:45 kernel: ral0: promiscuous mode disabled
          Jun 14 10:48:45 kernel: xl1: promiscuous mode disabled
          Jun 14 10:48:47 kernel: bridge0: Ethernet address: 3a:56:xx:xx:xx
          Jun 14 10:48:48 kernel: ral0: promiscuous mode enabled
          Jun 14 10:48:48 kernel: xl1: promiscuous mode enabled
          Jun 14 10:49:00 kernel: ral0: promiscuous mode disabled
          Jun 14 10:49:00 kernel: xl1: promiscuous mode disabled
          Jun 14 10:49:02 kernel: bridge0: Ethernet address: c2🆎4a:xx:xx:xx
          Jun 14 10:49:04 kernel: ral0: promiscuous mode enabled
          Jun 14 10:49:04 kernel: xl1: promiscuous mode enabled
          Jun 14 10:49:08 php: /interfaces_opt.php: Creating rrd update script
          Jun 14 10:49:11 check_reload_status: reloading filter

          ... (Enable) check box at "WPA:Enable WPA" Opt 1 interface

          Jun 14 10:50:57 kernel: ral0: promiscuous mode disabled
          Jun 14 10:50:57 kernel: xl1: promiscuous mode disabled
          Jun 14 10:50:59 kernel: bridge0: Ethernet address: fa:3e:7b:xx:xx:xx
          Jun 14 10:51:00 kernel: ral0: promiscuous mode enabled
          Jun 14 10:51:00 kernel: xl1: promiscuous mode enabled
          Jun 14 10:51:13 kernel: ral0: promiscuous mode disabled
          Jun 14 10:51:13 kernel: xl1: promiscuous mode disabled
          Jun 14 10:51:15 kernel: bridge0: Ethernet address: b2:86:b7:xx:xx:xx
          Jun 14 10:51:17 kernel: ral0: promiscuous mode enabled
          Jun 14 10:51:17 kernel: xl1: promiscuous mode enabled
          Jun 14 10:51:21 php: /interfaces_opt.php: Creating rrd update script
          Jun 14 10:51:25 check_reload_status: reloading filter

          ... Successful client Wifi Connection

          Jun 14 10:53:25 hostapd: ral0: STA 00:1c:bf:xx:xx:xx IEEE 802.11: associated
          Jun 14 10:53:26 hostapd: ral0: STA 00:1c:bf:xx:xx:xx WPA: pairwise key handshake completed (RSN)
          Jun 14 10:54:12 hostapd: ral0: STA 00:1c:bf:xx:xx:xx WPA: group key handshake completed (RSN)

          1 Reply Last reply Reply Quote 0
          • J
            jvin248
            last edited by

            After changing Key Rotation to 9000 and Master Key Rotation to 9999 seconds … the time to when the client is kicked off and cannot reconnect is indeed lengthened .. but 2.5 hours doesn't really solve the problem.

            Any suggestions on a possible fix?

            Version 1.2.3-RELEASE
            built on Sun Dec 6 23:21:36 EST 2009
            Platform cdrom
            Uptime 50 days, 14:24
            State table size 66/10000
            MBUF Usage 383 /1155

            1 Reply Last reply Reply Quote 0
            • D
              DamienD
              last edited by

              @DamienD:

              Hello,

              Same problem here…

              running pfsense 1.2.3 on ALIX mb

              somebody have a solution?

              Do you need more infos?

              Could it be related to the key rotation value?  http://forum.pfsense.org/index.php/topic,32038.0.html

              With the default value of 60 It holds up for about 4 days before starting to bug... I changed to 1800 to see if it improves anything.

              regards

              It has been up for about 88 days without any problem… Seems to be the solution for me at least.

              1 Reply Last reply Reply Quote 0
              • First post
                Last post