[Steam Deck] 5GHz Wifi Refuses to Connect After Wake from Sleep or Power-On

[ThisNekoGuy]

Your system information

• Steam client version: 1679113038
• SteamOS version: 3.4.6 Stable
• Opted into Steam client beta?: Yes
• Opted into SteamOS beta?: No
• Have you checked for updates in Settings > System?: Yes

Please describe your issue in as much detail as possible:

Waking up the Steam Deck from sleep ocassionally causes the 5GHz wifi device in it to stop connecting and refuse reconnects with the message: "Could not activate connection: Activation failed: Secrets were required, but not provided (7)" when attempting to use nmcli and/or nmtui to re-establish the connection and attempting to do so via Plasma in desktop mode yields the same result.

Forcing Plasma to forget the connection from the settings throws a notification message about "not being able to" doing to some sort of lack of authorization but then removes it from the known wifi networks list anyway.

From there, attempting to connect to the network via nmcli like so: nmcli wifi connect <network_name> throws the error message again by then flickers an authentication window for provided the "secrets" it desired; this can be more easily seen by rapidly using the "up" direction on the directional-pad and pressing A to force the system to work harder and potentially cause the window to appear just long enough to be legible before it closes itself again.

I take it there's some kind of issue where either isn't a keychain handler(?), which Network Manager needs in order to reliably stay connected, or whatever keychain handler SteamOS is using just isn't passing along what it needs to? I've seen people claim it's a wifi driver issue but I question that being the case when Network Manager claims authentication errors rather than something else?

That aside, getting around this is non-trivial; it can eventually start working again but it takes a variable amount of time that is incredibly annoying. It simply works when it wants to and stops when it doesn't. And considering this is supposed to be a handheld device that requires a connection via online login to even use it after reboots, busted network connectivity is quite unacceptable; especially for a high-tier model (that I have).

I get that the Steam Deck is meant to be a WIP device that you guys are trying to improve over time, but this is a pretty severe issue given whay I just mentioned. It's already annoying that I need to be online to login to handheld mode, when I could be out somewhere, but even worse when I can't even do that because it refuses connections. How am I supposed to reccomend this thing to anyone knowing they're going to come back to me saying that this is (rightfully) ridiculous?

Steps for reproducing this issue:

1. In handheld mode, press the power button to go into sleep mode
2. Wait maybe a few days (as I did)
3. Wake it up from sleep

Side note: This happened to my brother as well but with one difference; he actually turns his Deck off completely when he's not using it and he also had this same issue after turning it on.

[Opiboble]

Just want to chip and state that I am having this exact issue, even on a connection with zero security. Driving me capital C, crazy because the 2.4ghz bands in my area are swamped with interference.

[craftyguy]

I've been trying to reproduce this, but haven't been able to so far... it has no problem reconnecting to 5GHz wifi after resuming from suspend (no SteamOS 3.4.6 stable):

(deck@steamdeck ~)$ iw dev wlan0 info
Interface wlan0
        ...
        channel 157 (5785 MHz), width: 80 MHz, center1: 5775 MHz

If, according to @Opiboble, this is unrelated to actual WPA authentication, then maybe it has something to do with the channels used, or some other parameter? @ThisNekoGuy, @Opiboble are you both using a DFS channel for your 5GHz networks?

[pzmarzly]

I'm observing the same issue on my 5G network, on Steam OS 3.4.6 (20230313.1). 2.4GHz network from the same D-Link DIR-825ACG1 router works fine. Output of MacOS Wireless Diagnostics.app:

xxxxxx_2_4G - ssid=535xxxxx035, shortSSID=2xxxxx4, bssid=78:98:e8:xx:xx:xx, security=wpa2-personal, channel=[2g1/40 (0x20c)], cc=(null), phy=b/g/n (0x1C), rssi=-31, rsn=[mcast=aes_ccm, bip=none, ucast={ aes_ccm }, auths={ psk }, mfp=no, caps=0x0], wpa=(null), wapi=no, wep=no, 6e=no, filsd=no, ibss=no, ph=no, swap=no, hs20=no, age=0ms, match=[(null)]

xxxxxx_5G - ssid=535xxxxx547, shortSSID=1xxxxxx7, bssid=78:98:e8:xx:xx:Xx, security=wpa2-personal, channel=[5g36/80 (0x410)], cc=US, phy=a/n/ac (0x92), rssi=-40, rsn=[mcast=aes_ccm, bip=none, ucast={ aes_ccm }, auths={ psk }, mfp=no, caps=0x0], wpa=(null), wapi=no, wep=no, 6e=no, filsd=no, ibss=no, ph=no, swap=no, hs20=no, age=0ms, match=[(null)]

[craftyguy]

I'm still struggling to reproduce this... how often is this happening for y'all?

@pzmarzly based on that output, it appears that your network is not using any authentication either?

When this happens again, can someone provide the output from networkmanger and iwd around the time when the connection fails?

See the instructions here for enabling debug logging for NetworkManager and sending logs: https://github.com/ValveSoftware/SteamOS/issues/997#issuecomment-1642579600

[ThisNekoGuy]

@craftyguy logs.zip

It happens to me fairly frequently, btw

[craftyguy]

If you configure your 5GHz network to use a 20MHz channel width (instead of 40MHz and/or 80MHz), can you still reproduce it frequently?

How you do that depends on your wireless AP's config, but here's an example of what it might look like:

edit: Obviously changing the channel width is not really a "fix", but if someone can confirm that it helps then it might mean that I have been able to finally reproduce the same issue 😅

[ThisNekoGuy]

I changed it to 20MHz, after your suggestion, and it was fine for a few days since then but then it happened again just now

[CinisSec]

Steamdeck info: Updates: Stable Version: 3.4.6

I'm having the exact same problem since this morning. It worked fine this morning, was downloading a game, paused it, put in sleep, and when it woke up it couldn't connect to the wifi. Whenever I use nmcli: nmcli device wifi connect <SSID> A KDE window pops up to ask for the key I input the key and a few seconds later receive this feedback from nmcli: Error: Connection activation failed: (7) Secrets were required, but not provided.

Disabling power management in developer mode didn't work. Rebooting a few times didn't work. Shutting down didn't work.

I've noticed instability in sleep and waking since a week or two ago.

Edit: Changing "Infrastructure" to "Access Point" with 5GHz with automatic band and manual IP configuration in the KDE GUI I was able to activate the connection. Sadly I still had no access to the internet.

Edit2: After a factory reset 2.4Ghz wifi works again. No luck with 5Ghz.

[craftyguy]

@ThisNekoGuy thanks for the info! If you're willing to do another experiment, it would be helpful to know if switching to the "main" SteamOS channel, and leaving the 5GHz chan width at 20MHz is even more reliable.

Switching to the "main" channel involves enabling developer mode, and you should be able to switch back to the stable channel afterwards.

Also confirm the following setting in /etc/NetworkManager/config.d/wifi_backend.conf is set to "yes" when you've updated to the "main" SteamOS channel (or set it to "yes" if it's not, then reboot or restart NetworkManager):

[device]
...
wifi.iwd.autoconnect=yes

[craftyguy]

Also curious if folks who have this problem can share info about the wireless access point they are using (like make and model, and firmware version if that's known).

[ThisNekoGuy]

It still rejects the connection after doing this

Also, my router is an Asus RT-AC88U Firmware version: 3.0.0.4.386_48260-gd4c241c

[craftyguy]

@ThisNekoGuy which hardware version do you have? that info is printed on the barcode sticker under the device, HW Ver.: A2 (for example)

[ThisNekoGuy]

I don't have that sticker; not sure if I took it off when I first got it (I can't remember) :skull_and_crossbones:

[craftyguy]

ah, maybe it says in the web UI? anyways, no big deal if you can't find it. I'm going to pick one up, and would prefer to match it as closely to what you have as possible, but if that's unknown then I'll just hope that the hw differences between versions don't matter 😅

[ThisNekoGuy]

All I'm able to find in the UI is the serial number :v

[craftyguy]

@ThisNekoGuy

Looking at the logs you posted earlier, iwd is unable to load the connection configuration file from it's config dir:

Apr 09 20:26:36 steamdeck iwd[965]: Error loading /var/lib/iwd//5G_WIFI.psk

And around that time, NM reports a failure to connect:

Apr 09 20:26:36 steamdeck NetworkManager[912]: <info>  [1681089996.3655] device (wlan0): new IWD device state is connecting
Apr 09 20:26:38 steamdeck NetworkManager[912]: <error> [1681089998.9433] device (wlan0): Activation: (wifi) Network.Connect failed: GDBus.Error:net.connman.iwd.Failed: Operation failed
Apr 09 20:26:38 steamdeck NetworkManager[912]: <info>  [1681089998.9436] device (wlan0): state change: config -> failed (reason 'no-secrets', sys-iface-state: 'managed')
Apr 09 20:26:38 steamdeck NetworkManager[912]: <info>  [1681089998.9441] manager: NetworkManager state is now DISCONNECTED
Apr 09 20:26:38 steamdeck NetworkManager[912]: <warn>  [1681089998.9444] device (wlan0): Activation: failed for connection '5G_WIFI'

There's another experiment I'd like you to try if you are willing to:

1) Update to the latest SteamOS Main channel (which should include the changes I mentioned here)

2) Enable max logging for NetworkManager:

$ sudo busctl call org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager SetLogging ss "TRACE" "DEFAULT"

3) Reproduce the issue earlier, capture logs (steps here)

I'm also curious if you can reproduce the issue using this to trigger NetworkManager's sleep/resume logic:

# To trigger "sleep" logic in NM, this is also triggered systemd/logind system suspend:
$ sudo busctl call org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager Sleep b true

# Trigger "resume from sleep" logic in NM, also triggered automatically when waking from system suspend:
$ sudo busctl call org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager Sleep b false

I originally thought maybe there's a race condition between NM writing the connection config and iwd trying to load it, causing that error seen in your iwd log, but so far I have been unable to prove it on my steam deck. Hopefully verbose logs from NM give us more of a hint, that's easier than patching NM to try and trace what might be happening.

[gavsiu]

I also have this issue since I first received my Steam Deck. It happens at least 50% of the time I turn it on. In Game Mode, it keeps complaining it couldn't connect with my credentials and I just press OK several times and it connects.

Router Model: Netgear R7000
Firmware Version: DD-WRT v3.0-r47495 std (09/28/21)
Kernel Version: Linux 4.4.285 #4130 SMP Mon Sep 27 04:27:57 +07 2021 armv7l

Here are the settings if it helps.

I prefer not to change SteamOS channels, yet unless there is no other option.

I think earlier today, it wouldn't connect, but it connected just now when I turned it on. I tried triggering NetworkManager's sleep/resume, but every time it connected. I will have to try that next time it doesn't.

[gavsiu]

It turned on unable to auto connect today. I ran the 2 NetworkManager commands 4 times before it connected. Every time it failed, the notification said "No secrets were provided".

I was trying to grab the logs but it says invalid option -- 'b'. Does it need to run with that option?

Also, how do I set logging back to default if I set it to max logging?

[craftyguy]

@gavsiu

hey thanks for offering to get logs!

I was trying to grab the https://github.com/ValveSoftware/SteamOS/issues/997#issuecomment-1502169054 but it says invalid option -- 'b'. Does it need to run with that option?

Ugh, sorry I had a typo.. I've edited that original comment to link to this one.

To collect system logs in SteamOS with the Steam Client:

1) Update to the Steam Client beta: Settings -> System, select "beta" channel. This will update Steam to the latest beta, but the rest of SteamOS will stay on 3.4.x.

2) Enable debug logging with networkmanager's nmcli (instead of using dbus, as I mentioned earlier):

$ sudo nmcli general logging level debug domains default

3) Once the debug logging is enabled and the Steam Client has been upgraded to the latest beta, reproduce the issue

4) when the issue happens, send logs to Valve by going to Settings->System->Advanced (towards bottom)->System Report->Create Report

After you submit the report, let me know your steam account (does github allow PMs?). Alternatively, you can paste the report in this issue, but it may have some sensitive info in it (it collects system journald output, which could have MAC addresses, SSIDs, etc. Please review / scrub if you decide to paste it here!)

To restore logging back to the default level:

$ sudo nmcli general logging level info domains default

[gavsiu]

It's weird, but I haven't had an issue since I enabled debug logs. Once or twice I thought it wouldn't connect, but when I went into Desktop Mode to grab logs, it just connected. Unless there was a SteamOS update for stable that fixed it. I'll post if it happens again.

[huangpohao]

Hi @gavsiu,

Did you use different steamos version between these two results? May I ask what steamos version are you using right now(the one without issue)?

[gavsiu]

I don't think the system updated in between. I'm on stable 3.4.8 build 20230508.1. There was a few times it didn't connect right away, but when I switched to desktop mode, it connected without complaining about secrets.

[gavsiu]

Alright. I finally caught it having issues connecting. I switched to desktop mode and it said no secrets provided or whatever.

I tried copying the system report, but I'm guessing the Game Mode copy button is non-functional. I added Kwrite as a non-Steam game and was unable to paste. Jumping back and forth, I just sent the system report to Valve before wifi finally connected in Desktop Mode.

It doesn't seem like GitHub has pm. For the record, the log was sent around 12:50 am August 11.

[craftyguy]

@gavsiu I'll need to know your steam account (or link to your steam profile) in order to retrieve it

[craftyguy]

@gavsiu unfortunately it looks like the report you tried to submit didn't go through, likely because it was submitted while you were still disconnected from the internet? Anyways, would you be able to reproduce the issue again, and this time submit that system report after re-connecting? If you need to reboot to get the connection re-established, that's OK too since the system report includes the previous boot's journald entries.

[rmzfm]

I think I'm having the same issue since 2 days. I forgot both networks and tried to reconnect. The 5GHz one just throws the same error again, the 2.4GHz reboots my deck after entering the password and selecting connect.

[thimslugga]

I've started experiencing this issue recently, device has been pretty much unusable as I can't reliably connect to the WiFi. In desktop mode I noticed my 5GHz SSID shows frequency of 2.4, which is odd since I separate my 5 and 2.4 to their own dedicated SSIDs. When I am able to connect it seems like it's the 2.4, so definitely seems like an issue pertaining to connecting to 5GHz.

[doraskayo]

In case anyone is interested, I managed to get around two WiFi issues with Steam Deck that were mentioned in this issue:

1. It failed to connect, asking me to enter a password even though I specified the correct password. When attempting to connect from Desktop Mode, it showed the error "No secrets were provided"
   • I got around this issue using the procedure I described in this comment.
2. It refused to acknowledge the existence of the the 5 GHz BSSID and only ever connected to the 2.4 GHz BSSID. This happened regardless of whether I used the same SSID or different SSIDs for each channel.
   • As far as I could tell, the device refuses to list or connect to DFS channels (see table here).
   • To work around this issue, I changed the 5 GHz channel in my Access Point to a non-DFS channel following the table above. In my case, using channel 36 (5170–5250 MHz) allowed me to continue to use 80 HMz channel bandwidth without overlapping with DFS frequencies.

After working around these two issues, the only WiFi issue remaining is relatively low signal range compared to other (even smaller) devices. WiFi otherwise works very well.

[lostgoat]

@doraskayo Do the errors still happen if you switch back to iwd but keep the channel selection you described in point 2?

[doraskayo]

@doraskayo Do the errors still happen if you switch back to iwd but keep the channel selection you described in point 2?

Yes, the two issues seemed independent in my tests.