steam-deck-wifi: procedural update

blogs/2026-06-27_steam-deck-wifi.md

@@ -0,0 +1,74 @@
+---
+title: Steam Deck's WiFi troubles discovered through doing something it wasn't designed for, part 1
+date: 2026-06-27
+tags:
+  - Steam Deck
+  - Network
+  - Hardware
+wiki:
+  publish: false
+---
+
+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 (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 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 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 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
+I'll run you through the house's network setup very quickly:
+- Rakuten Hikari Modem (ONU), IPv4-over-IPv6 on RFC 2333  
+- FriendlyElec R5C router with OpenWrt  
+- Several switches for expanding RJ45 port counts  
+- H3C NX54 WiFi router but used only as WiFi AP  
+- End devices
+
+### 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.
+
+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
+
+
+
+
+Notes:
+
+WiFi 5 v. WiFi 6 : not the core reason
+