I installed Debian 9 stretch (GNOME desktop) 64-bit on my PC. My USB wireless adapter (TP-LINK TL-WN722N) was detected automatically after installing atheros firmware:

apt-get install firmware-atheros

But I can't connect to any wireless framework, whether they are protected with password or unprotected.

I plugged my USB. It was detected, sent auth, got authenticated, but immediately aborted authentication. Disabling IPV6 did not solve my problem.. Here is my dmesg report:

[   59.880805] usb 1-1.4: new high-speed USB device number 4 using ehci-pci
[   60.005727] usb 1-1.4: New USB device found, idVendor=0cf3, idProduct=9271
[   60.005729] usb 1-1.4: New USB device strings: Mfr=16, Product=32, SerialNumber=48
[   60.005731] usb 1-1.4: Product: USB2.0 WLAN
[   60.005732] usb 1-1.4: Manufacturer: ATHEROS
[   60.005734] usb 1-1.4: SerialNumber: 12345
[   60.324981] usb 1-1.4: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
[   60.325069] usbcore: registered new interface driver ath9k_htc
[   60.348095] usb 1-1.4: firmware: direct-loading firmware ath9k_htc/htc_9271-1.4.0.fw
[   60.629962] usb 1-1.4: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
[   60.880826] ath9k_htc 1-1.4:1.0: ath9k_htc: HTC initialized with 33 credits
[   61.111895] ath9k_htc 1-1.4:1.0: ath9k_htc: FW Version: 1.4
[   61.111897] ath9k_htc 1-1.4:1.0: FW RMW support: On
[   61.111899] ath: EEPROM regdomain: 0x809c
[   61.111900] ath: EEPROM indicates we should expect a country code
[   61.111901] ath: doing EEPROM country->regdmn map search
[   61.111911] ath: country maps to regdmn code: 0x52
[   61.111912] ath: Country alpha2 being used: CN
[   61.111912] ath: Regpair used: 0x52
[   61.122477] ieee80211 phy0: Atheros AR9271 Rev:1
[   61.185069] ath9k_htc 1-1.4:1.0 wlx18a6f7160a49: renamed from wlan0
[   61.224640] IPv6: ADDRCONF(NETDEV_UP): wlx18a6f7160a49: link is not ready
[   61.361032] IPv6: ADDRCONF(NETDEV_UP): wlx18a6f7160a49: link is not ready
[   61.535923] IPv6: ADDRCONF(NETDEV_UP): wlx18a6f7160a49: link is not ready
[   61.743450] IPv6: ADDRCONF(NETDEV_UP): wlx18a6f7160a49: link is not ready
[   69.190250] IPv6: ADDRCONF(NETDEV_UP): wlx18a6f7160a49: link is not ready
[   70.360621] wlx18a6f7160a49: authenticate with 74:23:44:dc:0f:d7
[   70.551637] wlx18a6f7160a49: send auth to 74:23:44:dc:0f:d7 (try 1/3)
[   70.556012] wlx18a6f7160a49: authenticated
[   75.555233] wlx18a6f7160a49: aborting authentication with 74:23:44:dc:0f:d7 by local choice (Reason: 3=DEAUTH_LEAVING)
[   76.872114] wlx18a6f7160a49: authenticate with 74:23:44:dc:0f:d7
[   77.061146] wlx18a6f7160a49: send auth to 74:23:44:dc:0f:d7 (try 1/3)
[   77.065158] wlx18a6f7160a49: authenticated
[   82.061225] wlx18a6f7160a49: aborting authentication with 74:23:44:dc:0f:d7 by local choice (Reason: 3=DEAUTH_LEAVING)
[   83.775718] wlx18a6f7160a49: authenticate with 74:23:44:dc:0f:d7
[   83.965040] wlx18a6f7160a49: send auth to 74:23:44:dc:0f:d7 (try 1/3)
[   83.969807] wlx18a6f7160a49: authenticated
[   88.969792] wlx18a6f7160a49: aborting authentication with 74:23:44:dc:0f:d7 by local choice (Reason: 3=DEAUTH_LEAVING)
[   91.207178] wlx18a6f7160a49: authenticate with 74:23:44:dc:0f:d7
[   91.395860] wlx18a6f7160a49: send auth to 74:23:44:dc:0f:d7 (try 1/3)
[   91.400263] wlx18a6f7160a49: authenticated
[   93.996839] wlx18a6f7160a49: aborting authentication with 74:23:44:dc:0f:d7 by local choice (Reason: 3=DEAUTH_LEAVING)
[   94.061841] IPv6: ADDRCONF(NETDEV_UP): wlx18a6f7160a49: link is not ready
[   94.233433] IPv6: ADDRCONF(NETDEV_UP): wlx18a6f7160a49: link is not ready

I have no idea why this happened, nor why it was aborted multiple times in one try.

Edit: iwconfig report:

enp3s0    no wireless extensions.

wlx18a6f7160a49  IEEE 802.11  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=20 dBm   
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off

lo        no wireless extensions.
  • How close are you from that AP – Rui F Ribeiro Aug 18 '17 at 11:45

Somehow, my firmware got trouble with long interface name. So I ran this command to prevent it:

ln -s /dev/null /etc/systemd/network/99-default.link

and it worked.

  • I observed the very same issue with an rt2x00 and this workaround worked immediately. I'd appreciate though if someone could explain why it works and what the proper solution is. – Helmut Grohne Oct 28 '17 at 16:24
  • 3
    While I agree this is a functional workaround, it would be fantastic if someone could explain the "why" a bit better... My guess is it has to do with something in NetworkManager but that's purely a punt. – C.J. Steele Nov 5 '17 at 1:27
  • For some reason, this appears to be working on my Netgear WG111v2 (RTL 8187b chipset). However, this WiFi adapter comes and goes, so maybe I'm declaring victory too soon. – TSJNachos117 Mar 23 '18 at 8:20
  • 1
    This helps, I've been fighting this issue for over a month, I upgraded my debian few months ago and started seeing this problem , but with only specific routers. I have intel wifi chip (iwlwifi module). – Krzysztof Krasoń Feb 8 '19 at 17:26
  • 1
    This works for my Ralink MTK7601u wireless adapter. $ sudo nmcli dev wifi connect MySSID raises an error message like Error: Connection activation failed: (53) The Wi-Fi network could not be found. The dmesg report is almost the same. – Arnie97 Nov 29 '19 at 20:09

As others said the issue is caused by non-standard name the device gets (i.e. not wlan*). Linking /dev/null did not work for me, so I had to create a udev rule to rename the interface:




SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTRS{product}=="802.11 n WLAN", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan1"

Adjust ATTRS{product} to your specific device. Check how to find it here

  • I'm having this same issue, and am just coming across this solution ... Is it only ATTRS{product} that needs to be replaced? Does DRIVERS also need to have something there or is it actually supposed to be set to =? Thanks! – J. Taylor Jan 31 '19 at 7:37
  • 1
    Did it over a year ago and frankly don't remember the details. I believe ATTRS{product} should be enough to match your device. Also, it should be DRIVERS=="?*" - stack ate the star. – Maciek Feb 2 '19 at 4:37
  • the links is broken! – nabulator Nov 4 '19 at 13:34
  • This is the solution for those who are using NetworkManager. This rule can be more flexible so that you don´t have to care about the ATTRS{product}. Mine is woking with this configuration: SUBSYSTEM=="net", ACTION=="add", KERNEL=="wlan*", NAME="wlan0" – rodvlopes Jan 16 at 18:54

I'm glad you posted and found a solution to your own problem, I had something similar with the same distro, with an rtl8192 based key (Netgear WNA3100M to be precise), the systemd ̀link trick you mentioned fixed it, thanks.

Just to add up that this article helped me understand why the fix actually works; it's because we're overriding default /lib/systemd/network/99-default.link file which contains a ̀NamePolicy which does not please the firmware.

BTW, I still had problems joining some networks. It happened that the default regulatory domain did not match my location, so I had to issue a iw reg set <MyCountryCode> and edit the /etc/default/crda file accordingly.


I have the same problem with two different USB WiFi sticks. The fix also worked in my case, thanks.
I think that the problem is connected to NetworkManager and to the firmware: when I used the same computer and USB sticks, the same Linux distribution (Debian 9.3), but used wicd instead of NetworkManager, then the long, non-standard device names were working, and this fix was not necessary.

  • I installed wicd and it connected fine after that, thanks ! – Hayden Thring Mar 14 '18 at 8:24

The accepted answer works for me too. But I am not sure, that using a link to /dev/null is the best solution, cause in 3 or 4 months I will be very confused finding such a link in this place.

In the Raspbian-Installation on my Raspberry Pi I found a regular file /etc/systemd/network/99-default.link with the following content:

# This machine is most likely a virtualized guest, where the old persistent
# network interface mechanism (75-persistent-net-generator.rules) did not work.
# This file disables /lib/systemd/network/99-default.link to avoid
# changing network interface names on upgrade. Please read
# /usr/share/doc/udev/README.Debian.gz about how to migrate to the currently
# supported mechanism.

I use this regular file instead of the symbolic link to fix the problem. I think this solution has the advantage that there is some sort of documentation on the system (perhaps I should add a link to this page…).

This will give a hint of what is going on to future-me. >;->


As others said, the issue is caused by non-standard name the device gets (i.e. not wlan*). Below is the proper ways to set the name of the network interface when using systemd.networkd or NetworkManager.


While linking to /dev/null may solve the problem, the proper way is to create a .link file setting the device name.

Create /etc/systemd/network/50-wlan.link with the following content:



Reboot or restart the network then check the result: udevadm info /sys/class/net/wlan0 | grep ID_NET_NAME=

More details and debug information can be found here: https://www.freedesktop.org/software/systemd/man/systemd.link.html


When using NetworkManager the interface rename can be achieved by creating a rule at the /etc/udev/rules.d directory.

Create /etc/udev/rules.d/70-rename-wlan.rules with the following content:

SUBSYSTEM=="net", ACTION=="add", KERNEL=="wlan*", NAME="wlan0"

If everything went right you should see wlan0 among your devices after a reboot.

root@bananapi:~# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group 
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group 
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group 

And you be able to connect to the wifi using nmcli d wifi connect MEU_WIFI_SSID password MEU_PASSWORD. The nmcli will persist the connection and reconnect after a reboot.

  • I think neither NetworkManager nor systemd-networkd renames your device. That is done by udev. So, yes, writing a udev rule works and so does creating a .link file (in that case, the .link file is processed by udev, not systemd-networkd). – thaller Feb 12 at 18:47
  • In the second example its clear that the udev is getting the job done, not NetworkManager. You may be right tough, but in the second example systemd-networkd can get the job done as well (perhaps it talks to udev under the hood). – rodvlopes Feb 13 at 19:24

Accepted solution did not work for me.

I have solved the problem by disabling IPv6 in the connection properties. Run nm-connection-editor, select your troubled connection, press the button with the gear icon (in my case), go to the "IPv6 Settings" tab, in the field Method select "Ignore" option.

Not the answer you're looking for?Browse other questions tagged or ask your own question.