"Abortar la autenticación por elección local (Motivo: 3 = DEAUTH_LEAVING)" al intentar conectarse a wifi

13

Instalé Debian 9 stretch (escritorio GNOME) de 64 bits en mi PC. Mi adaptador inalámbrico USB (TP-LINK TL-WN722N) se detectó automáticamente después de instalar el firmware de atheros:

apt-get install firmware-atheros

Pero no puedo conectarme a ningún marco inalámbrico, ya sea que estén protegidos con contraseña o sin protección.

Conecté mi USB. Se detectó, se envió autenticación, se autenticó, pero inmediatamente se anuló la autenticación. Deshabilitar IPV6 no resolvió mi problema. Aquí está mi dmesginforme:

[   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

No tengo idea de por qué sucedió esto, ni por qué fue abortado varias veces en un solo intento.

Editar: informe de iwconfig:

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
fuente
¿Qué tan cerca estás de ese AP
Rui F Ribeiro

Respuestas:

15

De alguna manera, mi firmware tuvo problemas con el nombre largo de la interfaz. Entonces ejecuté este comando para evitarlo:

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

Y funcionó.

GPraz
fuente
Solo para agregar que este artículo me ayudó a entender por qué la solución realmente funciona; es porque estamos anulando por defecto /lib/systemd/network/99-default.linkel archivo que contiene una NamePolicy, que no agrada el firmware. Por cierto, todavía tenía problemas para unirme a algunas redes. Sucedió que el dominio regulador predeterminado no coincidía con mi ubicación, por lo que tuve que emitir iw reg set <MyCountryCode>y editar el /etc/default/crdaarchivo de acuerdo
user3249994
Observé el mismo problema con un rt2x00 y esta solución funcionó de inmediato. Sin embargo, agradecería si alguien pudiera explicar por qué funciona y cuál es la solución adecuada.
Helmut Grohne
3
Si bien estoy de acuerdo en que esta es una solución funcional, sería fantástico si alguien pudiera explicar el "por qué" un poco mejor ... Supongo que tiene que ver con algo en NetworkManager, pero eso es puramente un despeje.
CJ Steele
1
Esto ayuda, he estado luchando contra este problema durante más de un mes, actualicé mi Debian hace unos meses y comencé a ver este problema, pero solo con enrutadores específicos. Tengo chip wifi de Intel (módulo iwlwifi).
Krzysztof Krasoń
1
Esto funciona para mi adaptador inalámbrico Ralink MTK7601u. $ sudo nmcli dev wifi connect MySSIDgenera un mensaje de error como Error: Connection activation failed: (53) The Wi-Fi network could not be found.El informe dmesg es casi el mismo.
Arnie97
7

Como otros dijeron, el problema es causado por un nombre no estándar que obtiene el dispositivo (es decir, no wlan *). Vincular / dev / null no funcionó para mí, así que tuve que crear una regla udev para cambiar el nombre de la interfaz:

En

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

añadir:

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

Ajústelo ATTRS{product}a su dispositivo específico. Mira cómo encontrarlo aquí

Maciek
fuente
Estoy teniendo el mismo problema, y ​​estoy encontrando esta solución ... ¿Es solo ATTRS{product}eso lo que necesita ser reemplazado? No DRIVERSTambién es necesario tener algo allí, o en realidad supone que se establece en =?Gracias!
J. Taylor
1
Lo hice hace más de un año y, francamente, no recuerdo los detalles. Creo que ATTRS {producto} debería ser suficiente para que coincida con su dispositivo. Además, debería ser DRIVERS == "? *" - stack comió la estrella.
Maciek
¡los enlaces están rotos!
Nabulator
Esta es la solución para aquellos que usan NetworkManager. Esta regla puede ser más flexible para que no tenga que preocuparse por el ATTRS{product}. El mío funciona con esta configuración:SUBSYSTEM=="net", ACTION=="add", KERNEL=="wlan*", NAME="wlan0"
rodvlopes
1

Tengo el mismo problema con dos dispositivos USB WiFi diferentes. La solución también funcionó en mi caso, gracias.
Creo que el problema está conectado a NetworkManager y al firmware: cuando usé la misma computadora y memorias USB, la misma distribución de Linux (Debian 9.3), pero usé wicd en lugar de NetworkManager, entonces los nombres largos y no estándar del dispositivo eran trabajando, y esta solución no era necesaria.

Laszlo
fuente
Instalé wicd y se conectó bien después de eso, ¡gracias!
Hayden Thring
1

La respuesta aceptada también funciona para mí. Pero no estoy seguro de que usar un enlace a / dev / null sea la mejor solución, porque en 3 o 4 meses estaré muy confundido al encontrar ese enlace en este lugar.

En Raspbian -Installation en mi Raspberry Pi encontré un archivo regular /etc/systemd/network/99-default.link con el siguiente contenido:

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

Utilizo este archivo normal en lugar del enlace simbólico para solucionar el problema. Creo que esta solución tiene la ventaja de que hay algún tipo de documentación en el sistema (tal vez debería agregar un enlace a esta página ...).

Esto dará una pista de lo que le está sucediendo al futuro. >; ->

thosch66
fuente
0

Como otros dijeron, el problema es causado por un nombre no estándar que obtiene el dispositivo (es decir, no wlan *). A continuación se muestran las formas adecuadas de establecer el nombre de la interfaz de red cuando se usa systemd.networkd o NetworkManager .

systemd.networkd

Si bien el enlace /dev/nullpuede resolver el problema, la forma correcta es crear una .link fileconfiguración para el nombre del dispositivo.

Crea /etc/systemd/network/50-wlan.linkcon el siguiente contenido:

[Match]
Type=wlan

[Link]
Name=wlan0

Reinicie o reinicie la red y luego verifique el resultado: udevadm info /sys/class/net/wlan0 | grep ID_NET_NAME=

Puede encontrar más detalles e información de depuración aquí: https://www.freedesktop.org/software/systemd/man/systemd.link.html

Gerente de Redes

Cuando se usa NetworkManager, se puede cambiar el nombre de la interfaz creando una regla en el directorio /etc/udev/rules.d.

Crea /etc/udev/rules.d/70-rename-wlan.rulescon el siguiente contenido:

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

Si todo salió bien, debería ver wlan0entre sus dispositivos después de 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 

Y podrás conectarte a wifi usando nmcli d wifi connect MEU_WIFI_SSID password MEU_PASSWORD. El nmclipersistirá la conexión y se volverá a conectar después de un reinicio.

rodvlopes
fuente
Creo que ni NetworkManager ni systemd-networkd cambian el nombre de su dispositivo. Eso lo hace udev. Entonces, sí, escribir una regla udev funciona y también lo hace crear un archivo .link (en ese caso, el archivo .link es procesado por udev, no systemd-networkd).
Thaller
En el segundo ejemplo, está claro que el udev está haciendo el trabajo, no NetworkManager. Puede que tengas razón, pero en el segundo ejemplo, systemd-networkd también puede hacer el trabajo (tal vez habla con udev bajo el capó).
Rodvlopes
-1

La solución aceptada no funcionó para mí.

He resuelto el problema deshabilitando IPv6 en las propiedades de conexión. Ejecute nm-connection-editor , seleccione su conexión problemática, presione el botón con el ícono de ajustes (en mi caso), vaya a la pestaña "Configuración de IPv6", en el campo Método, seleccione la opción "Ignorar".

usuario36313
fuente