Azimout's Linux weblog

deauthenticating, reason=3

with 56 comments

Lately I’m having trouble connecting to my wifi at home; the messages in dmesg are:

wlan0: direct probe to AP 00:24:01:e7:94:75 (try 1)
wlan0: direct probe responded
wlan0: authenticate with AP 00:24:01:e7:94:75 (try 1)
wlan0: authenticated
wlan0: associate with AP 00:24:01:e7:94:75 (try 1)
wlan0: RX AssocResp from 00:24:01:e7:94:75 (capab=0x431 status=0 aid=3)
wlan0: associated
wlan0: deauthenticating from 00:24:01:e7:94:75 by local choice (reason=3)
wlan0: deauthenticating from 00:24:01:e7:94:75 by local choice (reason=3)

So it probes, authenticates, associates and then makes a “local choice” to deauthenticate with reason=3. Where is this coming from? kernel? network manager? wpa-supplicant? And why is it happening?

Hmm, this seems to be coming from the kernel, from net/mac80211/mlme.c. The values for this reason_code can be found in include/linux/ieee80211.h under enum ieee80211_reasoncode, and value 3 means “WLAN_REASON_DEAUTH_LEAVING” (which doesn’t say much).

UPDATE 15.01.2011: Killing wpa_supplicant seems to resolve the issue for some people. If it works for you, please leave a comment saying so.


Written by azimout

22/02/2010 at 19:39

Posted in Problems

56 Responses

Subscribe to comments with RSS.

  1. I’m having this same problem. Did you ever find a fix for it?


    02/05/2010 at 04:17

    • I’ve upgraded to Lucid (10.04) and the problem went away…


      02/05/2010 at 08:18

  2. This comes up when I google the problem, so I figure I’ll post something. The problem in my case was caused by network manager disconnecting. I found more info in /var/log/daemon.log. That in turn seems to be caused by a problem with the card not obtaining a dhcp lease, which causes NM to make a call back to the kernel tht it’s disconnecting.

    Anyway, I think in my case it’s caused by a bad driver stopping all traffic on the card.


    04/06/2010 at 12:47

    • Thanks Dave. If you find out more, please let me know. Thanks!


      04/06/2010 at 13:05

  3. I didn’t have /var/log/daemon.log or NetworkManager running, but, when checking to see if I had NetworkManager running with ps -x, I discovered that I had three copies of wpa_supplicant running. I did a killall wpa_supplicant, then restarted just one of them, and the problem went away. Maybe you guys can check if you have more than one such client running, which seemed to cause it to disconnect and reconnect a lot, as described above (reason 3 etc).


    29/06/2010 at 01:11

    • I have just had the same problem when I enabled IPv6 through Network Manager on Ubuntu 10.04.
      Can’t connect with IPv6 enabled – automatic address, works perfectly when I disabel it.

      Wired ethernet works fine with IPv6 through the same router so it may not be the router.


      24/09/2010 at 09:36

    • I’ve been battling with flaky wireless for a few days now. Google search with ‘deauthenticating, reason=3’ brought me here. I’m running Ubuntu 10.10 with NetworkManager. Carl’s tip on wpa_supplicants saved my day. I didn’t have three of them running, nor did I restart any of those. I killed the only instance of it, then told network manager’s panel applet to connect to my AP and it succeeded. I don’t know the root cause of the problem, yet, but at least I know a workaround: kill wpa_supplicant. Thanks!


      15/10/2010 at 03:34

      • That’s good to know, thank you Kontza


        15/10/2010 at 08:09

      • Carl & Kontza,

        You guys made my day! I bought an ASUS N53JQ-XC1 laptop with the Atheros AR9285 wireless chipset. I’ve tried for one week without making the wireless working before I googled and arrived here.

        I am running Ubuntu 10.10, and initially I thought it was driver issue, I tried everything, ath9k, ndiswrapper, compat-wireless, none worked.

        Then I suspected it’s the WEP passphrase vs. hex key, it was not, either. BTW, I am lazy so I did not bother to change my wireless router with WEP-128bit for 6 years.

        Checking with ‘dmesg’ and daemon.log and syslog under /var/log shows that AP was seen, but wpa_supplicant throwing errors. WTH? I am running WEP, why should WPA stuff run?

        Then I saw your post, killed the only wpa_supplicant process, BOOM!!! Works like a charm.

        I am going to change my init scripts to disable wpa_supplicant loading upon startup.

        Hope this could help someone else.

        Alex Y.

        02/12/2010 at 16:04

      • I have been struggling with my wireless and maverick for a few months now – was on the verge of downgrading to lucid when I stumbled upon this page. Thanks Köntzä!! Kill wpa_supplicant was a gem of an advice 🙂


        14/01/2011 at 13:45

  4. I also had this issue when using Lucid (kUbuntu), but my problem went away when i removed network-manager (apt-get remove network-manager). ifdown wlan0 and ifup wlan0 then works perfectly. I have my wireless configuration preset in /etc/network/interfaces. Whenever I tried to kill one of my two wpa_supplicant processes, it respawned automatically, and did not help me.

    Vegard Fremstad

    30/10/2010 at 11:50

    • Same here. Just upgraded to Lucid (Mythbuntu) from Jaunty and the wireless broke. I took down the wireless interface, uninstalled network-manager and then killed wpa_supplicant for good measure. When I brought the wireless interface back up it worked fine. Thanks!


      19/11/2010 at 06:08

  5. I was having this problem on a Google Cr48 after removing the ubuntu-desktop packages when prepping to install ubuntu-netbook

    I repeatedly tried killing wpa_supplicant, but it would create a new instance each time. Executing apt-get remove wpasupplicant fixed the problem and I was able to connect with a simple ifup wlan0


    23/01/2011 at 21:44

  6. killall wpa_supplicant worked for me, too.
    Two instances were running. network-manager started (one instance of) wpa_supplicant again, and took about ten seconds to connect. During that time, /usr/var/syslog shows network-manager hammering commands at wpa_supplicant before wpa_supplicant is ready. I guess “hammering” is overstating it ;).

    I bet it was network-manager that started two wpa_supplicant instances in the first place, when I was disabling and enabling networking/wireless/etc.

    /usr/var/daemon.log showed trouble getting a dchp lease.
    /usr/var/syslog other errors. I assume it’s a mix of messages from both of the wpa_supplicant instances, whose state machines were doing confusing things to each other and the drivers. I’m pasting a few lines here, in case it helps anyone find this page.

    I hope this isn’t a reoccurring problem. Thanks for the solution!


    wpa_supplicant[1040]: WPA: Invalid EAPOL-Key MIC when using TPTK – ignoring TPTK
    wpa_supplicant[1040]: WPA: Could not verify EAPOL-Key MIC – dropping packet
    NetworkManager[18247]: (wlan0): supplicant connection state: 4-way handshake -> group handshake
    NetworkManager[18247]: (wlan0): supplicant connection state: group handshake -> completed
    wpa_supplicant[1040]: Authentication with 00:22:bd:da:aa:07 timed out.
    kernel: [201144.631336] wlan0: deauthenticating from 00:22:bd:da:aa:07 by local choice (reason=3)
    wpa_supplicant[1040]: CTRL-EVENT-DISCONNECTED – Disconnect event – remove keys
    kernel: [201144.821001] cfg80211: All devices are disconnected, going to restore regulatory settings
    Jan 31 21:36:41 hunny-bunny wpa_supplicant[7132]: CTRL-EVENT-DISCONNECTED – Disconnect event – remove keys
    Jan 31 21:36:41 hunny-bunny kernel: [201144.821009] cfg80211: Restoring regulatory settings
    Jan 31 21:36:41 hunny-bunny kernel: [201144.821014] cfg80211: Calling CRDA to update world regulatory domain
    Jan 31 21:36:41 hunny-bunny NetworkManager[18247]: (wlan0): supplicant connection state: completed -> disconnected
    Jan 31 21:36:41 hunny-bunny kernel: [201144.827101] cfg80211: World regulatory domain updated:
    Jan 31 21:36:41 hunny-bunny kernel: [201144.827106] (start_freq – end_freq @ bandwidth), (max_antenna_gain, max_eirp)
    Jan 31 21:36:41 hunny-bunny kernel: [201144.827112] (2402000 KHz – 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    Jan 31 21:36:41 hunny-bunny kernel: [201144.827117] (2457000 KHz – 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    Jan 31 21:36:41 hunny-bunny kernel: [201144.827122] (2474000 KHz – 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
    Jan 31 21:36:41 hunny-bunny kernel: [201144.827127] (5170000 KHz – 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    Jan 31 21:36:41 hunny-bunny kernel: [201144.827132] (5735000 KHz – 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
    Jan 31 21:36:41 hunny-bunny wpa_supplicant[7132]: Failed to initiate AP scan.
    Jan 31 21:36:41 hunny-bunny NetworkManager[18247]: (wlan0): supplicant connection state: disconnected -> scanning


    01/02/2011 at 06:06

  7. I had the same problem using Mavirck and TP-Link WN321G USB wireless adapter.
    I tried different solution from including installing wicd instead of network-manager.

    Nothing worked. The only thing that worked was to use the old 2.6.32-27 kernel instead of want ubuntu installed.

    I hope that one of you can make the people who can fix it aware of the problem.


    05/02/2011 at 20:23

  8. Even though I’ve subscribed to your RSS, I came here via Google. Killing wpa_supplicant worked indeed, I was messing around in order to get wpa_supplicant to work that long, that I didn’t notice the old processes weren’t stopped when starting it again.

    dhcpcd: wlan0: leased for 2592000 seconds
    YAY! Thanks 🙂


    26/02/2011 at 13:54

  9. Try enabling kdeWallet if you are using kde4.


    14/03/2011 at 20:59

    • This worked for me also, thank you. Just to repeat: Enabling kdeWallet on my 64bit OpenSuse 11 has fixed the problem of Wireless lan silently not working.

      All fixed.. great.


      01/09/2011 at 12:09

  10. I got the same problem running an Acer TravelMate 2490 Laptop with the BCM4318 chipset under Debian Squeezy. Disabling IPV6 through the “ipv6.disable=1” kernel boot option solved the problem. As far as I can tell, there is no running instance of wpa_supplicant by default.


    10/04/2011 at 21:10

    • I have the same chipset, but I’m running it on Lucid Linx and a Dell Laptop. There is no running instance of wpa_supplicant also.

      Bernardo Fontes

      12/04/2011 at 14:31

    • Thanks! .. blacklisting ipv6 under /etc/modprobe.d/blacklist.conf worked for me on a Meego device.


      14/08/2011 at 08:50

  11. helped me too. Thank you.


    29/05/2011 at 17:13

  12. I’m having the same problem. Killing wpa_supplicant doesn’t help. It only manages to connect when I first boot into windows and then reboot to linux.


    26/07/2011 at 08:07

  13. Thanks for the article. Great comments here!
    While struggling with this myself, I found a slight variation on the situations above. I saw only one instance of wpa_supplicant in my process list, but it was a much more involved command than what I was entering on the command line:

    wpa_supplicant -Dwext -iwlan0 -c[WPA conf file path]

    It occurred to me that this was due to the wpa_supplicant daemon running. I tried both killing it:

    kill -9 [WPA process ID]

    and stopping the daemon:

    /etc/init.d/wpa_supplicant stop

    But both resulted in the daemon immediately restarting itself with a new PID. Prove this by running:

    /etc/init.d/wpa_supplicant status


    ps aux | grep wpa

    It turns out NetworkManager is the culprit and is driving the wpa_supplicant daemon to be a persistent process (which is undesirable for our manual configuration). So we need to stop both processes:

    /etc/init.d/NetworkManager stop


    /etc/init.d/wpa_supplicant stop

    After this, you will be able to run your own wpa connection command with no fear of being deauthenticated by local choice due to the rogue daemon:

    wpa_supplicant -Dwext -iwlan0 -c[WPA conf file path]

    Then obtain network specific credentials and you’ll be off and running:

    dhclient wlan0

    My experience was on FC14 running kernel 2.6.35. Hope this was helpful!


    12/10/2011 at 04:56

  14. […] eventually worked out the difficulty I was having and posted the fix as a comment to a helpful blog post.Share this:TwitterFacebookLike this:LikeBe the first to like […]

  15. I’m having the same problem after enabling ipv6 on my wi-fi connection. It had a real tough time connecting, and took about ten attempts before it stayed up. It would either outright fail to connect, or connect and then disconnect after a few seconds.

    Disabling IPv6 fixed the problem, although it introduced the new problem of IPv6 being disabled. 😉

    For some reason after a reboot and about ten connection attempts it’s connected and stayed up for about ten minutes now. Can’t work out what’s going on.

    (Running Arch Linux, kernel 3.1.4-1-ARCH, NetworkManager fyi)


    09/12/2011 at 12:19

  16. check command ipcs
    in my case I had lost of shared memory allocated


    12/12/2011 at 19:49

  17. On Mandriva 2011 killall wpa_supplicant as root fixes it


    25/12/2011 at 15:27

  18. Ubuntu 11.10, BCM4312 chip.
    kill wpa_supplicant seems to help so far. Will try disabling ipv6 in the kernel boot option..


    09/01/2012 at 07:35

  19. dude you made my day running openwrt linux distribution on a x86 platform with a atheros ar5212 card causes the same deauthenticating, reason=3

    but after killing wpa_supplicant it doesn’t happen again frequently and is stable as ever


    25/01/2012 at 13:17

  20. Killing wpa_supplicant works for me, too. Has anybody figured out how to make this permanent?


    29/01/2012 at 20:12

  21. I’m running 11.04 – Natty Narwhal and I’m getting this problem but I suspect it has to do with the Network Card driver. I tried killing the wpa_suplicant process as stated here but it didn’t work. My solution was different, since the Network Manager was disconnecting from the Wireless Network because it was failing to get a DHCP lease I simply entered the IP Address, subnet mask, default gateway and DNS server manually from the Network Settings GUI.

    The next time I connected to the Wireless network it worked just fine. I’m somewhat concerned because this is not the way it is mean to work but it is a quick workaround.

    Sergio Bobillier

    31/01/2012 at 02:36

  22. Archlinux user here.
    I was having problems with that as well, the network kept disconnecting and deauthenticating, and when I ran “ps aux | grep wpa” I saw two wpa_supplicant instances, I killed them, tried again and now it works perfectly.

    Thanks a lot! 🙂


    02/02/2012 at 01:07

  23. Debian testing user here.

    I have also had the “deauthenticating … (reason=3)” error in syslog, when my wifi has failed. But it happened when I was mucking around with the stanzas in my /etc/wpa_supplicant/wpa-supplicant.conf file, which I was configuring for WPA2-Personal. When I added the line “group=CCMP” the wifi failed with the error=3 error. But when I changed it back to “group=TKIP”, it all worked fine. Tested and repeatable.

    So in my case, the error=3 error has occured when I’ve specified one type of encryption, and wpa_supplicant didn’t like it. Possible because my wireless router doesn’t support it? Not sure why. Obscure.


    18/07/2012 at 13:51

  24. OpenSuSE 12.1 user here. Wireless stopped working with the “deauthenticating… (reason=3) after switching between NetworkManager & ‘Traditional ifup’ method. There was only 1 wpa_supplicant process running, but sudo killall wpa_supplicant did the trick. Wireless connection happy again. Thanks for the advice.


    31/07/2012 at 08:44

  25. In my case it was a matter of Network Manager being unhappy about the quality of addresses received. I turned off IPv6 and told NM not to consider it a failure if it didn’t get an IPv4 address immediately. After that it went back to working properly.


    28/08/2012 at 02:18

    • I disabled the ipv6 module and that fixed it for me as well. I have an Ar9170 usb wifi adapter running on Linux kernel 3.4.10 and debian squeeze.


      05/09/2012 at 14:27

  26. Killing the already running wpa_supplicant started by already stopped wicd daemon and re-run my own wpa_supplicant command succeeded, thanks!


    28/08/2012 at 03:16

  27. […] – Free Electrons search ieee80211_reasoncode you can get all the reasoncode in kernel.) but deauthenticating, reason=3 here gives a possible solution: […]

  28. […] deauthenticating, reason=3 拜托这你自己也能 google 出来啊。 Reply With Quote […]

  29. Working on Raspberry Pi – raspbian – killing wpa_supplicant process ended two hours of frustartion with TL-WN722N adaptor – working perfectly on open network. Many thanks

    Jimmy C

    12/02/2013 at 15:08

  30. I found a similar article explaining WiFi Reason codes at although Killing WPA-Supplicant did help.


    19/02/2013 at 16:13

  31. […] to my Wi-Fi. I tried every way I knew and finally I started googling and I came across this post that finally shed some light on […]

  32. love to why this information is NO WHERE else, using WEP ? killall wpa_supplicant
    so happy I almost wept (pun intended)

    dr memals

    21/04/2013 at 20:47

  33. found a solution at a wiki on archlinux about Wireless_Setup in the first section about driver selection under ath5k (Atheros). it said to turn on driver option for software not hardware encryption if having problems leasing an IP. i had same dmesg wlan0 lines as shown by azimout – respond, authenticate, associate and deauthenticate – trying to do wpa2 w/passphrase using wpa supplicant. fixed it for me on “lildebeee” – an eee pc 900 using debian w/o a desktop aquired 8 mo ago, wiped, deb’d and seldom used . next week she’s gonna have a gender change, buy a bong and become “Wheeezy”.

    mouth breather

    02/05/2013 at 04:31

  34. […] deauthenticating, reason=3 | Azitech […]

  35. I’m having the same annoying problem with deauthenticaction on Kubuntu. I first noticed it in 12.04 and hoped that upgrading to 14.04 would help. But the problem persists. I do have internet access through wlan0, put it’s quite slow because it’s reconnecting all the time.
    I tried to kill the wpa_supplicant, but that doesn’t change anything. It just restarts.
    I tried to disable and to force ipv6, but nothing changed.
    I tried all the network manager settings for that connection.
    But still:
    yan@yan:~$ tail -f /var/log/syslog | grep deauthenticated
    Apr 19 12:19:03 yan kernel: [ 3467.790265] wlan0: deauthenticated from xx:xx:xx:xx:xx:xx (Reason: 3)
    Apr 19 12:19:16 yan kernel: [ 3480.759017] wlan0: deauthenticated from xx:xx:xx:xx:xx:xx (Reason: 3)
    Apr 19 12:19:29 yan kernel: [ 3493.826746] wlan0: deauthenticated from xx:xx:xx:xx:xx:xx (Reason: 3)
    Apr 19 12:19:36 yan kernel: [ 3500.820831] wlan0: deauthenticated from xx:xx:xx:xx:xx:xx (Reason: 3)
    Apr 19 12:19:59 yan kernel: [ 3523.949754] wlan0: deauthenticated from xx:xx:xx:xx:xx:xx (Reason: 3)
    Apr 19 12:20:07 yan kernel: [ 3532.034094] wlan0: deauthenticated from xx:xx:xx:xx:xx:xx (Reason: 3)
    Apr 19 12:22:19 yan kernel: [ 3663.722590] wlan0: deauthenticated from xx:xx:xx:xx:xx:xx (Reason: 3)
    Any more ideas?


    19/04/2014 at 10:33

    • Yan, what’s your wlan adapter?


      19/04/2014 at 11:48

      • Thanks for your answer. I’m using a Thinkpad T400:
        yan@yan:~$ lspci | grep Wireless
        03:00.0 Network controller: Intel Corporation PRO/Wireless 5100 AGN [Shiloh] Network Connection
        My Kubuntu version:
        yan@yan:~$ uname -a
        Linux yan 3.2.0-48-generic-pae #74-Ubuntu SMP Thu Jun 6 20:05:01 UTC 2013 i686 i686 i686 GNU/Linux


        19/04/2014 at 17:34

    • It seems this command solved the problem for me:
      echo “options iwlwifi 11n_disable=1″ | sudo tee /etc/modprobe.d/iwlwifi.conf > /dev/null


      20/04/2014 at 19:42

      • Thanks yan for sharing! Basically you have disabled 802.11n mode. Maybe this will be useful for someone else as well…


        20/04/2014 at 20:02

    • I tried it, but it doesn’t change anything, azimout.


      20/04/2014 at 11:43

  36. Had the same issue with Linux Mint, problem seemed to be DHCP-related.
    I did two things:
    – configure IPv4 manually (disable dhcp)
    – disable/ignore IPv6.
    Worked right away.


    01/07/2014 at 15:02

  37. thanks for the workaround: kill wpa_supplicant. (kubuntu 14.04)


    23/11/2014 at 19:40

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: