Your message dated Sun, 17 Apr 2022 17:26:19 +0200
with message-id <[email protected]>
and subject line Re: [Pkg-utopia-maintainers] Bug#1000965: Fails to bring up
the Wifi after suspend - "authentication timed out"
has caused the Debian Bug report #1000965,
regarding Fails to bring up the Wifi after suspend - "authentication timed out"
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1000965: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000965
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: network-manager
Version: 1.30.0-2
Severity: important
Dear Maintainer,
I recently upgraded my Thinkpad T520 (which has Intel(R) Centrino(R) Advanced-N
6205
wifi hardware) from Buster to Bullseye.
I use suspend/resume in a daily basis instead of completely shutdown/booting
for years now (suspend to ram), and this worked without problems during Buster
lifecycle.
Now with Bullseye, this is no longer a useful way, because often the wifi does
not
work after suspending.
I have to reboot the machine to bring wifi back to work.
(or at least this is the only way I found, to make wifi work again. maybe
something
like removing/reloading kernel modules or similar would also work, but I did not
succeed with such attempts.)
This happenes with a 5.10.0 kernel from bullseye, and it also happens, if I
boot with
the older 4.19 kernel from Buster, which I still have installed from the buster
times.
I did some research on firmware for the wifi hardware, but the used
iwlwifi-6000g2a-6.ucode firmware did not change from buster to bullseye
(version is
18.168.6.1 for both), and downgrading the whole iwlwifi-firmware package to the
Buster
version did not help, too.
Looking in the system log, I see lines like this:
Dec 1 18:20:07 t520 wpa_supplicant[510]: wlp3s0: SME: Trying to authenticate
with c8:0e:14:5a:28:c7 (SSID='Zion2' freq=5300 MHz)
Dec 1 18:20:07 t520 kernel: [ 342.607297] wlp3s0: authenticate with
c8:0e:14:5a:28:c7
Dec 1 18:20:07 t520 kernel: [ 342.611357] wlp3s0: send auth to
c8:0e:14:5a:28:c7 (try 1/3)
Dec 1 18:20:07 t520 NetworkManager[477]: <info> [1638379207.3696] device
(wlp3s0): supplicant interface state: scanning -> authenticating
Dec 1 18:20:08 t520 kernel: [ 344.097973] wlp3s0: send auth to
c8:0e:14:5a:28:c7 (try 2/3)
Dec 1 18:20:09 t520 kernel: [ 345.121870] wlp3s0: send auth to
c8:0e:14:5a:28:c7 (try 3/3)
Dec 1 18:20:10 t520 kernel: [ 346.113979] wlp3s0: authentication with
c8:0e:14:5a:28:c7 timed out
so authentication fails for some reason.
I will sent the full system log to the bug, when I get the bug number.
Is there a way to get more detailed log information?
Would that be of interest for you?
Any other suggestions?
Regards,
Holger
-- System Information:
Debian Release: 11.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-9-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages network-manager depends on:
ii adduser 3.118
ii dbus 1.12.20-2
ii libaudit1 1:3.0-2
ii libbluetooth3 5.55-3.1
ii libc6 2.31-13+deb11u2
ii libcurl3-gnutls 7.74.0-1.3+b1
ii libglib2.0-0 2.66.8-1
ii libgnutls30 3.7.1-5
ii libjansson4 2.13.1-1.1
ii libmm-glib0 1.14.12-0.2
ii libndp0 1.6-1+b1
ii libnewt0.52 0.52.21-4+b3
ii libnm0 1.30.0-2
ii libpsl5 0.21.0-1.2
ii libreadline8 8.1-1
ii libselinux1 3.1-3
ii libsystemd0 247.3-6
ii libteamdctl0 1.31-1
ii libudev1 247.3-6
ii libuuid1 2.36.1-8
ii policykit-1 0.105-31
ii udev 247.3-6
ii wpasupplicant 2:2.9.0-21
Versions of packages network-manager recommends:
ii dnsmasq-base [dnsmasq-base] 2.85-1
ii iptables 1.8.7-1
ii libpam-systemd 247.3-6
ii modemmanager 1.14.12-0.2
ii ppp 2.4.9-1+1
ii wireless-regdb 2020.04.29-2
Versions of packages network-manager suggests:
ii isc-dhcp-client 4.4.1-2.3
pn libteam-utils <none>
--
Holger Wansing <[email protected]>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
--- End Message ---
--- Begin Message ---
Hi,
Holger Wansing <[email protected]> wrote (Sat, 25 Dec 2021 12:55:54 +0100):
> Some research showed, that I had a WiFi connection from one of my neighbors in
> my "Known networks" list, without WiFi password, but with the "Connect
> automatically" check-box set.
> Because of this, I sometimes see, that the laptop automatically tries to
> connect to that WLAN, if that is available. Without success of course,
> since password is missing in the settings (the "Give password" dialog
> shows up then).
> Maybe that leads to some sort of authentication failure, which is later
> taken over to my own WLAN for whatever reason, to cause the authentication
> on my own WLAN to fail (even if password is correct in the settings)?
>
> I have now removed my neighbours WLAN from my "Known networks" list.
> Let's see, what happens now...
I had no more issues for more than 3 months now, so I guess this 'bug' is
fixed with above measures.
Thus closing this bug
Thanks for your assistance!
Holger
--
Holger Wansing <[email protected]>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
--- End Message ---
