novoyuuparosk-wiki/tech-blogs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

steam-deck-wifi: procedural update

Browse Source
This commit is contained in:
Mikkeli Matlock
2026-07-28 07:01:33 +09:00
parent c5f57d6305
commit fe5ae12047
1 changed files with 38 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
blogs/2026-06-27_steam-deck-wifi.md
+35 -18
View File
@@ -9,45 +9,62 @@ wiki:
publish: false
---
I have a Steam Deck OLED (512GB) and I pretty much like playing games with it. Then I run into a problem that I don't really have games that fit the Deck form factor really well. Shape and size-wise it's a mobile device with a very good built-in controller. The touchpad-as-mouse is good but not as good as a mouse or a trackball.
And for reasons I won't disclose because I don't exactly know myself, I picked Arknights: Endfield to be my controller-native game to play on the Deck. I imagined that with the outrageous mobility of your Steam Decks, it'll be fully possible to enjoy the unnecessarily complicated modern mobile game while lying in bed, connected to WiFi.
I have a Steam Deck OLED (512GB) and I very much like playing games on it. Then I run into a problem that I don't really have games that fit the Deck form factor really well. Shape and size-wise it's a mobile device with a very good built-in controller. The touchpad-as-mouse is good but not as good as a mouse or a trackball.
And for reasons I won't disclose as I'm not sure what they are, I picked Arknights: Endfield to be my controller-native game to play on the Deck. I imagined that with the outrageous mobility of your Steam Decks, it'll be fully possible to enjoy the unnecessarily complicated modern mobile game while lying in bed, connected to WiFi.
That's where things started to go wrong, fortunately.
**Spoiler / TL;DR**: It's the IPv4-over-IPv6 having a tiny MTU, and SteamOS somehow handling that (PMTUD) strangely.
**Spoiler / TL;DR**: It's the IPv4-over-IPv6 having a tiny MTU (because IPv4 packets get encapsulated in IPv6 packets), and SteamOS somehow handling that (PMTUD) strangely.
## Running a Windows-oriented modern online game on SteamOS was not a problem
So I won't go too deep into this. As simple as booting every relevant Windows exe through Steam using Proton. Then you could have the game executable running.
I'll leave some *useful tips* that may or may not apply to everyone.
- Deck is not exactly the biggest graphics powerhouse and my experience is only the lowest of low graphics is playable. Good thing is the screen is also not the biggest and that actually does real-world supersampling for your eyes.
- While debugging things people tend to use the desktop mode, which itself is a Wayland compositor. The game will be a different compositor created nested within the desktop one. Resulting bug is that the game runs in a weird 800x800 resolution.
- Deck is not exactly the biggest graphics powerhouse and my experience is only the lowest of low graphics is playable. Good thing is the screen is also not the best in the market resolution-wise and that actually does real-world supersampling for your eyes.
- While debugging things people tend to use the desktop mode, which itself is a Wayland compositor. The game will become a different compositor nested within the desktop one. Resulting bug is that the game runs in a weird 800x800 resolution.
This does not happen in 'Game Mode' which does not have a desktop. Games are generated as tier-0 (or -1, depends on where you live) `gamescope` objects or something like that, and takes up the whole screen without much problem.
## Problem I didn't expect and ruined the whole lying in bed plan
Modern online games has mad UDP traffics for various reasons: progress tracking, anti-cheat, hotfix, etc etc. Endfield is a modern online game and it has mad traffics.
## Problem I didn't expect ruining the whole lying in bed plan
Modern online games maintains TCP connections and spams UDP for various reasons: progress tracking, anti-cheat, hotfix, etc etc. Endfield is a modern online game and it has mad traffics.
These connections happen once you finish the de facto single-player tutorial part. Which is why I didn't realise there was a problem while playing through the tutorial on WiFi.
As soon as the mad online checks kick in, I get stuck in a storm of tiny disconnections before eventually timing out or simply getting disconnected. On WiFi. Unable to play the game in any meaningful sense, too.
As soon as the online checks kick in, I get stuck in a storm of tiny disconnections before eventually timing out or simply getting disconnected. On WiFi. Unable to play the game in any meaningful sense, too.
It's so apparently a network problem with a slight probability of being anti-cheat related. So a hunt began.
### Tracking down the culprit
#### the environment
## Tracking down the culprit
### the environment
I'll run you through the house's network setup very quickly:
- Rakuten Hikari Modem (ONU)
- Rakuten Hikari Modem (ONU), IPv4-over-IPv6 on RFC 2333
- FriendlyElec R5C router with OpenWrt
- H3C NX54 WiFi router but used only as WiFi AP
- Several switches for expanding RJ45 port counts
- H3C NX54 WiFi router but used only as WiFi AP
- End devices
The first easy thing to try is simply getting a Type-C dock and plugging in an RJ45 wired Ethernet. And play the game. And the game plays. I actually did this verification way longer than I should, but that's the point: you really can play Arknights: Endfield on a Steam Deck.
### the hunt
As someone with semi-proper training in scientific methodologies, I started with singling out variables. Honestly, it's all about singling out variables and trying to deal with the root cause(s). And singling out variables is always the time-consuming part.
Both the wired and wireless networks in the house aggregates to the same gateway, a FriendlyElec R5C router; but WiFi radio waves are served by another device, a H3C NX54. It doesn't change the picture too much if my R5C has a radio, though.
Generally, I started with the end terminals and progressed towards the house gateway in the network stack.
The first thing to do was to set a benchmark that the game itself being playable. And this was done in various ways, all taking longer than they needed to be:
- Desktop computer connecting to the router via Ethernet (Cat 5e) and two switches. I actually progressed halfway through Valley IV during the process. Apparently it was playable.
- Steam Deck, type-C dock, Ethernet from the same switch the desktop PC directly connects to. Also playable and even did a boss fight under no the most favourable circumstances.
The wired baseline gave me the (kind of) false conclusion that the router and everything from there (the ONU, the ISP trunk, etc) was faultless. So I focused on single-variable comparisons down the WiFi route.
It might seem to some as nonsense if you tell them that WiFi was not exactly the cause, but I maintain that going through many sectors down the WiFi route was worth the labour and very methodologically correct.
#### WiFi stuff to look at
I actually did the troubleshooting across several days due to hardware restrictions. I'll follow the actual timeline, loosely.
The easier things to test was
### a temporary and technically false conclusion and solution
After
### the revelation
Jumping to conclusions, a simple series of binary variable controlling narrows down the source very well. My actual process was way more messy and I would rather not talk about it.
- **heat 1**: wired v. wireless
Wired works, and wireless doesn't. So it's a wireless-only problem.
- **heat 2**: WiFi AP v. WiFi client