What your router knows but won't tell you - David E. Weekly<br>Skip to main content A while back my home network started acting strange. Not broken, exactly. Just a low-grade wrongness. Video calls would glitch for a few seconds and come back. Large file uploads would stall and resume. Speed tests mostly looked fine. Occasional ones didn’t. Every tool I pointed at the problem said “looks ok to me.”

The cable was a Cat6 run under the house. Terminated cleanly. Passed a basic continuity test. Looked for all the world like a working cable. It was, in the way that a tire with a slow leak is a working tire — every push of the pedal got you forward, until at some point it didn’t.

What the cable actually was, I found out later, was partially bitten through by a staple somewhere under the floor joists. The jacket had been compromised enough to let in just enough moisture to degrade the pairs, just enough, just sometimes. The physical layer was fine most of the time. When it wasn’t, the Ethernet frames came out garbled, failed their Frame Check Sequence, and the receiving NIC dropped them on the floor — incrementing a counter called rx_crc_errors in /sys/class/net/eth0/statistics/. Standard Ethernet has no retransmission at L2; it’s best-effort delivery. For my TCP traffic, the sender eventually noticed the missing acks and retransmitted higher up the stack. For UDP — which is most real-time video and voice — the frames were just gone, permanently, which is exactly what the video-call glitches actually were. From my laptop’s perspective: a little extra latency on downloads, a little weirdness on calls, mostly fine.

From the router’s perspective: an integer in a kernel data structure was climbing faster than it should be. The router knew. The router knew exactly. The router’s vendor never shipped a way to tell me.

That’s the story I want to unpack, because it’s not just about me and my cable. This is the shape of almost every home network problem I’ve tried to diagnose in the last year of building a diagnostic tool. The firmware already knows. It doesn’t tell.

The funnel

Here’s what I mean, concretely. I’ve spent the last several months tearing apart about twenty consumer gateways, mesh systems, and cable modems — Netgear Orbi, TP-Link Deco, Google Nest WiFi, Eero, Starlink, UniFi, AT&T and Xfinity ISP boxes, and a long tail of others. The pattern is identical across every single one:

The firmware measures a lot. On a Netgear Orbi WiFi 7 system, the mesh self-organizing daemon (ezmesh) sends path-quality probe packets every single second between every mesh node pair for its own steering decisions. A separate daemon (repacd) runs rolling 30-minute and 2-hour evaluation windows on the backhaul link quality. The radio driver (ath11k) tracks per-VAP CRC errors, retry percentages, airtime consumption, and noise floor. All of this is happening in the firmware right now, in your living room, continuously.

Root-on-the-box gets less. If you jailbreak or SSH into the device, you can read some but not all of it. On the satellite mesh nodes, you get satellite_status, hop_count, partial wireless info — but the ACL on the file read method explicitly denies reading /sys/class/net/ath*/statistics/. The error counters are there, on the device, exposed to the kernel’s VFS. The management daemon won’t let you read them.

The web UI gets even less. The one page on Orbi that shows any per-interface statistics at all (RST_stattbl.htm) displays TX and RX packet counts plus collisions. No error subtypes. No retry percentages. No per-client signal in dBm — just a 0-to-100 “quality bar” that compresses the actual data (dBm signal strength, SNR, PHY rate) into a single vibes-based integer.

The SOAP API gets a subset of the web UI. The vendor’s own SOAP interface returns client signal as 0-100, satellite signal as 0-100, WAN bytes as a 32-bit counter that overflows at 4 GB.

Any unauthenticated standard API gets a subset of that. UPnP IGD, which is the closest thing we have to a cross-vendor diagnostic protocol, exposes WAN IP, WAN status, WAN uptime, and aggregate byte counters. That’s it.

Five layers. Roughly a 10× compression from the top to the bottom. And that’s on Orbi, which is comparatively open — the direction of travel across the industry is toward less exposure, not more. Between Orbi firmware versions V10.5.10.10 and V10.5.19.5, several of the ubus endpoints I was relying on for satellite telemetry got ACL-denied in the newer build.

Why this happens

Not because exposing it is hard. Exposing the rx_crc_errors counter from sysfs is a few lines of code. The routers already run HTTP servers. Everything from the kernel to the admin web page is sitting on one small Linux or OpenWrt-derived device; nothing is physically far from anything.

It happens because no vendor has a commercial incentive to expose it, and no standard forces them to. Every vendor independently decides how much to surface, and most choose the minimum that...