Is It My Wi-Fi or My Internet: A 20-Minute Diagnosis

Run the cable first. Nothing you measure separates a Wi-Fi problem from a line problem until one reading exists with the wireless leg taken out of the picture, and this whole diagnosis is built around that one reading.

So: before any speed test, before the router reboot, before the call, find an Ethernet cable, plug a laptop straight into a LAN port on the gateway, and turn that laptop's Wi-Fi radio off. Everything below depends on having one measurement that no wireless problem could have touched. Without it you are guessing, and so is the person on the support line, which is how three appointments get burned on a problem that lives in the kitchen.

Budget twenty minutes: four for the wired control, three for pings, four for the path, four for the busy-line test, three for the modem's own page, two to write the result down.

The wired control is the whole diagnosis in miniature

With the cable in place, reproduce the thing that fails. Join the meeting that stutters. Or, if it only misbehaves at certain hours, run the measurements below and save them.

Clean wired, broken wireless: the fault is inside your house, and the provider cannot fix it. Equal misery on both: the fault is at or past the gateway, and now you have a case worth building.

Three ways the control gets ruined: a powerline adapter or MoCA bridge, which is a different in-home transport with its own failure modes; a laptop that still has its Wi-Fi enabled, because the operating system will happily keep traffic on it; and a cable run through a switch in another room, which puts that switch in the test.

Keep expectations honest while you are here. Microsoft's Teams bandwidth table puts one-to-one video at a recommended 1,500 kbps each way and plain audio at 58 kbps. Nothing that follows is about bandwidth. A 400 Mbps line drops calls for reasons no speed test reports.

Ping your own gateway before you ping anything else

Find the gateway address: ipconfig on Windows, netstat -nr | grep default on macOS, ip route on Linux. It is usually 192.168.1.1 or 192.168.0.1.

Then send a hundred packets, not four.

ping -n 100 192.168.1.1        (Windows)
ping -c 100 192.168.1.1        (macOS, Linux)

This single command splits the house from the line, because nothing between your laptop and your own router belongs to the provider. Run it twice: once over Wi-Fi from the chair where calls fail, once over the cable.

Any loss at all over Wi-Fi, or a max time twenty times the average, is a wireless finding. A clean wired run to the same box confirms it. Loss on the wired run to your own gateway is rarer and points at a cable, a port, or a network adapter — swap the patch cable and the port before accusing anyone.

Now repeat the same hundred packets against a stable public address such as 1.1.1.1 or 8.8.8.8. On Linux the summary line ends with mdev, the mean deviation; macOS calls the same column stddev. Either is close enough to jitter for triage. Windows ping reports no deviation at all, so read the gap between minimum and maximum, or use one of the tools further down.

The first hop past your house is where responsibility changes hands

Map the path:

tracert -d 1.1.1.1             (Windows)
traceroute 1.1.1.1             (macOS, Linux)
mtr -rwc 100 1.1.1.1           (macOS, Linux — 100 cycles, report mode)
pathping -q 50 1.1.1.1         (Windows — per-hop loss, slow)

Hop one is your gateway. Hop two is normally the provider's access equipment — the CMTS port, the OLT, the DSLAM, the fixed wireless sector. Everything from hop three outward is transit that neither you nor your provider's front line controls.

Here is the misreading that sends people into support calls with the wrong story, and it is the most common error in this whole procedure: a middle hop showing 30 or 40 percent loss in mtr almost never means 30 percent loss. Routers answer traceroute probes as the lowest-priority chore they have, and many rate-limit or ignore those replies entirely while forwarding your real packets untouched. Loss at hop four that vanishes by hop twelve is an artifact of the measurement. Only loss that appears at a hop and persists through every hop after it, all the way to the destination, is loss. If that pattern starts at hop two, the finding is line-side and you can say so precisely.

A hundred packets, and the thresholds that mean something

Numbers need somewhere to land. Two published sets are worth borrowing.

Microsoft's network performance table for Teams media rates a connection optimal at round-trip time under 60 ms, average packet loss under 0.5 percent, maximum packet loss under 5 percent and jitter under 3 ms, and poor past 500 ms, 10 percent, 25 percent and 30 ms.

Know what you are holding there. That table sits in Microsoft's previous-versions archive under a Skype for Business Online heading, the page carries a retired-and-archived flag, and its content date is 28 November 2017. The current Teams documentation publishes bandwidth numbers and no successor to the loss-and-jitter table. These are the last thresholds the vendor put in writing for real-time media, which makes them a good thing to aim at and a poor thing to quote at a support agent as a standard someone owes you.

The FCC's Thirteenth Measuring Broadband America report — published in 2023 on measurements taken across thirty days in September and October 2022 — bands consumer packet loss at up to 0.4 percent, 0.4 to 1 percent, and over 1 percent, explaining that "the 1% standard for packet loss is commonly accepted as the point at which highly interactive applications such as VoIP experience significant degradation in quality." Its measured idle latencies ran 7 to 14 ms for fiber ISPs, 12 to 24 ms for cable and 23 to 34 ms for DSL.

Those measurements are four years old now, and the report itself notes that some ISPs introduced active queue management after the testing window closed. Read the bands as the shape of the thing rather than as this year's numbers. Their use is comparative: if your wired idle round-trip time to a nearby target is triple the band for your technology, that is a number worth keeping.

Two loss events in a hundred packets is 2 percent, and 2 percent is enough to shred a call while leaving a speed test looking perfect.

The number that only shows up when the line is busy

Idle latency is the easy case. The one that ruins calls is latency measured while something is saturating the connection — a cloud backup, a game update, someone upstairs uploading video.

The FCC measures exactly this. Its working latency test runs during the ten-second speed test at ten packets per second, and the Thirteenth Report's finding is blunt: "the latency under downstream traffic load generally is significantly higher than idle latency, with a more pronounced difference for DSL subscribers."

Do it yourself in four minutes. Start a large upload or download and, while it runs, send another hundred pings to the target you used before. A jump from 18 ms idle to 400 ms loaded is bufferbloat: a fat queue at the edge of your link holding packets rather than dropping them. The loaded-latency tests at speed.cloudflare.com and Waveform's bufferbloat test report both figures side by side — run them from the wired laptop.

Bufferbloat is usually not a broken line. It is a queue, most often in your own router's upstream buffer, and smart queue management on a router that supports it flattens the graph without a phone call. It is also the one result here most likely to be escalated to a provider that can do nothing about it, so test it, note it, and check your own equipment first.

What the modem's own status page settles

Most cable modems answer at 192.168.100.1 even when they are in bridge mode behind a router. Nothing assigns that address — it is a vendor convention that has held for two decades, not a requirement — so if the page does not load, read the label on the unit or the manual before concluding the modem is unreachable. Fiber ONTs and DSL gateways vary more, and a few expose no status page to the LAN at all.

On a DOCSIS modem, read the downstream power per channel, the signal-to-noise or MER figure, and the correctable and uncorrectable codeword counters. The reference figures a cable technician works to come from CableLabs' DOCSIS 3.1 Physical Layer Specification, document CM-SP-PHYv3.1: a downstream input level range equivalent to −15 dBmV to +15 dBmV per 6 MHz channel, and 33 dB Es/No as the reference condition for demodulating 256-QAM. Two cautions before leaning on them. CableLabs reissues that specification and distributes it through its own specification library rather than at a fixed public address, so the issue your operator works to may not be the one those figures were quoted from. And a modem sitting inside the range can still be failing while one a decibel outside it runs fine. Readings hard against either edge are worth a screenshot, not a verdict.

The counters are better evidence than the levels, because they carry their own clock. Screenshot the page, wait fifteen minutes of ordinary use, screenshot it again. Correctables climbing is normal. Uncorrectable codewords climbing by thousands in a quarter hour, with timestamps to prove the interval, is a line finding a technician cannot argue with. On DSL the equivalents are the sync rate, the CRC error count and the resync log; on fiber, optical receive power in dBm and any loss-of-signal alarms.

Which page you are even reading depends on what physically serves the building, which is not always what the account says — what is really available at your address covers how to establish that.

Wi-Fi failures that leave a fingerprint

Some wireless faults identify themselves so specifically that you can stop testing.

If the whole network vanishes for about a minute in the middle of a call, comes back, and does not return to the same channel for at least half an hour, that is dynamic frequency selection. Under 47 CFR 15.407(h), whose eCFR text was read on 21 August 2026, devices in the 5.25–5.35 GHz and 5.47–5.725 GHz bands must watch for radar; on detection, all transmissions must cease on that channel within 10 seconds, a new channel requires a 60-second availability check before use, and the flagged channel is subject to "a non-occupancy period of at least 30 minutes." Live near an airport or a weather radar and your access point will do this on its own schedule forever. Pin the router to a non-DFS channel and the symptom disappears. Your line was never involved.

The other everyday one is the 2.4 GHz band, which offers three non-overlapping 20 MHz channels in the United States — 1, 6 and 11 — shared with every neighbor, every microwave oven and a pile of smart plugs. Check what the client actually negotiated rather than what the bars suggest. netsh wlan show interfaces on Windows prints the radio type, channel, signal percentage and receive/transmit rate. On macOS the airport utility that used to print the same thing is deprecated, and recent versions answer with a warning pointing at its replacement: sudo wdutil info, which reports RSSI, noise, channel, PHY mode and transmit rate. On current releases some identifiers, SSID and BSSID among them, come back redacted; none of the numbers you need here are among them. Compare the transmit rate standing next to the router with the rate in the room where calls fail. An order-of-magnitude drop is a coverage answer, and link rate is not throughput in either place.

Run the whole thing again at 8 p.m. on a Tuesday

One clean set of measurements at 2 p.m. proves little, because the failure mode you are chasing may be congestion. The FCC defines its peak usage period as "weeknights between 7:00 p.m. to 11:00 p.m. local time at the subscriber's location," and reports against that window precisely because it shows what users get when local demand is highest. Adopt the same definition. Run the wired hundred-packet test, the loaded-latency test and the modem counter check once in the early afternoon and once between 7 and 11 on a weeknight.

Loss and latency that appear only in that window, on the wired control, with the modem's error counters flat, is congestion on a shared segment. It is also the finding that a single mid-morning technician visit will never reproduce, which is exactly why the timestamps matter more than the raw numbers.

Save each run as a plain text file named with the date, the time and the method: 2026-08-21_2015_wired_ping100_1.1.1.1.txt. Keep wired and Wi-Fi runs in separate files so nobody can blame the wireless leg for a wired result. Then pull your provider's broadband label, which under 47 CFR 8.1(a) (read 21 August 2026) must appear at the point of sale and in your online account portal. The FCC's order adopting the label requires providers "to display their typical latency for that particular speed tier, either based on MBA methodology or other relevant testing data." That published figure is the baseline your numbers are deviating from, written by the company you are about to call.

Where the file goes when the answer is the line

You now have either a house problem, which is yours to fix, or a stack of timestamped files that say otherwise. If it is the line, the order of moves is narrow.

Open a ticket in writing rather than by phone, and attach the wired results specifically — say the words "wired directly to the gateway with Wi-Fi disabled," because the first thing any script does is blame the wireless. Ask for two things: a signal-level check at the tap or pedestal, and the maintenance history for your node or sector across the period your logs cover. Get a ticket number before the session ends. If a technician visit is booked, the appointment rules are the ones that govern an install date during a move, including the cable rule against cancelling after the close of business the day before — the move timeline post has the citation.

If two visits change nothing, the measurements stop being a repair request and become a billing argument: you are paying for a service that does not deliver what its own label says. That is a written dispute with a deadline attached, and the escalation ladder for a billing charge sets out the rungs, the clocks and the record that survives them.

Tonight, between 7 and 11, run the wired hundred-packet test twice and the loaded-latency test once, and save all three files with the timestamp in the name. Do the same thing tomorrow afternoon. Four files, two days, and the argument writes itself.