[Trisquel-users] Re : Internet connection problem
Indeed. :-)
[Trisquel-users] Re : Internet connection problem
What Debian did for Lilypond looks like the way to go. It prevents newly installed systems and systems that were not updated during the past week to suffer from the problem. For those who updated, I suggested in https://trisquel.info/forum/volunteer-write-more-regular-blog-posts-trisquelinfo#comment-144246 a post on the main website, maybe more visible than in the forum. After the addition of the (fake) updated version of NetworkManager to the repository, the terminal-free instructions for the MATE edition of Trisquel would become: Plug an Ethernet cable; Specify the IP address of any DNS server (for instance FDN's server: 80.67.169.12) in the DNS tab of "Network", in MATE's "Control Center"; Install the updates from the "Software Updater", in "Control Center." That last step is much easier for a non-technical user (like my mother) than typing 'sudo apt install network-manager=1.2.6-0ubuntu0.16.04.3 wpasupplicant=2.4-0ubuntu6.6' and 'sudo apt-mark hold network-manager wpasupplicant' without a typo. :-)
Re: [Trisquel-users] Re : Internet connection problem
> I really meant "unhold" (no typo).I do not think it is OK to still > have the normally proposed version of NetworkManager (well, normal for > those who enabled flidas-backports) "break the Internet" of many > users. Sorry, I misunderstood you. It sounds you had already successfully "held" the old network manager version and were checking to see if a new update were available fixing the issue. > Either another update is necessary or, thinking only of rarely used > systems (that were not updated in the past week) and of new users, a > removal of version 1.10.6-2ubuntu1+8.0trisquel2 from the repository: Debian once accidentally pushed an unstable version of Lilypond (2.19.81) from their experimental repo into the main repo. They then reuploaded the stable version (2.18.2) with "2.19.81+really-" prepended to the version number, and have kept it that way since, so the current version is "2.19.81+really-2.18.2-13". This essentially tricks the package manager to into thinking that the downgrade is really an upgrade, so it will propose the old version. The same thing could be accomplished by uploading the old version of network-manager with the version "1.10.6-2ubuntu1+8.0trisquel2+really-1.2.6-0ubuntu0.16.04.3", except that I'm not sure how anyone with the current version of network-manager will be able to upgrade at all unless they check the forum and learn what to do. signature.asc Description: PGP signature
[Trisquel-users] Re : Internet connection problem
I really meant "unhold" (no typo). I do not think it is OK to still have the normally proposed version of NetworkManager (well, normal for those who enabled flidas-backports) "break the Internet" of many users. The problem looks widespread: besides those who expressed themselves in this thread, I can mention the system I installed for my parents, who could not fix it without my assistance, which could not be remote since their system was offline. Either another update is necessary or, thinking only of rarely used systems (that were not updated in the past week) and of new users, a removal of version 1.10.6-2ubuntu1+8.0trisquel2 from the repository: somebody who installs Trisquel 8 and, to complement the installation, enables flidas-backports, updates and loses her Internet connection will certainly then proceed with the installation of another distribution!
Re: [Trisquel-users] Re : Internet connection problem
> If I 'sudo apt-mark unhold network-manager', the Update Manager still > proposes me the version 1.10.6-2ubuntu1+8.0trisquel2 of > NetworkManager... If you really did use "unhold", then this is the expected behavior. Change it to "hold" in order to prevent upgrades to network-manager. If you actually used "hold" and "unhold" is just a typo in the forum post, then maybe the graphical update manager does not observe the hold. Or, perhaps it will not actually upgrade network-manager if you follow through with the upgrade. When I run "apt list --upgradable" network-manager does appear, but when I run "sudo apt upgrade" I get The following packages have been kept back: network-manager so if the graphical installer uses "apt list --upgradable" or some equivalent to list the upgradable packages, then network-manager might appear even if it will not actually be upgraded. signature.asc Description: PGP signature
[Trisquel-users] Re : Internet connection problem
If I 'sudo apt-mark unhold network-manager', the Update Manager still proposes me the version 1.10.6-2ubuntu1+8.0trisquel2 of NetworkManager...
[Trisquel-users] Re : Internet connection problem
The newer version does not solve the problems for me: using Ethernet, the DNS server is not automatically set (I can only contact IP addresses, not domain names) and, I believe, I cannot establish a wireless connection to a network (using an adpater with the AR9271 chipset). I write "I believe" for the second problem, because I am at the university with a rather unreliable wireless network. So, after the update, I had to downgrade again: I added 80.67.169.12 as a DNS server in the Network Settings (and got domain name resolution); I executed 'sudo apt install network-manager=1.2.6-0ubuntu0.16.04.3 wpasupplicant=2.4-0ubuntu6.6' in a terminal.
Re: [Trisquel-users] Re : Internet connection problem
> Nothing unexpected: I have to choose the GVT-989C_nomap network by > hand, the password is asked but, again, the connection is never > established. I see no relevant difference in dmesg's output. I > detect no relevant difference in NetworkManager's log either but maybe > you will: Neither do I, and at this point I'm ready to give up. Ark74 and I spent hours working on a helper[1] that addressed the hostname issue, and it did not cause these problems when we tested it, but this other helper was used instead without any discussion. I don't really feel like putting more of my time into this issue. I've emailed quidam and pinged him on IRC asking him to revert these changes, and in the meantime I've made a forum thread[2] warning users and explaining how to upgrade all packages except these two. [1] https://devel.trisquel.info/trisquel/package-helpers/merge_requests/265/diffs [2] https://trisquel.info/en/forum/dont-upgrade-backported-network-manager-or-wpa-supplicant signature.asc Description: PGP signature
[Trisquel-users] Re : Internet connection problem
Nothing unexpected: I have to choose the GVT-989C_nomap network by hand, the password is asked but, again, the connection is never established. I see no relevant difference in dmesg's output. I detect no relevant difference in NetworkManager's log either but maybe you will: wifi-nl80211: (wlan0): using nl80211 for WiFi device control device (wlan0): driver supports Access Point (AP) mode manager: (wlan0): new 802.11 WiFi device (/org/freedesktop/NetworkManager/Devices/3) rfkill2: found WiFi radio killswitch (at /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/ieee80211/phy1/rfkill2) (driver ath9k_htc) supplicant: wpa_supplicant running devices added (path: /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/net/wlxc04a00104ebd, iface: wlxc04a00104ebd) device added (path: /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5:1.0/net/wlxc04a00104ebd, iface: wlxc04a00104ebd): no ifupdown configuration found. device (wlxc04a00104ebd): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external') device (wlxc04a00104ebd): set-hw-addr: set MAC address to F2:7A:07:06:A8:FC (scanning) device (wlxc04a00104ebd): supplicant interface state: starting -> ready device (wlxc04a00104ebd): state change: unavailable -> disconnected (reason 'supplicant-available', sys-iface-state: 'managed') keyfile: add connection in-memory (0686565e-d20a-4b46-a385-c1b343323b3e,"GVT-989C_nomap") device (wlxc04a00104ebd): Activation: starting connection 'GVT-989C_nomap' (0686565e-d20a-4b46-a385-c1b343323b3e) settings-connection[0x1535590,0686565e-d20a-4b46-a385-c1b343323b3e]: write: successfully commited (keyfile: update /etc/NetworkManager/system-connections/GVT-989C_nomap (0686565e-d20a-4b46-a385-c1b343323b3e,"GVT-989C_nomap") and persist connection) audit: op="connection-add-activate" uuid="0686565e-d20a-4b46-a385-c1b343323b3e" name="GVT-989C_nomap" pid=1700 uid=1000 result="success" device (wlxc04a00104ebd): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed') manager: NetworkManager state is now CONNECTING device (wlxc04a00104ebd): set-hw-addr: set-cloned MAC address to F6:CD:0B:6B:DD:DC (stable) device (wlxc04a00104ebd): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') device (wlxc04a00104ebd): Activation: (wifi) access point 'GVT-989C_nomap' has security, but secrets are required. device (wlxc04a00104ebd): state change: config -> need-auth (reason 'none', sys-iface-state: 'managed') settings-connection[0x1535590,0686565e-d20a-4b46-a385-c1b343323b3e]: write: successfully commited (keyfile: update /etc/NetworkManager/system-connections/GVT-989C_nomap (0686565e-d20a-4b46-a385-c1b343323b3e,"GVT-989C_nomap")) device (wlxc04a00104ebd): state change: need-auth -> prepare (reason 'none', sys-iface-state: 'managed') device (wlxc04a00104ebd): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') device (wlxc04a00104ebd): Activation: (wifi) connection 'GVT-989C_nomap' has security, and secrets exist. No new secrets needed. Config: added 'ssid' value 'GVT-989C_nomap' Config: added 'scan_ssid' value '1' Config: added 'bgscan' value 'simple:30:-80:86400' Config: added 'key_mgmt' value 'WPA-PSK' Config: added 'auth_alg' value 'OPEN' Config: added 'psk' value '' device (wlxc04a00104ebd): supplicant interface state: ready -> scanning device (wlxc04a00104ebd): supplicant interface state: scanning -> authenticating device (wlxc04a00104ebd): supplicant interface state: authenticating -> disconnected device (wlxc04a00104ebd): supplicant interface state: disconnected -> scanning device (wlxc04a00104ebd): supplicant interface state: scanning -> authenticating device (wlxc04a00104ebd): supplicant interface state: authenticating -> disconnected device (wlxc04a00104ebd): supplicant interface state: disconnected -> scanning device (wlxc04a00104ebd): supplicant interface state: scanning -> authenticating device (wlxc04a00104ebd): supplicant interface state: authenticating -> disconnected device (wlxc04a00104ebd): supplicant interface state: disconnected -> scanning device (wlxc04a00104ebd): supplicant interface state: scanning -> authenticating device (wlxc04a00104ebd): Activation: (wifi) association took too long, failing activation device (wlxc04a00104ebd): state change: config -> failed (reason 'ssid-not-found', sys-iface-state: 'managed') manager: NetworkManager state is now DISCONNECTED device (wlxc04a00104ebd): Activation: failed for connection 'GVT-989C_nomap' device (wlxc04a00104ebd): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed') device (wlxc04a00104ebd): set-hw-addr: set MAC address to 06:0D:9B:C2:CF:51 (scanning) sup-iface[0x14afba0,wlxc04a00104ebd]: connection disconnected (reason -3) device (wlxc04a00104ebd): supplicant interface state: authenticating -> disconnected
Re: [Trisquel-users] Re : Internet connection problem
> Given the problem with DNS, I would bet on a problem > relating to "disabling sending hostname on DHCP > requests". In that case, it is the changes made to nm-setting-ip4-config.c and nms-ifcfg-rh-writer.c that are causing the issue, which can only be reverted by recompiling. What happens if you make NetworkManager forget the connection to your router and start fresh? signature.asc Description: PGP signature
[Trisquel-users] Re : Internet connection problem
Since the log has several errors that mention your MAC address, I think the problem might have to do with the new randomization of mac addresses. Given the problem with DNS, I would bet on a problem relating to "disabling sending hostname on DHCP requests". Indeed, a DHCPOFFER message includes DNS servers: https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Offer
Re: [Trisquel-users] Re : Internet connection problem
On 10/20, lc...@dcc.ufmg.br wrote:
> Deleting both sections of
> /etc/NetworkManager/NetworkManager.conf and executing
> 'systemctl restart NetworkManager' does not solve any
> of the two problems (the DNS not being automatically
> configured with Ethernet, the Wifi adapter never
> connecting to the network). Should I still try to
> remove only one of the two sections?
Prior to the update, the /etc/NetworkManager/NetworkManager.conf
looked like this
```
[main]
plugins=ifupdown,keyfile,ofono
dns=dnsmasq
[ifupdown]
managed=false
```
Now it looks like this:
```
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=false
[device]
wifi.scan-rand-mac-address=yes
[connection]
wifi.cloned-mac-address=stable
ethernet.cloned-mac-address=stable
connection.stable-id=${CONNECTION}/$(BOOT)
```
So the problem should lie in the new [device] section, the new
[connection] section, and/or the missing "dns=dnsmasq" line. (I ofono in
the "plugins=" line makes a difference.)
If completely reverting to the contents of the old NetworkManager.conf
doesn't fix the problem, then perhaps the issue has something to do with
the newer versions of network-manager and/or wpasupplicant, which with
this latest change are now backported from Ubuntu 18.04.
> Also, I only
> executed 'systemctl restart NetworkManager' after
> updating to the flidas-backports version of
> NetworkManager. Is it really necessary to reboot (as
> the Update Manager says)?
I'm not sure. It seems that the problem may have something to do with
how your computer communicates with your router, and I'm not sure
whether something relevant to this happens on startup that does not
happen when restarting NetworkManager.
signature.asc
Description: PGP signature
[Trisquel-users] Re : Internet connection problem
I tried deleting only one of the two sections. I tried rebooting after deleting both sections too. Nothing led to any improvement w.r.t. the faced problems.
[Trisquel-users] Re : Internet connection problem
Deleting both sections of /etc/NetworkManager/NetworkManager.conf and executing 'systemctl restart NetworkManager' does not solve any of the two problems (the DNS not being automatically configured with Ethernet, the Wifi adapter never connecting to the network). Should I still try to remove only one of the two sections? Also, I only executed 'systemctl restart NetworkManager' after updating to the flidas-backports version of NetworkManager. Is it really necessary to reboot (as the Update Manager says)?
[Trisquel-users] Re : Internet connection problem
Hopefully reinstalling the previous version of network-manager and wpasupplicant will fix your system. It did: https://trisquel.info/forum/internet-connection-problem#comment-144131 Thank you. I think that GNOME's graphical frontend to network-manager might allow you to change it persistently. I use GNOME's graphical frontend... This[1] should also work. I will try that later. Does editing /etc/NetworkManager/NetworkManager.conf and commenting out (...) fix the problem? I will break again my network connection and try right now. :-)
Re: [Trisquel-users] Re : Internet connection problem
> Since I have the same Wifi chipset (AR9271), I installed the latest
> updates to see. Here is the related entry in
> /var/log/apt/history.log:
Thanks for saving me the trouble of breaking my own Internet in order to
get this information. Hopefully reinstalling the previous version of
network-manager and wpasupplicant will fix your system.
> I have actually always wanted to use the DNS Of French Data Network (a
> French associative ISP, fighting against censorship) and adding
> 80.67.169.12 in the DNS tab of the Network Settings works. So, here
> is a way to get a working wired connection... but the change is not
> persistent (it has always been like that on my system, for some
> reason): the DNS must be
network-manager automatically generates /etc/resolv.conf on startup,
which will overwrite any changes you make manually, so you can't
persistently change DNS behind network-manager's back. I think that
GNOME's graphical frontend to network-manager might allow you to change
it persistently. This[1] should also work.
> The Wifi problem seems unrelated and more serious. Right after
> plugging in my adapter, here are dmesg's messages over 114 seconds (I
> removed the timestamps to ease the reading):
Since the log has several errors that mention your MAC address, I think
the problem might have to do with the new randomization of mac
addresses.[2] Does editing /etc/NetworkManager/NetworkManager.conf and
commenting out
```
wifi.scan-rand-mac-address=yes
```
and/or
```
[device]
wifi.scan-rand-mac-address=yes
[connection]
wifi.cloned-mac-address=stable
ethernet.cloned-mac-address=stable
connection.stable-id=\${CONNECTION}/\$(BOOT)
```
fix the problem?
[1]
https://wiseindy.com/blog/linux/how-to-set-dns-in-centos-rhel-7-prevent-network-manager-from-overwriting-etc-resolv-conf/
[2]
https://devel.trisquel.info/trisquel/package-helpers/commit/b6270b123898a9896ae4be0560a48d76d521dc4b
signature.asc
Description: PGP signature
[Trisquel-users] Re : Internet connection problem
That works here. However, the package had to be downloaded (sorry about the French, I should have set LC_ALL=C): $ sudo apt install network-manager=1.2.6-0ubuntu0.16.04.3 Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires : libjansson4 libpsl0 libteamdctl0 publicsuffix Veuillez utiliser « sudo apt autoremove » pour les supprimer. Les paquets suivants seront mis à une VERSION INFÉRIEURE : network-manager 0 mis à jour, 0 nouvellement installés, 1 remis à une version inférieure, 0 à enlever et 0 non mis à jour. Il est nécessaire de prendre 1 957 ko dans les archives. Après cette opération, 1 187 ko d'espace disque seront libérés. Souhaitez-vous continuer ? [O/n] Réception de :1 https://archive.trisquel.info/trisquel flidas-security/main amd64 network-manager amd64 1.2.6-0ubuntu0.16.04.3 [1 957 kB] 1 957 ko réceptionnés en 4s (431 ko/s) dpkg : avertissement : dégradation (« downgrade ») de network-manager depuis 1.10.6-2ubuntu1+8.0trisquel1 vers 1.2.6-0ubuntu0.16.04.3 (Lecture de la base de données... 328013 fichiers et répertoires déjà installés.) Préparation du dépaquetage de .../network-manager_1.2.6-0ubuntu0.16.04.3_amd64.deb ... Dépaquetage de network-manager (1.2.6-0ubuntu0.16.04.3) sur (1.10.6-2ubuntu1+8.0trisquel1) ... Traitement des actions différées (« triggers ») pour systemd (229-4ubuntu21.22) ... Traitement des actions différées (« triggers ») pour ureadahead (0.100.0-19.1) ... ureadahead will be reprofiled on next reboot Traitement des actions différées (« triggers ») pour dbus (1.10.6-1ubuntu3.4) ... Traitement des actions différées (« triggers ») pour man-db (2.7.5-1) ... Paramétrage de network-manager (1.2.6-0ubuntu0.16.04.3) ... Installation de la nouvelle version du fichier de configuration /etc/NetworkManager/NetworkManager.conf ... Installation de la nouvelle version du fichier de configuration /etc/dbus-1/system.d/org.freedesktop.NetworkManager.conf ... Installation de la nouvelle version du fichier de configuration /etc/init.d/network-manager ... Traitement des actions différées (« triggers ») pour dbus (1.10.6-1ubuntu3.4) ... Traitement des actions différées (« triggers ») pour systemd (229-4ubuntu21.22) ... Traitement des actions différées (« triggers ») pour ureadahead (0.100.0-19.1) ... Also, I had to restart NetworkManager: $ systemctl restart NetworkManager An now, the Update Manager is proposing me the same update again... Hopefully, the logs I reported are useful o solve the problem in another update. Whoever works on it: I can help with testing.
[Trisquel-users] Re : Internet connection problem
Since I have the same Wifi chipset (AR9271), I installed the latest updates to see. Here is the related entry in /var/log/apt/history.log: Start-Date: 2019-10-20 11:24:20 Commandline: aptdaemon role='role-commit-packages' sender=':1.183' Install: libteamdctl0:amd64 (1.23-1, automatic), publicsuffix:amd64 (20160130-1, automatic), libpsl0:amd64 (0.11.0-2, automatic), libjansson4:amd64 (2.7-3ubuntu0.1, automatic) Upgrade: libnm-glib4:amd64 (1.2.6-0ubuntu0.16.04.3, 1.10.6-2ubuntu1+8.0trisquel1), gir1.2-networkmanager-1.0:amd64 (1.2.6-0ubuntu0.16.04.3, 1.10.6-2ubuntu1+8.0trisquel1), libnm-glib-vpn1:amd64 (1.2.6-0ubuntu0.16.04.3, 1.10.6-2ubuntu1+8.0trisquel1), libnm0:amd64 (1.2.6-0ubuntu0.16.04.3, 1.10.6-2ubuntu1+8.0trisquel1), network-manager:amd64 (1.2.6-0ubuntu0.16.04.3, 1.10.6-2ubuntu1+8.0trisquel1), libnm-util2:amd64 (1.2.6-0ubuntu0.16.04.3, 1.10.6-2ubuntu1+8.0trisquel1), wpasupplicant:amd64 (2.4-0ubuntu6.6, 2:2.6-15ubuntu2+8.0trisquel1) End-Date: 2019-10-20 11:24:25 NetworkManager is updated (nothing specific to Atheros chipsets) and things go wrong indeed. In the case of my system, wronger than what Piriponzolo reports: after restarting NetworkManager (or rebooting the whole system), I apparently can neither get a Wifi connection nor a wired connection. The version of the kernel does not seem to make a difference. I tried versions 4.4.0-161 and 4.15.0-55, Trisquel's default and HWE versions. I wrote "apparently" because the wired connection works with IP addresses. As far as I understand (I am not knowledgeable when it comes to networks), the DNS servers of my ISP are not automatically set anymore (since the update). I have actually always wanted to use the DNS Of French Data Network (a French associative ISP, fighting against censorship) and adding 80.67.169.12 in the DNS tab of the Network Settings works. So, here is a way to get a working wired connection... but the change is not persistent (it has always been like that on my system, for some reason): the DNS must be The Wifi problem seems unrelated and more serious. Right after plugging in my adapter, here are dmesg's messages over 114 seconds (I removed the timestamps to ease the reading): usb 1-5: new high-speed USB device number 8 using xhci_hcd usb 1-5: New USB device found, idVendor=0cf3, idProduct=9271 usb 1-5: New USB device strings: Mfr=16, Product=32, SerialNumber=48 usb 1-5: Product: USB2.0 WLAN usb 1-5: Manufacturer: ATHEROS usb 1-5: SerialNumber: 12345 usb 1-5: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested usb 1-5: Direct firmware load failed with error -64642976 usb 1-5: ath9k_htc: Firmware htc_9271.fw requested usb 1-5: ath9k_htc: Transferred FW: htc_9271.fw, size: 50980 ath9k_htc 1-5:1.0: ath9k_htc: HTC initialized with 33 credits ath9k_htc 1-5:1.0: ath9k_htc: FW Version: 1.3 ath9k_htc 1-5:1.0: FW RMW support: Off ath: EEPROM regdomain: 0x809c ath: EEPROM indicates we should expect a country code ath: doing EEPROM country->regdmn map search ath: country maps to regdmn code: 0x52 ath: Country alpha2 being used: CN ath: Regpair used: 0x52 ieee80211 phy1: Atheros AR9271 Rev:1 ath9k_htc 1-5:1.0 wlxc04a00104ebd: renamed from wlan0 IPv6: ADDRCONF(NETDEV_UP): wlxc04a00104ebd: link is not ready IPv6: ADDRCONF(NETDEV_UP): wlxc04a00104ebd: link is not ready IPv6: ADDRCONF(NETDEV_UP): wlxc04a00104ebd: link is not ready IPv6: ADDRCONF(NETDEV_UP): wlxc04a00104ebd: link is not ready IPv6: ADDRCONF(NETDEV_UP): wlxc04a00104ebd: link is not ready wlxc04a00104ebd: authenticate with 2c:e4:12:c7:98:a0 wlxc04a00104ebd: send auth to 2c:e4:12:c7:98:a0 (try 1/3) wlxc04a00104ebd: send auth to 2c:e4:12:c7:98:a0 (try 2/3) wlxc04a00104ebd: authenticated wlxc04a00104ebd: aborting authentication with 2c:e4:12:c7:98:a0 by local choice (Reason: 3=DEAUTH_LEAVING) wlxc04a00104ebd: authenticate with 2c:e4:12:c7:98:a0 wlxc04a00104ebd: send auth to 2c:e4:12:c7:98:a0 (try 1/3) wlxc04a00104ebd: authenticated wlxc04a00104ebd: aborting authentication with 2c:e4:12:c7:98:a0 by local choice (Reason: 3=DEAUTH_LEAVING) wlxc04a00104ebd: authenticate with 2c:e4:12:c7:98:a0 wlxc04a00104ebd: send auth to 2c:e4:12:c7:98:a0 (try 1/3) wlxc04a00104ebd: authenticated wlxc04a00104ebd: authenticate with 2c:e4:12:c7:98:a0 wlxc04a00104ebd: send auth to 2c:e4:12:c7:98:a0 (try 1/3) wlxc04a00104ebd: authenticated wlxc04a00104ebd: aborting authentication with 2c:e4:12:c7:98:a0 by local choice (Reason: 3=DEAUTH_LEAVING) IPv6: ADDRCONF(NETDEV_UP): wlxc04a00104ebd: link is not ready IPv6: ADDRCONF(NETDEV_UP): wlxc04a00104ebd: link is not ready IPv6: ADDRCONF(NETDEV_UP): wlxc04a00104ebd: link is not ready wlxc04a00104ebd: authenticate with 2c:e4:12:c7:98:a0 wlxc04a00104ebd: send auth to 2c:e4:12:c7:98:a0 (try 1/3) wlxc04a00104ebd: authenticated wlxc04a00104ebd: aborting authentication with 2c:e4:12:c7:98:a0 by local choice (Reason: 3=DEAUTH_LEAVING) wlxc04a00104ebd: authenticate with 2c:e4:12:c7:98:a0
