wlan deauth immediately after auth by local choice (reason=3)

thenextdon13 · 2013-05-30 21:57:45

Hello-
Somtimes when trying to connect to public wifi networks, I have to restart my machine to be able to connect.

I've searched the forums and found a few solved threads regarding this, but none of them seem to apply to me.
https://bbs.archlinux.org/viewtopic.php?id=146052 - problem seems to be multiple different network control daemons running, or sysinit rc mixed with systemd
https://bbs.archlinux.org/viewtopic.php?id=136482&p=2 - problem appeared to be a bug in NetworkManager that is since closed
https://bbs.archlinux.org/viewtopic.php?id=132079 -- it may be this but i'm unclear- it appears to be disabling the 11n and using swcrypto instead of hardware. Is this something that others have seen? INext time it happens i can try to test this.

Computer/Kernel info

[dylan@zenbook conf.d]$ uname -a
Linux zenbook 3.9.4-1-ARCH #1 SMP PREEMPT Sat May 25 16:14:55 CEST 2013 x86_64 GNU/Linux
[dylan@zenbook conf.d]$ sudo dmidecode | grep -i "Base Board" -A 3 
Base Board Information
	Manufacturer: ASUSTeK COMPUTER INC.
	Product Name: UX32A
	Version: 1.0

Network Interface Info:

[dylan@zenbook conf.d]$ lspci -kvs 02:00.0
02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6235 (rev 24)
	Subsystem: Intel Corporation Centrino Advanced-N 6235 AGN
	Flags: bus master, fast devsel, latency 0, IRQ 46
	Memory at f7c00000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

I seem to still be having this happen, but don't have netcfg, wicd, or 'network'.
I am using NetworkManager and have migrated entirely to systemctl/systemd

[dylan@zenbook conf.d]$ sudo ls -l /etc/rc.conf
ls: cannot access /etc/rc.conf: No such file or directory
[dylan@zenbook conf.d]$

Below is an example of trying to attach to an AP where it would authenticate then immediately deauthenticate.

May 30 13:51:06 zenbook kernel: wlan0: send auth to c4:10:8a:1d:a0:08 (try 1/3)
May 30 13:51:06 zenbook kernel: wlan0: authenticated
May 30 13:51:11 zenbook kernel: wlan0: deauthenticating from c4:10:8a:1d:a0:08 by local choice (reason=3)
May 30 13:51:11 zenbook NetworkManager[4915]: <info> (wlan0): supplicant interface state: authenticating -> disconnected
May 30 13:51:11 zenbook NetworkManager[4915]: <info> (wlan0): supplicant interface state: disconnected -> scanning
--
May 30 13:51:35 zenbook kernel: wlan0: send auth to 68:92:34:10:14:38 (try 1/3)
May 30 13:51:35 zenbook kernel: wlan0: send auth to 68:92:34:10:14:38 (try 2/3)
May 30 13:51:35 zenbook kernel: wlan0: authenticated
May 30 13:51:40 zenbook kernel: wlan0: deauthenticating from 68:92:34:10:14:38 by local choice (reason=3)
May 30 13:51:40 zenbook NetworkManager[4915]: <info> (wlan0): supplicant interface state: authenticating -> disconnected
May 30 13:51:40 zenbook NetworkManager[4915]: <info> (wlan0): supplicant interface state: disconnected -> scanning

Suggestions?
THanks!

ndt · 2013-06-02 22:51:18

Have you tried using netctl instead of NetworkManager? It's a replacement for netcfg that's built in to systemd. How are you connecting? I used to use ifconfig, iwconfig and wpa_supplicant manually with some success.

I don't have any specific experience with NetworkManager. However, it would be helpful to know if you're using some sort of GUI frontend, and if you are, that you have a keyring installed. Basically, make sure you've tried all the relevant stuff in the troubleshooting section of the Wiki.

Edit: gandalf13 seems to have found a solution.

Last edited by ndt (2013-06-02 22:53:22)

WonderWoofy · 2013-06-03 01:14:18

@ndt, netctl is not "built in to systemd", but rather, like netcfg, is a set of bash scripts that handle network connectivity. They are separate from systemd completely, and unless adopted by others, are unique to Arch Linux. Tough, since they make use of systemd features, in particular the BindTo= configuration option, they are much better than netcfg, providing much less race issues. But as a set of scripts that rely on systemd features, something we all know is not unique to Arch Linux, netctl can actually be used as is in other distributions, unlike netcfg.

Gandalf13's solution to his problems was that he had more than one network manager still enabled. If you read through the OP's post you will find the first link that says that he/she already found a nearly identical problem/fix.

@OP, can you post the output of "systemctl --type=services" just as a sanity check? I know you are pretty certain that you got all the services, but maybe there was something that you accidentally overlooked. Where are these access points you are trying to connect to? Are they public? Do they have a password? If they are open networks, can you try using just basic networking tools to connect? For example you can use iwconfig or iw to do this if there is no encryption or just wep, while wpa and wpa2 obviously require wpa_supplicant.

I think that if you try to connect manually with the basic tools, and it works, then you at least can narrow it down to being NetworkManager or not NetworkManager. Also, it might be worth it to try installing and trying wicd, or netctl, or connman to see if one of those gets better success. I think that connman might be the most interesting since it is pretty different from the others.

ndt · 2013-06-03 02:24:54

@WonderWoofy Thanks for the explanation! I had a feeling I wasn't being quite accurate about netctl. However, it's good to know that it's able to be used on other distros. I really think it's an excellent tool (as was netcfg).

OP, I just remembered that I have encountered this problem myself from time to time, and it was often due to an rfkill (no idea how that occurs, but I know how to fix it):

# sudo rfkill unblock wlan0

Change "wlan0" to whatever your wireless interface is, of course, before attempting. You can use "rfkill list" to view rfkills on any devices.

As for other possible solutions (once you've tried something besides networkmanager, as suggested), it would be handy to see the output of dmesg around the time of the failure. Hopefully you are able to reproduce this problem, and it doesn't involve going to that one specific cafe you might have troubles at.

Last edited by ndt (2013-06-03 02:25:57)

thenextdon13 · 2013-06-06 06:22:31

WonderWoofy wrote:

--snip
@OP, can you post the output of "systemctl --type=services" just as a sanity check? I know you are pretty certain that you got all the services, but maybe there was something that you accidentally overlooked. Where are these access points you are trying to connect to? Are they public? Do they have a password? If they are open networks, can you try using just basic networking tools to connect? For example you can use iwconfig or iw to do this if there is no encryption or just wep, while wpa and wpa2 obviously require wpa_supplicant.
I think that if you try to connect manually with the basic tools, and it works, then you at least can narrow it down to being NetworkManager or not NetworkManager. Also, it might be worth it to try installing and trying wicd, or netctl, or connman to see if one of those gets better success. I think that connman might be the most interesting since it is pretty different from the others.

Thank you, WonderWoofy-
This problem was public APs without encryption. Next time i will try using iwconfig + dhclient to configure and see how it works - for some odd reason I didn't think of that hah.
Understood on trying other network management utilities. I would like to track down the problem or file bug if it _is_ NetworkManager - and it rarely happens - so I will probably try to troubelshoot further

Here is the output of systemctl --type=services.. umm I don't think this is what you were looking for

[dylan@zenbook ~]$ sudo systemctl --type=services:
[sudo] password for dylan: 
Unknown unit type or load state 'services:'.
Use -t help to see a list of allowed values.
[dylan@zenbook ~]$

But a quick look found what you were describing:

[dylan@zenbook ~]$ sudo systemctl -t help
Available unit types:
service
socket
target
device
mount
automount
snapshot
timer
swap
path

Available unit load states: 
stub
loaded
error
merged
masked
[dylan@zenbook ~]$ 

[dylan@zenbook ~]$ sudo systemctl --type=service
UNIT                           LOAD   ACTIVE SUB     DESCRIPTION
acpid.service                  loaded active running ACPI event daemon
asus-kbd-backlight.service     loaded active exited  Allow user access to keyboard backlight
dbus.service                   loaded active running D-Bus System Message Bus
getty@tty1.service             loaded active running Getty on tty1
laptop-mode.service            loaded active exited  Laptop Mode Tools
ModemManager.service           loaded active running Modem Manager
NetworkManager.service         loaded active running Network Manager
ntpd.service                   loaded active running Network Time Service
polkit.service                 loaded active running Authorization Manager
slim.service                   loaded active running SLiM Simple Login Manager
systemd-journald.service       loaded active running Journal Service
systemd-logind.service         loaded active running Login Service
systemd-modules-load.service   loaded failed failed  Load Kernel Modules
systemd-remount-fs.service     loaded active exited  Remount Root and Kernel File Systems
systemd-sysctl.service         loaded active exited  Apply Kernel Variables
systemd-tmpfiles-setup.service loaded active exited  Recreate Volatile Files and Directories
systemd-udev-trigger.service   loaded active exited  udev Coldplug all Devices
systemd-udevd.service          loaded active running udev Kernel Device Manager
systemd-update-utmp.service    loaded active exited  Update UTMP about System Reboot/Shutdown
systemd-user-sessions.service  loaded active exited  Permit User Sessions
systemd-vconsole-setup.service loaded active exited  Setup Virtual Console
udisks.service                 loaded active running UDisks
upower.service                 loaded active running Daemon for power management
wpa_supplicant.service         loaded active running WPA supplicant

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

24 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

Will update again when i have the problem again.
Much appreciated!

WonderWoofy · 2013-06-06 15:03:35

Yeah, I did mean "systemctl --type=service" as you eventually figured out there. Sometimes I get tying too fast and get all typo crazy!

So unfortunately, I have actually seen other reports of issues with iwlwifi and public networks. I used to use this same card and never experienced them myself, but people who have issues with iwlwifi seem to really have issues with iwlwifi. There are some that indicate that disabling 80211n and enabling software encryption (rather than the default hw encryption) seems to imprve their situation. This can be done by adding the parameters to a configuariton file in /etc/modprobe.d. The specific parameters are 11n_disable=1 and swcrypto=1. If you want to give this a whirl w/o making it persistent across boots, you can just append those two things to a modprobe command. So unload the module (I like "modprobe -r" because it handles module dependencies, but rmmod will work as well), then do "modprobe iwlwifi 11n_disable=1 swcrypto=1". Or of course you can try each one at a time and see if one or the other seems to be an inprovment. The consequences of this should be pretty obvious, potentially lowered speeds and higher impact on cpu cycles.

I have also seen reports that this card has trouble finding the actual closest AP when it is an ESSID being broadcasted by APs all over the place. So you can try using "iwlist scan" then use the strongest open BSSID and connect to that. Of curse, if you won't want to use the deprecated "iwlist" you can use "iw <device> scan" instead.

And one more thing. I see you have wpa_supplicant.service running. Do you have any idea why this is running? This could very well be conflicting with your NetworkManager.service, as it means that two services are potentially trying to use the same program. Dhcpcd seems to handle a situation like this a bit more gracefully. If you have a dhcpcd process already going, then you try to start a new one (at least by hand, I'm not sure about by service) it sends the request to the main process. So before trying all that crap above, try simply disabling/stopping wpa_supplicant.service and then trying again. You really don't need that running anyway unless you know why you are using it.

thenextdon13 · 2013-06-06 15:19:49

Thank you for the information WonderWoofy.

I am not sure why I have wpa_supplicant.service running. Perhaps part of the base install? I don't _think_ I manually enabled it (suppose I could check the date of the symlink to see if it is the install date or something).

I probably won't get back to try this anytime in the next few days as I will be out of town, but I will test and mess around with it in the next week, I believe.

Much appreciate!

thenextdon13 · 2013-06-24 04:49:31

I'm back on a public hotspot today, and not having trouble- however I decided to try to dig into why wpa_supplicant is running.

I'm not seeing where it is being started, so i can't keep it from starting. I really don't understand this dbus stuff..

Here are the only mentions of it in /etc, other than its own directory (/etc/wpa_supplicant)

[dylan@zenbook etc]$ grep wpa_supplicant * -r -s | grep -v wpa_supplicant/
dbus-1/system.d/wpa_supplicant.conf:                <allow own="fi.w1.wpa_supplicant1"/>
dbus-1/system.d/wpa_supplicant.conf:                <allow send_destination="fi.w1.wpa_supplicant1"/>
dbus-1/system.d/wpa_supplicant.conf:                <allow send_interface="fi.w1.wpa_supplicant1"/>
dbus-1/system.d/wpa_supplicant.conf:                <allow receive_sender="fi.w1.wpa_supplicant1" receive_type="signal"/>
dbus-1/system.d/wpa_supplicant.conf:                <deny own="fi.w1.wpa_supplicant1"/>
dbus-1/system.d/wpa_supplicant.conf:                <deny send_destination="fi.w1.wpa_supplicant1"/>
dbus-1/system.d/wpa_supplicant.conf:                <deny send_interface="fi.w1.wpa_supplicant1"/>
dbus-1/system.d/wpa_supplicant.conf:                <deny receive_sender="fi.w1.wpa_supplicant1" receive_type="signal"/>
network.d/examples/wireless-wpa-config:DESCRIPTION='A wpa_supplicant configuration based wireless connection'
network.d/examples/wireless-wpa-config:WPA_CONF='/etc/wpa_supplicant.conf'

Looking at pstree, it appears to be started directly from systemd

systemd(1)-+-GoogleTalkPlugi(3436)-+-{GoogleTalkPlugi}(3437)
           |                       |-{GoogleTalkPlugi}(3438)
           |                       |-{GoogleTalkPlugi}(3439)
           |                       |-{GoogleTalkPlugi}(3457)
           |                       |-{GoogleTalkPlugi}(3458)
           |                       `-{GoogleTalkPlugi}(3459)
           |-ModemManager(899)-+-{ModemManager}(943)
           |                   `-{ModemManager}(955)
           |-NetworkManager(901)-+-dhclient(6985)
           |                     |-{NetworkManager}(1060)
           |                     |-{NetworkManager}(1549)
           |                     `-{NetworkManager}(1566)
...
...
...
           |-udisks-daemon(910)-+-udisks-daemon(942)
           |                    |-{udisks-daemon}(956)
           |                    `-{udisks-daemon}(1556)
           |-upowerd(1642)-+-{upowerd}(1643)
           |               `-{upowerd}(1644)
           |-wpa_supplicant(1560)
           |-xbindkeys(1584)
           |-xfce4-power-man(1599)---{xfce4-power-man}(1623)
           `-xfconfd(1639)

but when i look there doesn't appear to be a way to disable it (thanks bash-completion! hehe)

[dylan@zenbook etc]$ sudo systemctl disable                     
ModemManager.service                         dbus-org.freedesktop.ModemManager1.service   ntpd.service
NetworkManager.service                       dbus-org.freedesktop.NetworkManager.service  remote-fs.target
acpid.service                                display-manager.service                      slim.service
acpid.socket                                 getty@.service                               udisks.service
asus-kbd-backlight.service                   laptop-mode.service                          
[dylan@zenbook etc]$ sudo systemctl disable

However, it does seem happy to be stopped via systemctl..

[dylan@zenbook etc]$ sudo systemctl stop wpa_supplicant.service 
[sudo] password for dylan: 
[dylan@zenbook etc]$

And, when i stop it, i am immediately disconnected from wireless.
Followed by an immediate reconnect, and restart of the service.

[dylan@zenbook etc]$ sudo systemctl stop wpa_supplicant.service 
[sudo] password for dylan: 
[dylan@zenbook etc]$ sudo systemctl status wpa_supplicant.service 
wpa_supplicant.service - WPA supplicant
   Loaded: loaded (/usr/lib/systemd/system/wpa_supplicant.service; disabled)
   Active: active (running) since Sun 2013-06-23 21:46:12 PDT; 34s ago
 Main PID: 7303 (wpa_supplicant)
   CGroup: name=systemd:/system/wpa_supplicant.service
           └─7303 /usr/sbin//wpa_supplicant -u

Jun 23 21:46:12 zenbook systemd[1]: Starting WPA supplicant...
Jun 23 21:46:12 zenbook systemd[1]: Started WPA supplicant.
[dylan@zenbook etc]$ date
Sun Jun 23 21:46:58 PDT 2013

The best I can figure is that the wpa_supplicant service is in cahoots with NetworkManager somehow, since NetworkManager seems to be scarily 'smart' about re-spawning. Out of curiousity.. looking at pstree, it is still listed under systemd. Hmm

I'm stumped. It may be acting as expected..

WonderWoofy · 2013-06-24 05:16:12

It is definitely being started by NetworkManager. I just tried this out myself, and it was started as well. Strangely, I could not find any hint it is package contents about wpa_supplicant.service, though I already knew for a fact that it depended on wpa_supplicant itself.

I wonder if you could possibly try any other network management software and see if the problem persists. At least that way you might be able to determine if this is something to do with your Intel 6235 or the software. Though I don't use it on a regular basis anymore, I have found wicd to be extremely reliable in the past. You might also want to try using netctl's wifi-menu, as that makes things pretty damn simple too.

A bit less straight forward (as the project is still relatively young) is connman. Until I started using netctl again about a week ago, that had been my network management tool of choice for a while. Though you have to be aware that because netctl uses openresolv for its vpn functionality, it conflicts with the connman that is in the repos. But if you use connman-git from the AUR, it has the vpn stuff disabled, so can be installed along side netctl. You should also pick up connman-ui-git from the AUR as well, if you want hassle free network management with connman. I just use it to generate config files because I can't figure out a really easy way to do it otherwise with just the cli tools that connman provides.

sadol · 2013-12-04 17:49:41

Hi

I had the same problem on my newly installed machine:

uname -rv:

3.12.2-1-ARCH ...

lspci|grep theros:

05:00.0 Network controller: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) (rev 01)

At first I tried manually set up the wireless network like this:

ip link set dev wlp5s0 up
wpa_supplicant -Dnl80211 -B -iwlp5s0 -c /etc/wpa_supplicant.conf
dhcpcd wlp5s0

but realized that dhcpcd started wpa_supplicant once again:

...
dhcpcd[444]: wlp5s0: starting wpa_supplicant
...

so I removed wpa_supplicant hook from dhcpcd call:

dhcpcd wlp5s0 -C 10-wpa_supplicant

and problem was 'solved'.

thenextdon13 · 2014-01-09 01:47:26

I'm beginning to think this is a driver or firmware issue. Not only are there many posts with similar issues with this card (intel 6235) but--

I was investigating a wireless issue with OpenWRT, and have found a pattern; (https://dev.openwrt.org/ticket/14520)
The network card starts behaving badly on a relatively newly flashed openwrt N access point -- dropping lots of packets, iperf not completing correctly or hanging, etc
Then, if you change to another AP- G lets say- things 'seem' ok. Until you look at the ping response times.
The ping response times increase over the course of 3 pings.. stariting at up to 700ms or so..
Here is an example, but this is before the problem is so pronounced.. I believe at this point it will re-auth without a problem. When it will not re-auth, it is more like 3 pings between 'wrap-arounds' in latency.

[dylan@zenbook ~]$ ping bigbox
PING bigbox.dryhollow (192.168.11.10) 56(84) bytes of data.
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=1 ttl=64 time=1.45 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=2 ttl=64 time=1208 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=3 ttl=64 time=213 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=4 ttl=64 time=479 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=5 ttl=64 time=707 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=6 ttl=64 time=936 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=7 ttl=64 time=1165 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=8 ttl=64 time=159 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=9 ttl=64 time=383 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=10 ttl=64 time=612 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=11 ttl=64 time=840 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=12 ttl=64 time=1069 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=13 ttl=64 time=62.7 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=14 ttl=64 time=289 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=15 ttl=64 time=517 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=17 ttl=64 time=770 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=18 ttl=64 time=1007 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=19 ttl=64 time=8.21 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=20 ttl=64 time=122 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=21 ttl=64 time=144 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=22 ttl=64 time=271 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=23 ttl=64 time=497 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=24 ttl=64 time=781 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=25 ttl=64 time=954 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=26 ttl=64 time=1080 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=27 ttl=64 time=82.1 ms
64 bytes from bigbox.dryhollow (192.168.11.10): icmp_seq=28 ttl=64 time=103 ms

Note:
I _believe_ this only starts happening after trying to associate with that particular wireless N 20mhz 'open' openwrt router. But will confirm

thenextdon13 · 2014-01-09 06:18:46

Well, my suspicions were incorrect it seems.

I found the problem with my networking; It power save issues with laptop-mode tools. I will chase that up later.

However I have found perhaps a hint toward the deauth issue.

If i do the following, I get the de-auth reason=3 issue

turn off wifi using button/kill switch
modprobe -r iwldvm
modprobe -r iwlwifi
wait
modprobe iwlwifi
modprobe iwldvm
turn on wifi using button/kill switch

Doing this once leads for the de-auth to occur. Doing this twice confuses the kill switch and.. the LED indicates the radio is off when it is on, and on when it is off.

potterzot · 2014-05-14 15:40:21

I am getting the same error with a variety of network managers (netctl, wicd, network manager). The three suggestions I've seen online are:

1. disable ipv6 (add ipv6.disable=1 to kernel boot options)
2. turn off power saving (iw wlp1s0 set power_save off)
3. don't require a ca_cert for network manager

I've checked power saving multiple times and do not use network manager, so 2 and 3 aren't of much help for me, but I've just disabled ipv6, and we'll see if that helps. Included the other solutions in case they are of help to you.

Have you found anything else on this? Any suggestions of things to try that I missed?

Thanks.

vladev · 2014-11-04 21:16:47

After some digging some people are suggesting that wpa_supplicant messes up after suspend. See https://bugs.launchpad.net/ubuntu/+sour … ug/1311257.

Will test in the next days.

pavelpotocek · 2014-12-01 11:20:51

I spent like forever trying to track down the same issue. This thread frequently comes up on google, so I am posting my solution here. It seems that NetworkManager and dhcpcd should not be started by systemd at the same time. The following fixed my issues (using NetworkManager):

# systemctl stop dhcpcd
# systemctl disable dhcpcd

This is my setup:

$ uname -r
3.17.3-1-ARCH
$ lspci | grep Net
09:00.0 Network controller: Intel Corporation Centrino Wireless-N 1000 [Condor Peak]

and this is the problem I was dealing with:

$ dmesg | head -n20
[  754.886225] wlp9s0: RX AssocResp from ac:a3:1e:8a:d5:01 (capab=0x431 status=0 aid=10)
[  754.896513] wlp9s0: associated
[  755.304198] wlp9s0: deauthenticating from ac:a3:1e:8a:d5:01 by local choice (Reason: 3=DEAUTH_LEAVING)
[  755.332950] cfg80211: Calling CRDA to update world regulatory domain
[  755.780103] wlp9s0: authenticate with ac:a3:1e:8a:d5:01
[  755.798874] wlp9s0: send auth to ac:a3:1e:8a:d5:01 (try 1/3)
[  755.842491] wlp9s0: authenticated
[  755.845018] wlp9s0: associate with ac:a3:1e:8a:d5:01 (try 1/3)
[  755.866684] wlp9s0: RX AssocResp from ac:a3:1e:8a:d5:01 (capab=0x431 status=0 aid=10)
[  755.873156] wlp9s0: associated
[  756.142133] wlp9s0: deauthenticating from ac:a3:1e:8a:d5:01 by local choice (Reason: 3=DEAUTH_LEAVING)
[  756.164690] cfg80211: Calling CRDA to update world regulatory domain
[  756.501150] wlp9s0: authenticate with ac:a3:1e:8a:d5:01
[  756.518294] wlp9s0: send auth to ac:a3:1e:8a:d5:01 (try 1/3)
[  756.586295] wlp9s0: authenticated
[  756.588791] wlp9s0: associate with ac:a3:1e:8a:d5:01 (try 1/3)
[  756.592600] wlp9s0: RX AssocResp from ac:a3:1e:8a:d5:01 (capab=0x431 status=0 aid=10)
[  756.625923] wlp9s0: associated
[  764.208401] wlp9s0: deauthenticating from ac:a3:1e:8a:d5:01 by local choice (Reason: 3=DEAUTH_LEAVING)
[  764.227269] cfg80211: Calling CRDA to update world regulatory domain

Needless to say, the error messages were not helpful.

In my case, none of following solutions posted online had any effect: disable ipv6, turn off power saving, manually set world regulatory domain, set parameters for iwlwifi: sw_crypto=1, 11n_disable=1, bt_coex_active=N. It seems that "Reason: 3" is a very broad class of reasons.

mikro · 2014-12-09 09:44:18

pavelpotocek wrote:

# systemctl stop dhcpcd
# systemctl disable dhcpcd

Thanks Pavel, I had exactly the same problem and this fixed it for good! Cheers!

arrow7 · 2015-01-14 14:00:14

mikro wrote:

pavelpotocek wrote:
# systemctl stop dhcpcd
# systemctl disable dhcpcd
Thanks Pavel, I had exactly the same problem and this fixed it for good! Cheers!

+1 solved
i have lost many hours trying to fix this problem. The reason=3 message doesn't offer much help :\

Last edited by arrow7 (2015-01-14 14:00:56)

cteeto · 2015-03-31 17:14:42

vladev wrote:

After some digging some people are suggesting that wpa_supplicant messes up after suspend. See https://bugs.launchpad.net/ubuntu/+sour … ug/1311257.
Will test in the next days.

I have this same issue, I think I have tracked it down to the wpa_supplicant service (no other solution posted here has worked for me). After resuming from suspend, I get these same error messages when trying to connect again (reason=3), restarting wpa_supplicant.service the allows me to connect. As a workaround I put

systemctl restart wpa_supplicant

in my /etc/acpi/actions/lm_lid_open.sh, so that it does this when I open my lid (after a sleep 2), and it works great. Of course you need the acpi daemon and laptop-mode (I think these actions are added by laptop-mode).

glebtv · 2017-04-11 17:40:01

Had this exact problem, with one specific network (other networks work ok), but none of the posted solutions helped.

Solved by switching from dhcpcd to dhclient, no idea why. dhcpcd was never able to get IP address, but dhclient has no problems.
If using wicd, you can switch to dhclient in wicd app settings.

Posting here since this thread is 1st on Google on DEAUTH_LEAVING and related things that appear in dmesg for this problem.

WorMzy · 2017-04-11 17:54:35

glebtv wrote:

Posting here since this thread is 1st on Google on DEAUTH_LEAVING and related things that appear in dmesg for this problem.

That is not an excuse. Don't necrobump.

https://wiki.archlinux.org/index.php/Co … bumping.22

Closing.

Arch Linux

#1 2013-05-30 21:57:45

wlan deauth immediately after auth by local choice (reason=3)

#2 2013-06-02 22:51:18

Re: wlan deauth immediately after auth by local choice (reason=3)

#3 2013-06-03 01:14:18

Re: wlan deauth immediately after auth by local choice (reason=3)

#4 2013-06-03 02:24:54

Re: wlan deauth immediately after auth by local choice (reason=3)

#5 2013-06-06 06:22:31

Re: wlan deauth immediately after auth by local choice (reason=3)

#6 2013-06-06 15:03:35

Re: wlan deauth immediately after auth by local choice (reason=3)

#7 2013-06-06 15:19:49

Re: wlan deauth immediately after auth by local choice (reason=3)

#8 2013-06-24 04:49:31

Re: wlan deauth immediately after auth by local choice (reason=3)

#9 2013-06-24 05:16:12

Re: wlan deauth immediately after auth by local choice (reason=3)

#10 2013-12-04 17:49:41

Re: wlan deauth immediately after auth by local choice (reason=3)

#11 2014-01-09 01:47:26

Re: wlan deauth immediately after auth by local choice (reason=3)

#12 2014-01-09 06:18:46

Re: wlan deauth immediately after auth by local choice (reason=3)

#13 2014-05-14 15:40:21

Re: wlan deauth immediately after auth by local choice (reason=3)

#14 2014-11-04 21:16:47

Re: wlan deauth immediately after auth by local choice (reason=3)

#15 2014-12-01 11:20:51

Re: wlan deauth immediately after auth by local choice (reason=3)

#16 2014-12-09 09:44:18

Re: wlan deauth immediately after auth by local choice (reason=3)

#17 2015-01-14 14:00:14

Re: wlan deauth immediately after auth by local choice (reason=3)

#18 2015-03-31 17:14:42

Re: wlan deauth immediately after auth by local choice (reason=3)

#19 2017-04-11 17:40:01

Re: wlan deauth immediately after auth by local choice (reason=3)

#20 2017-04-11 17:54:35

Re: wlan deauth immediately after auth by local choice (reason=3)

Board footer