18

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.
GPraz
  • 459

5 Answers5

16

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.

GPraz
  • 459
  • 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 05 '17 at 01: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 08: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 08 '19 at 17:26
  • 2
    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
  • This solution works for those using systemd.networkd. If your are using NetworkManager only, you have to write a rule at /etc/udev/rules.d. – rodvlopes Jan 16 '20 at 19:03
  • Looks like interface names are handled by systemd-udevd. This strange symlink disables configuration file /usr/lib/systemd/network/99-default.link. Empty file should work too.See https://www.freedesktop.org/software/systemd/man/systemd.link.html – yarolig Jan 18 '20 at 18:49
  • Worked for me in a Debian 10 using Linksys WUSB54GC. I had to unplug and plug the USB adapter for changes to take effect. Adding 'SUBSYSTEM=="net", ACTION=="add", KERNEL=="wlan*", NAME="wlan0"' to /etc/udev/rules.d/70-persistent-net.rules also works. – Luciano Afranllie Apr 26 '20 at 04:12
  • 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 according – user3249994 Sep 26 '17 at 19:53
  • This solution didn't work for me as my wlan link name is wlan0 but I get the exact same error. I use openSUSE 15.4 with Gnome (latest) – aLuViAn Mar 04 '23 at 09:11
10

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:

In 

/etc/udev/rules.d/70-persistent-net.rules

add:

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

AdminBee
  • 22,803
Maciek
  • 101
  • 1
  • 4
  • 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 07: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 02 '19 at 04:37
  • the links is broken! – nabulator Nov 04 '19 at 13:34
  • 1
    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 '20 at 18:54
5

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.

systemd.networkd

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:

[Match]
Type=wlan

[Link]
Name=wlan0

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

NetworkManager

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.

rodvlopes
  • 958
  • 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 '20 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 '20 at 19:24
2

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

thosch66
  • 21
-1

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.

user36313
  • 101