Home network diagnostics needs a standard. And a body to maintain it.

I’ve spent the last year building Network Weather, a Mac app that tries to tell people in plain English why their home network is acting weird. To do that well, I’ve had to tear apart about twenty consumer gateways and mesh systems — Netgear, TP-Link, Google Nest, Eero, Starlink, UniFi, AT&T and Xfinity ISP boxes, and a long tail of others. What I’ve found is consistent across every single one:

The firmware already gathers the telemetry you’d want. The vendor doesn’t expose it. And no standards body is working on fixing that.

I want to propose we fix it anyway.

The gap, briefly

On a modern mesh router, the firmware is continuously computing exactly the signals a good diagnostic tool needs: per-interface CRC errors, per-client WiFi signal in dBm, per-band backhaul link rate, rolling backhaul quality evaluations, airtime consumption, noise floor, DFS events. All of it is happening in silicon twenty feet from you. Almost none of it reaches the router’s web UI, and essentially none of it is available through any standardized local API.

UPnP IGD is the closest thing we have to a cross-vendor diagnostic protocol. It was standardized in 2001 and last meaningfully updated in 2010. The UPnP Forum merged into the Open Connectivity Foundation in 2016 and has been dormant on gateway-device work ever since. Even when UPnP IGD is implemented well on a given router, the protocol doesn’t cover error counters, WiFi statistics, mesh topology, or any of the real physical-layer health data that answers “why does my Zoom call glitch.” It also doesn’t compose — a gateway’s UPnP can tell you about the gateway, but not about the upstream cable modem or fiber ONT. If you want to know whether your ISP’s problem is actually their problem, you’re on your own, device by device, HTML-scraping your way through a 2010-era admin page.

Every home network failure mode I encounter ultimately comes back to this gap. A staple through a Cat6 cable run under my house caused weeks of subtle glitchiness before I tracked it down — the kernel saw the CRC errors the whole time, and no tool I could point at the router would tell me. Microwaves that degrade mesh backhaul quality between 12:30 and 1:00pm. A new neighbor’s access point lifting the noise floor on the only channel your living room can reach. All diagnosable by the firmware, none diagnosable by the user.

The proposal

We need two things that don’t exist today:

A minimum diagnostic surface, specified as a standard. A lightweight, read-only JSON API any router could expose over its LAN. Discoverable via SSDP or mDNS. Covers per-interface error counters, per-client WiFi signal in dBm, mesh topology with parent/child relationships, channel utilization and noise floor, backhaul link health, and a pointer (where relevant) to the upstream modem’s equivalent surface. References existing standards where they already fit — IF-MIB for interface stats, TWAMP Light (RFC 5357) for hop-by-hop active measurement — and defines new structure only where it needs to.

A standards body willing to maintain it. The UPnP Forum is gone. The Broadband Forum does TR-069 and TR-369 USP for ISP-to-CPE management, but their charter doesn’t extend to end-user diagnostic visibility. The Wi-Fi Alliance is certification-focused, conservative, and expensive. OCF inherited UPnP but has shown no interest in evolving IGD. IETF could host a working group but moves slowly. CableLabs owns DOCSIS but only for cable. Nothing sits in the middle owning cross-vendor, cross-medium, end-user-readable home network diagnostics.

I don’t think the right first move is to form a new legal entity. The right first move is to publish a v0.1 draft of the spec, publish a reference implementation that a Raspberry Pi or any OpenWrt-capable device can run in an afternoon, and invite people to tear it apart. If the draft lands well, the body forms around it. If the body needs a home, the Linux Foundation’s Joint Development Foundation is designed for exactly this sequence.

What makes this plausible

Two things have to be true for a standard like this to actually ship on real devices:

A chipset vendor has to carry the reference implementation. Qualcomm, Broadcom, and MediaTek ship reference firmware that most consumer routers are built on. A minimum diagnostic surface baked into reference firmware is a standard that propagates essentially for free. Without at least one of those three companies in the conversation, a standard is theoretical. Qualcomm is the most logical first target given how much of the current mesh category runs on their IPQ chipsets.

A regulatory tailwind needs to exist. The FCC’s Cyber Trust Mark program is already asking vendors to commit to security update windows and publish end-of-support dates. Extending the Mark’s criteria to include a minimum diagnostic-exposure requirement would give the standard real market force, and would give enterprise security teams an auditable posture signal for the millions of home networks their employees work from. This is a policy moment that didn’t exist three years ago.

Invitation

If you work in consumer network chipsets (Qualcomm, Broadcom, MediaTek, Realtek), at a router or mesh vendor (Netgear, TP-Link, ASUS, Eero, Ubiquiti, and yes, even the vendors I’ve been less kind to), at an ISP that cares about reducing support cost, at a regulator thinking about Cyber Trust Mark extensibility, or at any research lab or consumer-advocacy organization working this problem — I’d like to talk.

I’ll be publishing the v0.1 draft spec, the gap analysis that informed it, and a reference implementation over the next few weeks. The goal is to make the conversation easy: read the draft, find what’s wrong with it, tell me. If a handful of us converge on a shared schema that Qualcomm or Broadcom will put into reference firmware, we change the category.

Reach out: [email protected]. I’ll post updates here and at networkweather.com.