Bug#969319: wifi cannot connect after combined suspend & gateway reboot
Hi, NM's master branch has changes related to IWD hidden SSID support and there's a possibility that it's working reliably. Unfortunately the changes didn't make it into the upcoming 1.28.0 so they'll probably only be in 1.30.0 which may be a long time off. Best regards
Bug#969319: wifi cannot connect after combined suspend & gateway reboot
Hi all, On Tue, Sep 08, 2020 at 11:35:27PM +0200, Michael Biebl wrote: [...] > I'm bringing Andreas, the maintainer iwd into the loop here. [...] (Seems you forgot to CC me but I stumbled upon this, so giving my 5c) FYI I lost interest and orphaned iwd. I'm can't tell if this is an iwd or NM bug. My best recommendation is to try without NM, connecting via iwctl and see if the problem can be reproduced standalone to help finding that out. Please also contact iwd upstream directly, either via their mailing list or irc channel. Make sure to include iwmon traces and debug output for them to be able to properly analyze what's going on. In my own experience there are many issues lingering in the NM iwd backend before it can be expected to be production quality. A very good way of triggering NM iwd backend problems is by using a hidden SSID for unknown reason. Please note that NM actively refused to connect to a hidden SSID using the iwd backend until recently (and I only fixed up the very basic things so that it is not actively refused, there should be comments on the upstream issue/merge-request about several remaining problems that needs to be adressed still if you're interested). Please note: - iwd upstream actively discurages usage of hidden SSIDs simply because there's no upside and many downsides to using it. - NM upstream actively discurages using the iwd backend (likely because they are tired of noone contributing to fixing it up). For a data point you can compare against, I'm using NM with iwd backend myself against a hidden SSID quite often. I only quickly glanced over your description, but I don't feel like I can relate to your problem description. I can however say that I do have to apply different hacks to get things going more often then I'd want to. Usually doing (a) below solves hickups when NM doesn't get along anymore with iwd, but rarely I also need to do (b) when NM decides there are no usable interfaces available. a/ systemctl stop iwd ; systemctl restart NetworkManager ; poke the GNOME ui to "select [wifi] network" so that NM dbus activates iwd again. b/ systemctl stop iwd; systemctl stop NetworkManager; rmmod ; modprobe ; systemctl start NetworkManager ; ... Regards, Andreas Henriksson
Bug#969319: [Pkg-utopia-maintainers] Bug#969319: Bug#969319: wifi cannot connect after combined suspend & gateway reboot
On Tue, 2020-09-08 at 23:35 +0200, Michael Biebl wrote: > In any case, it might be a good idea to involve NM upstream and file > an > issue at > https://gitlab.freedesktop.org/NetworkManager/NetworkManager done: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/531 also: https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/550
Bug#969319: [Pkg-utopia-maintainers] Bug#969319: Bug#969319: wifi cannot connect after combined suspend & gateway reboot
Hi Lyndon, thanks for testing the iwd backend in NM. You might be interested in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919619 I'm bringing Andreas, the maintainer iwd into the loop here. Personally, I'm not using the iwd backend, so I'm not really qualified to tell whether the problems you are seeing are in iwd itself of in NM's implementation of the iwd backend. Maybe Andreas has some thoughts on this. In any case, it might be a good idea to involve NM upstream and file an issue at https://gitlab.freedesktop.org/NetworkManager/NetworkManager Regards, Michael Am 08.09.20 um 01:26 schrieb Lyndon Brown: > this is driving me a little crazy today. > > some hours ago i was in the middle of getting some stuff transferred > over an rsync connection, when suddenly the transfers stopped > progressing. the connection had gone bad. > > so, since previously a solution seemed to be closing some programs, i > started closing things down and trying to reconnect (having turned the > wifi off temporarily via the gnome menu). > > this time, no luck, i'd closed all my open programs and it still would > not connect. of course it could be a background task, but whatever the > case, i needed to reboot. > > i rebooted, and unlike before, it just would not connect. it has taken > me ***2 whole damn hours*** of fiddling to get connected again. > > i rebooted the laptop multiple times; i rebooted the gateway multiple > times; it just would not work. i tried moving myself a few feet away > from the router to ensure a strong signal. i told NM to forget the > connection and re-added it, multiple times. i tried using iwctl to > connect, but it just immediately reported failure on every attempt. i > tried forcing a change of MAC with macchanger, no difference. > > my android smartphone connected fine when i fetched it and turned on > the wifi... i turned off the gateway to scan visible networks with the > smartphone to check that there wasn't a neighbour with the same router- > model SSID, nope. > > so i pushed the reset button on the gateway, told NM to forget the > connection, and interestingly had absolutely no trouble at all > connecting this time. > > i restored a backup of the gateway's config and it rebooted. i then > again had NM forget the connection and tried to re-add it, and it just > kept refusing, giving me an 'activation of network connection failed' > popup at the top of my screen. note, i'd been copying and pasting the > password, so i know that's not the issue, i even compared the password > in the NM connection config and that stored in the gateway (via a wired > connection from an old machine). > > i switched the gateway wifi channel, no difference. i set the SSID to > un-hidden. finally, shortly after doing this, it suddenly connected > fine. > > i switched it back to hidden, then i went and sat down with the laptop > to type this up, and after a minute or so, i notice the connection > suddenly disappear, and again it's refusing to connect. > > interestingly it was yesterday that iwd was updated to v1.9; i'd left > the laptop sleeping overnight, and just rebooting earlier today (if i > recall correctly), so perhaps the 1.9 update has either introduced yet > another problem on top, or otherwise made things much worse. > > since it's gone down again after switched back to hidden, i'll spend a > little more time experimenting... > > so, rebooted, no difference. moved next to gateway, no difference. > > logged back into gateway via wired connection of older machine, changed > wifi to non-hidden, saved, turned around and boom, it's suddenly got a > wifi connection. > > turned back to the old machine, changed to hidden again, turned back to > laptop, saw the wifi icon change to the '...' reconnect one > temporarily, but if i recall now correctly it remained up, i then > turned off and back on the wifi (on the laptop) and fails to connect. > switched back to unhidden, and connects perfectly. so yeah, > functionality for connecting to hidden networks is completely broken. > > so i switched things back to wpa_supplicant and rebooted. straight > away, no issues at all connecting to the hidden SSID (after forgetting > and re-adding again of course). i'm connected now and getting work done > again. > > well, it's almost working perfectly back on wpasupplicant, i was back > getting data transferred via rsync, and then eventually something went > wrong preventing further transfer, but turning the wifi off and back on > again fixed it. i recall that always being a bad as things had gotten > previously with wpasupplicant. > > ___ > Pkg-utopia-maintainers mailing list > pkg-utopia-maintain...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers > signature.asc Description: OpenPGP digital signature
Bug#969319: [Pkg-utopia-maintainers] Bug#969319: wifi cannot connect after combined suspend & gateway reboot
reassigning to iwd for now, since my latest experiences are that having updated to iwd v1.9 connecting to my hidden SSID home network is now completely broken. which may very possibly relate to the original issues i was experiencing under v1.8.
Bug#969319: [Pkg-utopia-maintainers] Bug#969319: wifi cannot connect after combined suspend & gateway reboot
this is driving me a little crazy today. some hours ago i was in the middle of getting some stuff transferred over an rsync connection, when suddenly the transfers stopped progressing. the connection had gone bad. so, since previously a solution seemed to be closing some programs, i started closing things down and trying to reconnect (having turned the wifi off temporarily via the gnome menu). this time, no luck, i'd closed all my open programs and it still would not connect. of course it could be a background task, but whatever the case, i needed to reboot. i rebooted, and unlike before, it just would not connect. it has taken me ***2 whole damn hours*** of fiddling to get connected again. i rebooted the laptop multiple times; i rebooted the gateway multiple times; it just would not work. i tried moving myself a few feet away from the router to ensure a strong signal. i told NM to forget the connection and re-added it, multiple times. i tried using iwctl to connect, but it just immediately reported failure on every attempt. i tried forcing a change of MAC with macchanger, no difference. my android smartphone connected fine when i fetched it and turned on the wifi... i turned off the gateway to scan visible networks with the smartphone to check that there wasn't a neighbour with the same router- model SSID, nope. so i pushed the reset button on the gateway, told NM to forget the connection, and interestingly had absolutely no trouble at all connecting this time. i restored a backup of the gateway's config and it rebooted. i then again had NM forget the connection and tried to re-add it, and it just kept refusing, giving me an 'activation of network connection failed' popup at the top of my screen. note, i'd been copying and pasting the password, so i know that's not the issue, i even compared the password in the NM connection config and that stored in the gateway (via a wired connection from an old machine). i switched the gateway wifi channel, no difference. i set the SSID to un-hidden. finally, shortly after doing this, it suddenly connected fine. i switched it back to hidden, then i went and sat down with the laptop to type this up, and after a minute or so, i notice the connection suddenly disappear, and again it's refusing to connect. interestingly it was yesterday that iwd was updated to v1.9; i'd left the laptop sleeping overnight, and just rebooting earlier today (if i recall correctly), so perhaps the 1.9 update has either introduced yet another problem on top, or otherwise made things much worse. since it's gone down again after switched back to hidden, i'll spend a little more time experimenting... so, rebooted, no difference. moved next to gateway, no difference. logged back into gateway via wired connection of older machine, changed wifi to non-hidden, saved, turned around and boom, it's suddenly got a wifi connection. turned back to the old machine, changed to hidden again, turned back to laptop, saw the wifi icon change to the '...' reconnect one temporarily, but if i recall now correctly it remained up, i then turned off and back on the wifi (on the laptop) and fails to connect. switched back to unhidden, and connects perfectly. so yeah, functionality for connecting to hidden networks is completely broken. so i switched things back to wpa_supplicant and rebooted. straight away, no issues at all connecting to the hidden SSID (after forgetting and re-adding again of course). i'm connected now and getting work done again. well, it's almost working perfectly back on wpasupplicant, i was back getting data transferred via rsync, and then eventually something went wrong preventing further transfer, but turning the wifi off and back on again fixed it. i recall that always being a bad as things had gotten previously with wpasupplicant.
Bug#969319: Info received ([Pkg-utopia-maintainers] Bug#969319: wifi cannot connect after combined suspend & gateway reboot)
a further update since the experimentation done this morning. for the past ~12 hours since then i've been getting a lot of work done on the laptop, and have **NOT** let it sleep during this time. somewhat randomly the problem has surfaced again, thus suggesting that sleeping has nothing to do with the source of the problem. i was doing something else for a few minutes before returning to the laptop. the lid was left up, so not sleeping, but it had turned off the screen. i unlocked my account. as best as i can recall, my next action was then to try to check for updates, only to find the command hung and finally failed. the wifi was still connected. i checked the lights on the gateway and they were good, so the internet connection was fine. it became apparent that the connection had gone bad somehow, refusing to let anything through. i've experienced this numerous times before, including, i'm certain, before i even installed iwd, let alone configured NM properly to use it (which was just a few weeks ago). so i turned the wifi off and back on (via the gnome menu), and it was refusing to connect. i captured activity with iwmon whilst trying numerous times to ask it to connect, sometimes turning wifi off and back on, and even waiting a full minute before trying again. it just would not connect. dmesg was showing the same issues as before. i was starting to shutdown some of the apps i had open, but then remembered that sometimes when i've experienced this before it was whilst deluge was running (which was not open this time), and closing deluge immediately fixed the problem. (immediately reopening deluge was not a problem). so i closed a couple of things with no change, then closed evolution, and bang, it connected perfectly fine having done so. so it seems to be the case that something occasionally manages to go wrong and jams up the connection (i'm not sure that it's a complete block on all apps sending messages over the connection, but certainly some), in a way that's linked to one of the running apps, which only gets fixed upon closing that app. i.e. an app (evolution it seems in this case, deluge commonly in others) is obtaining some locked access to the connection and failing to release it, even letting itself get blocked by the failed release of that resource. i've previously researched the problem with respect to deluge and found at least one other person experiencing this problem, which the deluge guys could not get to the bottom of as i recall. note, again, to be absolutely clear, deluge was not running in this instance, it seems to have been evolution this time. if this results from the same exact bug as is causing the originally reported problem, it's a little strange since in the experiments i was doing this morning i typically only had terminal and gedit open. of course there may be things like gnome-online-accounts automatically running in the background (which i have accounts setup in). in fact just in case it's relevant, i frequently get timeout errors and such in evolution relating to failures to fetch calendars and such from google.
Bug#969319: [Pkg-utopia-maintainers] Bug#969319: wifi cannot connect after combined suspend & gateway reboot
On Mon, 2020-08-31 at 14:02 +0200, Michael Biebl wrote: > Am 31.08.20 um 12:22 schrieb Lyndon Brown: > > Package: network-manager > > Version: 1.26.2-1 > > Severity: important > > > > I'm on Debian Sid, with network manager configured to use iwd. I > > have > > an Intel AX200 wifi card. > > > > Can you reproduce that with wpasupplicant? short answer no. details of hours of experimentation today follows... firstly, i forgot previously to mention that it's a hidden network. also, it can be noted that the other day i tried leaving the gateway on over night for a change, while leaving the laptop sleeping (lid shut), and when i returned to it the next day, it successfully reconnected. so time left sleeping does not seem to be a particularly significant factor, whilst the gateway being off for a while during that sleep definitely does. however, i've been doing that for the past few days now, and today experienced the same connection failure, despite the gateway having remained on the entire time. (unless there was a power cut while i slept i guess; i didn't check). so that's interesting. since that has forced me to close down all of the work i'm in the middle of (which is why i'm leaving it sleeping) for a reboot, i've taken the opportunity to investigate further as asked... firstly i felt the need to test reproducibility before any switch to wpa_supplicant. so i started off doing the following: 1. rebooted and logged in. 2. it connected automatically and i took the opportunity to install package updates. 3. i shut the lid and waited for approximately one minute. 4. turned off the gateway and waited for approximately one minute. 5. turned the gateway back on and waited for approximately one and a half minutes. 6. opened the lid of the laptop and unlocked it. unfortunately it had no issue reconnecting (which it did automatically). dmesg output: ``` [ 362.938616] PM: suspend exit [ 364.687381] wlan0: authenticate with «MAC» [ 364.691259] wlan0: send auth to «MAC» (try 1/3) [ 365.590534] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 365.590626] wlan0: Connection to AP «MAC» lost [ 366.175547] wlan0: send auth to «MAC» (try 2/3) [ 366.183586] wlan0: authenticated [ 366.183659] wlan0: associating with AP with corrupt probe response [ 366.186737] wlan0: associate with «MAC» (try 1/3) [ 366.198772] wlan0: RX AssocResp from «MAC» (capab=0x411 status=0 aid=1) [ 366.214860] wlan0: associated [ 366.512295] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready ``` so although it did not connect exactly cleanly, it still connected. perhaps there's a time factor and i need to leave it for longer? so i tried again, this time with the following differences: 1. directly locked the desktop first (win+l) 2. did not reboot since the last experiment 3. expanded the time periods from parts 3-5 of the previous experiment to 3min, 5min and 3min respectively. having returned to the laptop, this time it's not automatically reconnected. good. dmesg: ``` [ 1776.902728] PM: suspend exit [ 1778.750632] wlan0: authenticate with «MAC» [ 1778.753331] wlan0: send auth to «MAC» (try 1/3) [ 1779.321626] wlan0: send auth to «MAC» (try 2/3) [ 1780.220436] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 1780.220475] wlan0: Connection to AP «MAC» lost [ 1780.281716] wlan0: send auth to «MAC» (try 3/3) [ 1781.180748] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 1781.180849] wlan0: Connection to AP «MAC» lost [ 1781.304939] wlan0: authentication with «MAC» timed out ``` explicitly selecting the network fails, ah but damn, turning it off then back on it's now successfully connected, which is not what has been happening previously. ``` [ 1776.902728] PM: suspend exit [ 1778.750632] wlan0: authenticate with «MAC» [ 1778.753331] wlan0: send auth to «MAC» (try 1/3) [ 1779.321626] wlan0: send auth to «MAC» (try 2/3) [ 1780.220436] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 1780.220475] wlan0: Connection to AP «MAC» lost [ 1780.281716] wlan0: send auth to «MAC» (try 3/3) [ 1781.180748] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 1781.180849] wlan0: Connection to AP «MAC» lost [ 1781.304939] wlan0: authentication with «MAC» timed out [ 1978.199366] wlan0: authenticate with «MAC» [ 1978.204215] wlan0: send auth to «MAC» (try 1/3) [ 1979.103492] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 1979.103593] wlan0: Connection to AP «MAC» lost [ 1979.322185] wlan0: send auth to «MAC» (try 2/3) [ 1980.221124] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [ 1980.221207] wlan0: Connection to AP «MAC» lost [ 1980.282051] wlan0: send auth to «MAC» (try 3/3) [ 1981.181057] iwlwifi :3a:00.0: No beacon heard and the session protection is over already...
Bug#969319: [Pkg-utopia-maintainers] Bug#969319: wifi cannot connect after combined suspend & gateway reboot
Am 31.08.20 um 12:22 schrieb Lyndon Brown: > Package: network-manager > Version: 1.26.2-1 > Severity: important > > I'm on Debian Sid, with network manager configured to use iwd. I have > an Intel AX200 wifi card. > Can you reproduce that with wpasupplicant? signature.asc Description: OpenPGP digital signature
Bug#969319: wifi cannot connect after combined suspend & gateway reboot
Package: network-manager Version: 1.26.2-1 Severity: important I'm on Debian Sid, with network manager configured to use iwd. I have an Intel AX200 wifi card. Normally the wifi of my laptop connects to my home gateway automatically, but there's a issue where it cannot connect until rebooted after a combined suspending of the laptop and rebooting of the router. My normal daily routine involves turning the gateway on first (no point wasting electricity leaving it on over night), then getting out the laptop and turning that on. There's no problem in this scenario. If at any time during the day I reboot the gateway, it handles this fine (or at least if it doesn't automatically reconnect it connects fine on manually selecting the network from the list Gnome provides). A lot of the time when I go off to do something else, I leave the lid open, so no suspending, but sometimes I do close the lid and thus let the laptop sleep, and similarly, no real issues with connecting when I get back on it. I can select the 'turn off' wifi option and turn it back on, and it reconnects fine. However, something I've done instead for the past couple of nights is to lock the user account, close the lid to let it sleep, and then turn off the gateway. The problem I'm experiencing is that after turning the gateway back on, and then (minutes later) returning to the laptop, it's impossible to reconnect without rebooting. Selecting the network from the list Gnome provides, the wifi connecting icon appears for a few seconds, then just disappears. Checking dmesg, this is what I'm seeing (MAC censored): [223484.493130] wlan0: authenticate with «MAC» [223484.496051] wlan0: send auth to «MAC» (try 1/3) [223485.395342] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223485.395383] wlan0: Connection to AP «MAC» lost [223485.759776] wlan0: send auth to «MAC» (try 2/3) [223486.658815] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223486.658853] wlan0: Connection to AP «MAC» lost [223486.751809] wlan0: send auth to «MAC» (try 3/3) [223487.650547] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223487.650625] wlan0: Connection to AP «MAC» lost [223487.710943] wlan0: authentication with «MAC» timed out [223503.680212] wlan0: authenticate with «MAC» [223503.685609] wlan0: send auth to «MAC» (try 1/3) [223504.585038] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223504.585098] wlan0: Connection to AP «MAC» lost [223504.735885] wlan0: send auth to «MAC» (try 2/3) [223505.634822] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223505.634869] wlan0: Connection to AP «MAC» lost [223505.759800] wlan0: send auth to «MAC» (try 3/3) [223506.658534] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223506.658564] wlan0: Connection to AP «MAC» lost [223506.718845] wlan0: authentication with «MAC» timed out [223803.377295] wlan0: authenticate with «MAC» [223803.382092] wlan0: send auth to «MAC» (try 1/3) [223804.281508] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223804.281602] wlan0: Connection to AP «MAC» lost [223804.736105] wlan0: send auth to «MAC» (try 2/3) [223805.635147] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223805.635194] wlan0: Connection to AP «MAC» lost [223805.728010] wlan0: send auth to «MAC» (try 3/3) [223806.627041] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223806.627081] wlan0: Connection to AP «MAC» lost [223806.719201] wlan0: authentication with «MAC» timed out [223878.248338] wlan0: authenticate with «MAC» [223878.255331] wlan0: send auth to «MAC» (try 1/3) [223879.154749] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223879.154801] wlan0: Connection to AP «MAC» lost [223879.776037] wlan0: send auth to «MAC» (try 2/3) [223880.675073] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223880.675113] wlan0: Connection to AP «MAC» lost [223880.735862] wlan0: send auth to «MAC» (try 3/3) [223881.634760] iwlwifi :3a:00.0: No beacon heard and the session protection is over already... [223881.634804] wlan0: Connection to AP «MAC» lost [223881.727233] wlan0: authentication with «MAC» timed out I tried turning wifi off and back on again (via the Gnome menu) and manually selecting the network, which did not help, same failure. I have macchanger installed, and tried switching to a new random MAC to see if that helped (with the wifi off temporarily, obviously), but it did not help. I tried rebooting the gateway again, which also did not help. I tried closing the lid for a few moments to recycle through a sleep state, which did not help. So I rebooted, as I did the day before when this happened, and it connected just fin
