Is it my Wi-Fi or my internet? How to tell

Why one box decides the whole question

Your connection has two halves that fail for completely different reasons. Inside the house: a radio link between each device and an access point, plus the wiring, switches and mesh nodes behind it. Outside: the drop from the pole or pedestal, the run back to a node or an optical line terminal, and everything beyond. One piece of equipment straddles that boundary — the modem, the ONT, or the combined gateway your provider handed you — and its network-facing side is where the physical layer either locks or does not.

That lock is called sync, and it is the first thing to establish because everything else depends on it. A cable modem locks onto downstream carriers and then ranges on the upstream; a fiber ONT receives light and registers; a DSL modem trains the copper pair. Until sync exists, nothing above it can work and no amount of Wi-Fi troubleshooting matters. Once sync exists and pages still fail, the fault has moved up a layer: to provisioning, routing, DNS, or your own network.

This is why the wired test is the control, not just another thing to try. Cabling a computer to the gateway and disabling that computer’s Wi-Fi removes the entire radio path from the experiment: band, interference, distance, mesh backhaul, the client’s own antenna. If the fault survives that, none of those were the cause.

Which band did the device actually join

Before blaming the line for a slow phone, check what the phone is attached to. The Wi-Fi Alliance describes Wi-Fi 6E certification as offering the features and capabilities of Wi-Fi 6 extended to the 6 GHz band, so a modern client may be on 2.4, 5 or 6 GHz, and the bands trade range against capacity: the lower frequency carries further through walls, the higher one carries more data over a shorter distance. A device that roamed onto 2.4 GHz in a back bedroom, or is clinging to a distant mesh node, produces exactly the symptoms people report as “the internet is slow.”

Ping targets are path segments

A ping is not one test: it is a different test for each target, and the targets map onto sections of the path. Your router’s address covers the house only. Your provider’s first hop, which traceroute shows you, adds the drop and the local plant. A public resolver addressed by IP covers the path without name resolution; the same resolver by hostname adds DNS. The first target that fails is roughly where the break is.

Roughly, because ICMP was never designed to carry a verdict. RFC 792 says plainly that the purpose of these control messages is to provide feedback about problems in the communication environment, not to make IP reliable. Nothing in it obliges a router or host to answer an echo request, and equipment on the path is free to deprioritize or ignore ICMP while forwarding ordinary traffic normally. A middle hop showing loss while later hops are clean is a router being economical with its CPU, not a fault. Only loss that persists to the destination counts.

Idle latency and loaded latency are two different measurements

A single speed number cannot tell a radio fault from a saturated line: both can produce a respectable number. The FCC measures idle latency — sampled only when no other traffic is detected in or out of the home, at 2,000 UDP packets an hour — separately from latency under load, sampled at 10 packets a second during the ten-second download and upload runs. In the data behind its Thirteenth Measuring Broadband America report, collected in September and October 2022, median idle latency was lowest on fiber (7–14 ms), higher on cable (12–24 ms) and highest on DSL (23–34 ms), and latency under downstream load was generally significantly higher than idle latency, with a more pronounced difference for DSL subscribers.

The mechanism is bufferbloat: oversized queues at the bottleneck fill under load and every packet behind them waits. RFC 8290 describes FQ-CoDel as a tool for fighting bufferbloat and reducing latency by keeping queue lengths short, preferentially dropping packets that remain in the queue too long, and isolating low-rate traffic such as DNS, web and videoconferencing. That is why a connection can measure fast and still fail a video call.

Cloudflare grades the same gap numerically: in its Aggregated Internet Measurement rubric the difference between loaded and unloaded latency scores 20 points under 10 ms, 10 under 20 ms, 5 under 50 ms and zero above 50 ms, and its video-call score is built from packet loss, jitter, unloaded latency and that difference. Those thresholds give you the decision rule. A large loaded delta measured wired means queueing at the last mile or in your gateway’s upstream buffer. A large delta that appears only over Wi-Fi, with the wired test clean, means the radio. Turning those four numbers into a per-application verdict is its own exercise, covered in latency, jitter and packet loss.

Packet loss finishes the picture. The FCC bands its packet-loss results at up to 0.4%, 0.4–1% and over 1%, and treats the 1% mark as the commonly accepted point at which highly interactive applications such as VoIP degrade significantly. Sustained loss above 1% on a wired test is a line fault; the same loss over Wi-Fi with a clean wired result is a radio fault.

What each test actually rules out

The order to work in

Each step is ordered by likelihood × cost to check, and the ones that produce evidence come before the reboot that destroys it.

1. Establish the scope. One device misbehaving while everything else is fine is that device or its radio. Everything failing at once is the router, the gateway or the line. Thirty seconds, and it eliminates half the possibilities.
2. Write down the lights and the uptime before you touch anything. Note which indicators are lit on the modem or ONT, and if the box exposes a status page, record the uptime counter and copy the event log. A reboot resets both, and support will ask you to reboot before it does anything else.
3. Run the wired control test. Ethernet from the gateway to a computer, Wi-Fi off on that computer, then retest what was failing. Check the link rate the operating system reports on that adapter before trusting any speed number.
4. Measure idle and loaded latency separately, wired first. Ping a stable target with nothing else running, then again during a sustained download and a sustained upload. Repeat over Wi-Fi. You are comparing four numbers, not one.
5. Walk the path. Traceroute to any public host, then ping in order: your router, your provider’s first hop, a public resolver by IP, and finally a hostname. If only the hostname fails, it is DNS and the line is fine.
6. Read the modem’s own numbers. On cable, this is the readout that settles arguments.

Reading the modem, and what 192.168.100.1 really is

The convention that a cable modem answers on 192.168.100.1 with a diagnostic page is exactly that — a convention. The CableLabs specification governing the modem-to-equipment interface says only that read-only diagnostic interfaces provide debugging, trouble-shooting and status information to users, and that a modem MAY have them; a separate clause states that the document does not mandate any specific number or type of modem interface. A modem that does not answer is not broken, and an ISP gateway may put the same readout behind its router interface.

The page is also read-only by design; the same specification requires that a modem must not allow access to modem functions through a management access interface, so you cannot damage anything by opening it, and you cannot fix a line fault from it either. When it does exist, it is the only consumer-visible physical-layer evidence you have: downstream and upstream power, signal-to-noise ratio, uncorrectable codewords, the uptime counter, and the event log.

The uptime counter is the single most useful number on the page: it tells you whether the modem has been silently resetting between the outages you noticed. The event log is the proof. On DOCSIS networks a T3 timeout (event code R03.0) means the modem sent sixteen ranging requests and got no ranging response back, typically from upstream noise, insufficient modem transmit power, or lost MAC-layer messages. A T4 (R04.0) means no station-maintenance opportunity arrived within 30–35 seconds. A T2 (R01.0) means roughly ten seconds with no broadcast maintenance opportunity, and a T1 (U01.0) means no periodic upstream channel descriptor from the head end at all. Every one is a physical-layer failure between your modem and the network — not a Wi-Fi problem, and not fixable from inside your house.

Fiber has no DOCSIS-style standard for that readout, and what an ONT or fiber gateway exposes varies by manufacturer and provider. Often all you get is indicators: a power light and an optical or PON light whose labels and colors differ between units, so the card or sticker on yours is the authority. If the ONT is not receiving light, nothing above it means anything — that is a line call, immediately.

What to say when you call

Lead with evidence, not symptoms. “My modem uptime is under an hour, the event log shows T3 timeouts at 7:12, 7:19 and 7:44 this morning, and on a wired connection I am seeing 2% packet loss with ping rising from 18 ms idle to 140 ms under load.” That names the layer, supplies timestamps, and closes off the two things a first-line script would otherwise spend twenty minutes on.

What this page cannot tell you

It cannot tell you where outside your house the fault is. A failed wired test plus T3 timeouts proves the problem is at or beyond the drop, but a corroded connector, a neighborhood node and a regional outage look identical from your side. That distinction needs the provider’s own network view.

It also cannot settle a speed complaint. If everything here comes back healthy — sync solid, wired test clean, latency normal idle and under load, loss under 0.4% — and you are simply not getting the number on your bill, that is a provisioning and measurement question rather than a fault, and it is covered in not getting the speed I pay for. If browsing works but incoming connections, game hosting or remote access do not, nothing above will find it, because the cause is usually carrier-grade NAT rather than a fault at all.

And ICMP results stay hints. Because nothing obliges a device to answer an echo request, the path walk narrows the search; the wired test, the latency pair and the event log carry the weight.