On Sat, 2019-12-28 at 13:54 +0100, Jürgen Bausa wrote:
I am running a laptop (Xiaomi Air 12) with debian Buster AMD64 and use KDE with network-Manager. Wifi is supplied by a Fritzbox 7530 wifi-router (2.4 and 5 GHz with same ssid and wpa2). Since I use the Fritzbox (before that I used a TP-Link router, that did not have this problem) I experience the following problem: When a new connection is initiated by the laptop (after reboot or resume) in some cases (about 5-10 %) the connection is made for a very short time only. The laptop is then disconnected and a window appears on the desktop, saying that the password had been wrong (which is definitely not the case: the correct password is stored in NMs database) and asking for the correct one. When I type in the correct password, the connection is made. Or, if I just close the window and clcik on the connection in NM, the connection is also made. This is what I find in the routers log (lina is my laptop): (translation from german). 20.12.19 22:57:51 WIFI-device has been disconnected (5 GHz), lina, IP 192.168.0.31, MAC XX:XX:XX:XX:XX:XX. 20.12.19 22:57:48 WIFI-device has been connected, WIFI reactivated with full power (5 GHz). These two things are always the same, when the problem happens: - the router resumes from power saving mode when the first attempt to connect is made (WIFI reactivated with full power) - 5 Ghz is used This is what I find in the laptops log: wlp1s0: CTRL-EVENT-REGDOM-CHANGE init=DRIVER type=COUNTRY alpha2=DE wlp1s0: SME: Trying to authenticate with XX:XX:XX:XX:XX:XX (SSID='meineSSID' freq=5220 MHz) wlp1s0: Trying to associate with XX:XX:XX:XX:XX:XX (SSID='meineSSID' freq=5220 MHz) wlp1s0: Associated with XX:XX:XX:XX:XX:XX wlp1s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wlp1s0: WPA: Key negotiation completed with XX:XX:XX:XX:XX:XX [PTK=CCMP GTK=CCMP] wlp1s0: CTRL-EVENT-CONNECTED - Connection to XX:XX:XX:XX:XX:XX completed [id=0 id_str=] wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-70 noise=9999 txrate=6000 Dec 20 22:57:48 lina avahi-daemon[637]: Joining mDNS multicast group on interface wlp1s0.IPv6 with address fe80::31a:e3aa:b668:28ed. Dec 20 22:57:48 lina avahi-daemon[637]: New relevant interface wlp1s0.IPv6 for mDNS. Dec 20 22:57:48 lina avahi-daemon[637]: Registering new address record for fe80::31a:e3aa:b668:28ed on wlp1s0.*. Dec 20 22:57:49 lina dhclient[17036]: DHCPREQUEST for 192.168.0.31 on wlp1s0 to 255.255.255.255 port 67 wlp1s0: CTRL-EVENT-DISCONNECTED bssid=XX:XX:XX:XX:XX:XX reason=2 wlp1s0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect wlp1s0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="meineSSID" auth_failures=1 duration=10 reason=WRONG_KEY dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/ wpa_supplicant1/Interfaces/5 wlp1s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD Dec 20 22:57:54 lina systemd[1]: NetworkManager-dispatcher.service: Succeeded. Dec 20 22:58:06 lina avahi-daemon[637]: Withdrawing address record for fe80::31a:e3aa:b668:28ed on wlp1s0. Dec 20 22:58:06 lina avahi-daemon[637]: Leaving mDNS multicast group on interface wlp1s0.IPv6 with address xxxx::xxxx:xxxx:xxxx:xxxx. Dec 20 22:58:06 lina avahi-daemon[637]: Interface wlp1s0.IPv6 no longer relevant for mDNS. wlp1s0: Reject scan trigger since one is already pending The whole thing only happens with the debian buster laptop. No problem with other clients (android, Mac, iphone, Windows10) I tried this in another house, where same router is used. There, the same problem appears. However with a different laptop (Acer), but also debian buster AMD64 with KDE and network- Manager. Anyone else using a Fritzbox Router? Having or not having this problem? I am not sure if it is related to router, NM, or kernel. I dont think its related to the wifi driver, because it happened on two laptops with different hardware. Is there any way for me to obtain more information do debug this?
Hi Juergen, I have probably the same issue with NetworkManager and one Fritzbox (another Fritzbox works fine for me). I think the problem is that association fails, and somebody (driver, wpa-supplicant or NetworkManager) wrongly assumes the reason is a wrong password. Given how often that failure to associate happens, it seems there are more serious issue here (I would guess it's a supplicant issue). You also see the message from supplicant "pre-shared key may be incorrect", which hints that the issue is not in NetworkManager. Anyway, NetworkManager thinking that the password is wrong causes quite some problems. In the best case, you get a password prompt. In the worst case, you are not at the machine and nobody can provide the password. That means, that profile will be blocked from autoconnecting. That's bad, if you want to leave the machine unattended and expect it to reconnect automatically. Somehow it helped in my case to store the password systemwide (wifi.psk-flags=0). I was thinking, maybe NetworkManager should get a flag in the profile to indicate "I know the password is correct, don't ever assume it's wrong". However, that's only a workaround, it would be better to fix the underlying issue ... best, Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part