"Abandon de l'authentification par choix local (raison: 3 = DEAUTH_LEAVING)" lors de la tentative de connexion au wifi

13

J'ai installé Debian 9 Stretch (bureau GNOME) 64 bits sur mon PC. Mon adaptateur sans fil USB (TP-LINK TL-WN722N) a été détecté automatiquement après l'installation du micrologiciel atheros:

apt-get install firmware-atheros

Mais je ne peux pas me connecter à une infrastructure sans fil, qu'elle soit protégée par mot de passe ou non protégée.

J'ai branché mon USB. Il a été détecté, envoyé une authentification, s'est authentifié, mais a immédiatement abandonné l'authentification. La désactivation d'IPV6 n'a pas résolu mon problème. Voici mon dmesgrapport:

[   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

Je n'ai aucune idée pourquoi cela s'est produit, ni pourquoi il a été abandonné plusieurs fois en un seul essai.

Modifier: rapport 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.
wifi dhcp wlan GPraz
la source
À quelle distance êtes-vous de cet AP
Rui F Ribeiro

Réponses:

15

D'une manière ou d'une autre, mon micrologiciel a rencontré des problèmes avec le nom d'interface long. J'ai donc exécuté cette commande pour l'empêcher:

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

et ça a marché.

GPraz
la source
Juste pour ajouter que cet article m'a aidé à comprendre pourquoi le correctif fonctionne réellement; c'est parce que nous surchargeons par défaut /lib/systemd/network/99-default.linkfichier qui contient un NamePolicyqui ne plaît pas le firmware. BTW, j'ai toujours eu des problèmes pour rejoindre certains réseaux. Il est arrivé que le domaine réglementaire par défaut ne corresponde pas à mon emplacement, j'ai donc dû émettre un iw reg set <MyCountryCode>et modifier le /etc/default/crdafichier en fonction
user3249994
J'ai observé le même problème avec un rt2x00 et cette solution de contournement a fonctionné immédiatement. J'apprécierais si quelqu'un pouvait expliquer pourquoi cela fonctionne et quelle est la bonne solution.
Helmut Grohne
3
Bien que je convienne qu'il s'agit d'une solution de contournement fonctionnelle, ce serait fantastique si quelqu'un pouvait expliquer un peu mieux le "pourquoi" ... Je suppose que cela a à voir avec quelque chose dans NetworkManager mais c'est purement un coup de volée.
CJ Steele
1
Cela aide, je lutte contre ce problème depuis plus d'un mois, j'ai mis à niveau mon debian il y a quelques mois et j'ai commencé à voir ce problème, mais avec seulement des routeurs spécifiques. J'ai une puce wifi intel (module iwlwifi).
Krzysztof Krasoń
1
Cela fonctionne pour mon adaptateur sans fil Ralink MTK7601u. $ sudo nmcli dev wifi connect MySSIDdéclenche un message d'erreur comme Error: Connection activation failed: (53) The Wi-Fi network could not be found.Le rapport dmesg est presque le même.
Arnie97
7

Comme d'autres l'ont dit, le problème est dû au nom non standard obtenu par l'appareil (c'est-à-dire pas wlan *). Lier / dev / null ne fonctionnait pas pour moi, j'ai donc dû créer une règle udev pour renommer l'interface:

Dans 

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

ajouter:

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

Adaptez- ATTRS{product}vous à votre appareil spécifique. Vérifiez comment le trouver ici

Maciek
la source
J'ai ce même problème, et je viens ATTRS{product}de découvrir cette solution ... Est-ce seulement cela qui doit être remplacé? Doit DRIVERSégalement contenir quelque chose ou est-il censé être réglé sur =?Merci!
J. Taylor
1
Je l'ai fait il y a plus d'un an et je ne me souviens vraiment pas des détails. Je pense qu'ATTRS {produit} devrait être suffisant pour correspondre à votre appareil. En outre, ce devrait être des PILOTES == "? *" - la pile a mangé l'étoile.
Maciek
les liens sont rompus!
nabulator
C'est la solution pour ceux qui utilisent NetworkManager. Cette règle peut être plus flexible afin que vous n'ayez pas à vous soucier de ATTRS{product}. Le mien se réveille avec cette configuration:SUBSYSTEM=="net", ACTION=="add", KERNEL=="wlan*", NAME="wlan0"
rodvlopes
1

J'ai le même problème avec deux clés USB WiFi différentes. Le correctif a également fonctionné dans mon cas, merci.
Je pense que le problème est lié à NetworkManager et au firmware: quand j'ai utilisé le même ordinateur et les mêmes clés USB, la même distribution Linux (Debian 9.3), mais j'ai utilisé wicd au lieu de NetworkManager, puis les noms de périphériques longs et non standard étaient fonctionnant, et cette correction n'était pas nécessaire.

Laszlo
la source
J'ai installé wicd et il s'est bien connecté après cela, merci!
Hayden Thring
1

La réponse acceptée fonctionne aussi pour moi. Mais je ne suis pas sûr que l'utilisation d'un lien vers / dev / null soit la meilleure solution, car dans 3 ou 4 mois, je serai très confus de trouver un tel lien à cet endroit.

Dans Raspbian -Installation sur mon Raspberry Pi, j'ai trouvé un fichier /etc/systemd/network/99-default.link standard avec le contenu suivant:

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

J'utilise ce fichier normal au lieu du lien symbolique pour résoudre le problème. Je pense que cette solution a l'avantage qu'il existe une sorte de documentation sur le système (peut-être devrais-je ajouter un lien vers cette page…).

Cela donnera un aperçu de ce qui se passe pour moi-futur. >; ->

thosch66
la source
0

Comme d'autres l'ont dit, le problème est dû au nom non standard obtenu par l'appareil (c'est-à-dire pas wlan *). Vous trouverez ci-dessous les moyens appropriés de définir le nom de l'interface réseau lorsque vous utilisez systemd.networkd ou NetworkManager .

systemd.networkd

Bien que la liaison à /dev/nullpuisse résoudre le problème, la bonne façon consiste à créer un .link fileparamètre pour le nom du périphérique.

Créez /etc/systemd/network/50-wlan.linkavec le contenu suivant:

[Match]
Type=wlan

[Link]
Name=wlan0

Redémarrez ou redémarrez le réseau puis vérifiez le résultat: udevadm info /sys/class/net/wlan0 | grep ID_NET_NAME=

Plus de détails et d'informations de débogage peuvent être trouvés ici: https://www.freedesktop.org/software/systemd/man/systemd.link.html

Gestionnaire de réseau

Lorsque vous utilisez NetworkManager, le changement de nom de l'interface peut être obtenu en créant une règle dans le répertoire /etc/udev/rules.d.

Créez /etc/udev/rules.d/70-rename-wlan.rulesavec le contenu suivant:

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

Si tout s'est bien passé, vous devriez voir wlan0parmi vos appareils après 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

Et vous pourrez vous connecter au wifi en utilisant nmcli d wifi connect MEU_WIFI_SSID password MEU_PASSWORD. Le nmcliconservera la connexion et se reconnectera après un redémarrage.

rodvlopes
la source
Je pense que ni NetworkManager ni systemd-networkd ne renomme votre appareil. Cela est fait par udev. Donc, oui, l'écriture d'une règle udev fonctionne, tout comme la création d'un fichier .link (dans ce cas, le fichier .link est traité par udev et non par systemd-networkd).
thaller
Dans le deuxième exemple, il est clair que l'udev fait le travail, pas NetworkManager. Vous avez peut-être raison, mais dans le deuxième exemple, systemd-networkd peut également faire le travail (peut-être qu'il parle à udev sous le capot).
rodvlopes
-1

La solution acceptée n'a pas fonctionné pour moi.

J'ai résolu le problème en désactivant IPv6 dans les propriétés de connexion. Exécutez nm-connection-editor , sélectionnez votre connexion en difficulté, appuyez sur le bouton avec l'icône d'engrenage (dans mon cas), accédez à l'onglet "Paramètres IPv6", dans le champ Méthode, sélectionnez l'option "Ignorer".

user36313
la source