ValveSoftware
3.7.8 No WiFi, Controls Do Not Function
System Info:
- Steam client version: 1747772770
- SteamOS version: 3.7.8
- Opted into Steam client beta?: No
- Opted into SteamOS beta?: No
- Have you checked for updates in Settings > System?: Yes
Issue Description:
After updating to 3.7.8 on OLED and rebooting WiFi would not connect automatically. Attempting to reconnect manually would render all physical buttons inoperable except the power button and the touch screen. Software power options / switch to desktop option just hang and never complete after attempting to manually connect to WiFi as well. Only way to restore controls is to hold power to hard shutdown and restart. This reboot does not fix the WiFi issue.
Steps for reproducing this issue:
- Install 3.7.8
- Reboot
- Attempt to manually connect to WiFi
I've been seeing more then one report of this occurring with the latest stable update
https://steamcommunity.com/app/1675200/discussions/0/597401552634812145/
I had the entire left side of the controller straight up just stop working on 3.7.8, Im on an 256gb LCD
I encountered the same problem on my Steam Deck OLED. The only thing that helped was rolling back to the previous version
Same issue here in Steamdeck OLED on 3.7.8. Rolling back to 3.6.24 wifi works fine.
Issue persisted even after resetting the KDE wallet for the wifi keystore, deleting and readding the networks, and even removing the user account password before updating thinking this might be related. Issue persists regardless of the above.
Of note, this system does have tailscale installed but this should not be an issue, and I don't believe other users have mentioned this.
For users rolling back for now, use the command "sudo rauc status mark-active booted" from 3.6.24 in desktop mode terminal to make the revert permanent until this is patched. Otherwise you will go back to the 3.7.8 with broken wifi each reboot. You will need to set a user password to run this command. Make sure not to forget it, or run the command to remove your user password afterwards instead.
I dont think I had any issues with WiFi, but having half my Deck's controls suddenly dead isnt helpful. I just hope Valve sees this.
I dont think I had any issues with WiFi, but having half my Deck's controls suddenly dead isnt helpful. I just hope Valve sees this.
Have you tried reverting to 3.6.24? This fixed my issues until there is a fix for the update.
https://help.steampowered.com/en/faqs/view/1B71-EDF2-EB6D-2BB3#menu
Replying to https://github.com/ValveSoftware/SteamOS/issues/1907#issuecomment-2903335353
Yeah Ive done this and it worked for me. My only gripe is that I have to do this every time I need to restart the Steam Deck and Ryujinx sometimes doesnt play nice, it can sometimes cause the Deck to lock up and require a restart.
Replying to https://github.com/ValveSoftware/SteamOS/issues/1907#issuecomment-2903345531
To make the rollback permanent:
- Ensure you already set up a sudo password.
- Go to desktop mode and open Konsole or open Konsole from game mode if you already have a shortcut there.
- If you already used the boot menu to boot into 3.6.24, run the following command
sudo rauc status mark-active bootedto make the current boot option persistent. If you haven't done so and you booted into 3.7.8, you must usesudo rauc status mark-active otherto switch the boot option on next reboot and make it persistent. Then reboot the Steam Deck to boot into 3.6.24 by default.
Hope it helps.
Replying to https://github.com/ValveSoftware/SteamOS/issues/1907#issuecomment-2903774164
Worked a treat, cheers.
I had the same Wi-Fi connection issue after the update. Here's what worked for me:
Enabled Developer Mode (Settings > System > Enable Developer Mode).
Went to the new Developer tab in settings.
Under the WiFi section:
Disabled: Enable WiFi Power Management
Enabled: Force WPA Supplicant WiFi backend
After making these changes, my Steam Deck was finally able to connect to the 2.4 GHz band of my router.
Hope this helps others facing the same problem.
I had the same issue, 3.7.8, no WiFi (connecting to Orbi RBR50 mesh network), Steam button seemed to have no effect.
While testing is Desktop Mode, It was getting stuck on 'acquiring network address', however montioring the logs on my Orbi, no connection was logged.
Steam Deck OLED 512GB.
Used recovery menu to roll back to 3.6.24, everything works again.
This was the output from journalctl -f | grep -I wlan
May 23 15:31:57 steamdeck NetworkManager[1081]: <info> [1748010717.1669] device (wlan0): Activation: starting connection 'Wright' (eac83dcf-5a6e-42c4-8651-5ec2f3e282d0)
May 23 15:31:57 steamdeck NetworkManager[1081]: <info> [1748010717.1671] device (wlan0): state change: disconnected -> prepare (reason 'none', managed-type: 'full')
May 23 15:31:57 steamdeck NetworkManager[1081]: <info> [1748010717.1676] device (wlan0): state change: prepare -> config (reason 'none', managed-type: 'full')
May 23 15:31:57 steamdeck NetworkManager[1081]: <info> [1748010717.1688] device (wlan0): new IWD device state is connecting
May 23 15:31:59 steamdeck kernel: wlan0: authenticate with 9c:c9:eb:e1:b4:e3 (local address=b0:0c:9d:93:d1:6f)
May 23 15:31:59 steamdeck kernel: wlan0: send auth to 9c:c9:eb:e1:b4:e3 (try 1/3)
May 23 15:31:59 steamdeck kernel: wlan0: authenticated
May 23 15:31:59 steamdeck kernel: wlan0: associate with 9c:c9:eb:e1:b4:e3 (try 1/3)
May 23 15:31:59 steamdeck kernel: wlan0: RX AssocResp from 9c:c9:eb:e1:b4:e3 (capab=0x1511 status=0 aid=7)
May 23 15:31:59 steamdeck kernel: wlan0: associated
May 23 15:31:59 steamdeck NetworkManager[1081]: <info> [1748010719.1591] device (wlan0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Connected to 'Wright'.
May 23 15:31:59 steamdeck NetworkManager[1081]: <info> [1748010719.1679] device (wlan0): new IWD device state is connected
May 23 15:31:59 steamdeck NetworkManager[1081]: <info> [1748010719.1730] device (wlan0): state change: config -> ip-config (reason 'none', managed-type: 'full')
May 23 15:31:59 steamdeck NetworkManager[1081]: <info> [1748010719.1777] dhcp4 (wlan0): activation: beginning transaction (timeout in 45 seconds)
May 23 15:32:05 steamdeck plasmashell[13571]: org.kde.plasma.nm.libs: Wireless scan on "wlan0" failed: "Scanning not allowed at this time"
May 23 15:32:05 steamdeck systemsettings[16379]: org.kde.plasma.nm.libs: Wireless scan on "wlan0" failed: "Scanning not allowed at this time"
May 23 15:32:15 steamdeck plasmashell[13571]: org.kde.plasma.nm.libs: Wireless scan on "wlan0" failed: "Scanning not allowed at this time"
May 23 15:32:16 steamdeck systemsettings[16379]: org.kde.plasma.nm.libs: Wireless scan on "wlan0" failed: "Scanning not allowed at this time"
May 23 15:32:25 steamdeck plasmashell[13571]: org.kde.plasma.nm.libs: Wireless scan on "wlan0" failed: "Scanning not allowed at this time"
May 23 15:32:26 steamdeck systemsettings[16379]: org.kde.plasma.nm.libs: Wireless scan on "wlan0" failed: "Scanning not allowed at this time"
May 23 15:32:35 steamdeck plasmashell[13571]: org.kde.plasma.nm.libs: Wireless scan on "wlan0" failed: "Scanning not allowed at this time"
May 23 15:32:36 steamdeck systemsettings[16379]: org.kde.plasma.nm.libs: Wireless scan on "wlan0" failed: "Scanning not allowed at this time"
May 23 15:32:43 steamdeck NetworkManager[1081]: <info> [1748010763.9816] device (wlan0): state change: ip-config -> failed (reason 'ip-config-unavailable', managed-type: 'full')
May 23 15:32:43 steamdeck NetworkManager[1081]: <warn> [1748010763.9822] device (wlan0): Activation: failed for connection 'Wright'
May 23 15:32:43 steamdeck NetworkManager[1081]: <info> [1748010763.9824] device (wlan0): state change: failed -> disconnected (reason 'none', managed-type: 'full')
May 23 15:32:43 steamdeck NetworkManager[1081]: <info> [1748010763.9983] dhcp4 (wlan0): canceled DHCP transaction
May 23 15:32:43 steamdeck NetworkManager[1081]: <info> [1748010763.9984] dhcp4 (wlan0): activation: beginning transaction (timeout in 45 seconds)
May 23 15:32:43 steamdeck NetworkManager[1081]: <info> [1748010763.9984] dhcp4 (wlan0): state changed no lease
May 23 15:32:44 steamdeck kernel: wlan0: deauthenticating from 9c:c9:eb:e1:b4:e3 by local choice (Reason: 3=DEAUTH_LEAVING)
May 23 15:32:44 steamdeck NetworkManager[1081]: <info> [1748010764.1689] device (wlan0): new IWD device state is disconnecting
May 23 15:32:44 steamdeck NetworkManager[1081]: <info> [1748010764.1690] device (wlan0): new IWD device state is disconnected
Might be helpful: https://github.com/ValveSoftware/SteamOS/issues/1904
state change: ip-config -> failed (reason 'ip-config-unavailable' …
This means the deck associated with the AP but the DHCP transaction immediately after failed. If switching to the WPA backend works to fix this, that would be interesting to know.
Also - does this happen immediately after booting, or only after a suspend/resume?
After upgrading to 3.7.8, no connection whatsoever, rebooted, suspend, desktop. Even removed and re-added network to no avail.
However, Dev mode, Force WPA Supplicant WiFi backend worked fine on 3.7.8. Connected straight away.
Using WPA/WPA2 Personal
Enabling the Developer Mode option for WPA Supplicant resolved the Wi-Fi issue for now. Did not notice any major increase in wifi resume time after sleep or major impact on speed.
I have not personally experienced the control issue, so the WPA Supplicant option provides a temporary relief to the wifi issue, in my case.
Replying to https://github.com/ValveSoftware/SteamOS/issues/1907#issuecomment-2904730787
I was losing my mind trying to connect to wifi with a brand new unit. I have the same setup. What I did was go into desktop mode, connect to the guest network, and then set the BSSID to lock it. Seemed to work so far, but glad to know it's likely a regression in 3.7 and I just have unlucky timing.
I can +1 this problem (OLED, 3.7.8, 1748914100). Rollback and WPA supplicant each separately solve the problem. Very curious what's going on here. I've seen scattered discussion of wifi ax being the problem, but my ax home router wifi has been fine, it's just my ax repeater that's a problem, and even if I turn off its 5 GHz channel (or vice-versa), so I don't think that's the same issue. I also have very similar journalctl output to what D5120 showed above.
I would also note that there's actually two issues in this! The first is that the wifi is broken with certain networks. The second is that when the wifi connection hangs in a certain way, the SteamOS game mode UI locks up as OP describes. Although unlike OP, I did find a second way out - leaving it alone for a while seemed to trigger some sort of watchdog that rebooted and "verified installation". Connecting in Desktop Mode doesn't work but also doesn't hang the entire system, so I think there's a Game-Mode-Specific bug.
Interestingly, at least in Desktop Mode, connecting to my good network and then the bad network seemed to work most of the time. I didn't feel like hanging my system repeatedly to test this in Game Mode.
I'm afraid of creating duplicate things so I'll let someone more involved with things do what they will with that information.
The controls hanging is almost certainly something blocked on network access, and you're right, there are watchdogs that kick in if things are blocked for too long.
The WiFi issue is being looked into but it's a weird one. Only some networks affected, only iwd, no obvious reason why yet.
If anyone is using an access point/router other than Orbi RBR50 mesh network, please share the make/model
If anyone is using an access point/router other than Orbi RBR50 mesh network, please share the make/model
MSI RADIX AXE6600
If anyone is using an access point/router other than Orbi RBR50 mesh network, please share the make/model
Netgear Nighthawk R9000 - latest firmware (1.0.5.42)
There's a firmware change in SteamOS 3.7.10 which may fix this.
I can confirm, Beta 3.7.10 resolved the connectivity issues with my Orbi RBR50 👍🏻
The controls hanging is almost certainly something blocked on network access, and you're right, there are watchdogs that kick in if things are blocked for too long.
Seems weird and wrong that there would be network communications blocking fundamental UI interactions like opening the power menu and shutting down. The UI really just entirely breaks down.
If anyone is using an access point/router other than Orbi RBR50 mesh network, please share the make/model
TP-Link WA1801 causing problems for me, latest firmware.
I'll try this beta when I can.
Seems weird and wrong that there would be network
Well it's not right :)
communications blocking fundamental UI interactions like opening the power menu and shutting down. The UI really just entirely breaks down.
I'm guessing based on the symptoms you decribe - can't think of another way those two things would even be connected.
3.7.10 Beta fixes the issue for me too. 🥳 Do we know when that goes stable? I'm not really a beta sort of Deck user.
I'm guessing based on the symptoms you decribe - can't think of another way those two things would even be connected.
I didn't really get into it because it's all very speculative on my part and even in touching on it too briefly I've been unclear in my meaning and put my foot in it. What I mean is that it doesn't make sense to me that networking problems would be the real cause of the UI breakage. I think there's an entirely separate bug (being triggered by but not specific to the networking bug) wherein the UI breaks when any system task it has dispatched hangs.
If we revisit the trigger/symptoms for the UI parts of the bug, it happens when manually connecting to the problematic network. Having the background systems automatically attempt connection doesn't break the UI interactivity at all (and of course just not having networking usually doesn't break the UI either). So I don't think it's networking at fault, but a separate problem with the UI architecture. I infer that the UI is getting hung up because it's prompting the system to do something and just never gets a response, because the connection never completes and also apparently never fails (or is never recognised to have failed). IIRC, you have the option to cancel and I guess that too never returns as having been acknowledged. The UI is forever waiting to report success or failure that never comes. In the meantime, the UI remains locked out as that's "in the foreground" and, being hung, appears to blackhole most interactions. And/or, guessing from the fact that you can't shut down either, there's some system task/message queue that gets entirely backed up and the UI can't task the system to actually do anything any more.
But again, it's all speculation and I don't think there's much value in theorycrafting what might be going on within the Deck's UI software.