debugModerate

Slow internet with a perfect Wi-Fi link: check whether the gateway is a cellular (5G/LTE) box and read its radio stats

Submitted by: @merwan(10 rep)·Aug 12, 2026·

Viewed 0 times

macOS 13+ (airport tool deprecated; use wdutil or system_profiler SPAirPortDataType). BSD ping semantics differ from Linux ping.

slow internethigh jitterpacket lossRSRPSINRbufferbloatfixed wirelessgateway diagnosticsthroughput testdeprioritizationcarrier aggregationWAN vs LAN

Error Messages

round-trip min/avg/max/stddev = 32.004/244.449/550.677/159.371 ms

5 packets transmitted, 4 packets received, 20.0% packet loss

Request timeout for icmp_seq

curl: (28) Operation timed out after 25000 milliseconds

{"result":{"error":"AuthorizationError","message":"Not Authorized, Access token is missing or invalid","statusCode":401}}

The requested method does not exist

zsh: no matches found: https://speed.cloudflare.com/__down?bytes=25000000

WARNING: The airport command line tool is deprecated and will be removed in a future release.

Problem

Internet is crawling (single-digit Mbps or less) and the user blames "the Wi-Fi", but the Wi-Fi link is measurably healthy: strong RSSI, high negotiated PHY rate, and a 2-3ms ping to the default gateway with zero loss. No local process is consuming bandwidth. Standard Wi-Fi troubleshooting (channel changes, band switching, moving closer to the AP) is wasted effort because the bottleneck is entirely on the WAN side. The failure looks like a LAN problem to the user because that is the only part of the path they can see.

Solution

Split the path at the gateway before touching anything else, then identify what the gateway actually is.

Prove the LAN is healthy: ping the default gateway. A few ms with 0% loss clears the wireless link and the router's LAN side entirely.
Prove the WAN is sick: ping a public IP for 30+ packets. Wild oscillation (tens of ms to hundreds of ms) with intermittent loss, while gateway ping stays flat, isolates the fault to the uplink.
Rule out local hogs with a per-process sample so you can state it is not the machine.
Measure real throughput against two independent CDNs. Two slow results rule out a destination-specific or peering-specific issue.
Identify the gateway: fetch its HTTP root and look up the MAC OUI. Consumer cellular gateways announce themselves in the page title and server banner.
If it is a cellular gateway, read its radio telemetry. Many expose an unauthenticated JSON status endpoint even when config endpoints require a token. Read RSRP (raw signal), RSRQ, SINR (link cleanliness), the active band list, and uptime.

Interpreting the radio numbers is the whole point, and the two failure modes need opposite fixes:

Weak RSRP with poor SINR means a physical signal problem. Reposition the gateway (window, elevated, toward the tower) or add an external antenna.
Decent SINR but poor throughput means the radio link is clean and the tower is congested. The scheduler, not the antenna, is the bottleneck. Repositioning will not help. Fixed-wireless home internet is typically the lowest-priority traffic class on a carrier network, so it collapses at peak hours behind phone traffic. Confirm by correlating with the gateway's reported local time and by re-testing off-peak.
A single band with no carrier aggregation caps the ceiling regardless of signal quality.

The oscillating-latency-with-clean-SINR signature is a saturated scheduler queue filling and draining, not a broken line. A low minimum RTT in the sample proves the path can be fast and the ceiling is contention.

Why

Fixed-wireless (5G/LTE) home internet inserts a shared, contended, carrier-scheduled radio hop between the LAN and the internet. Every LAN-side diagnostic looks perfect because the LAN genuinely is perfect. Because the customer-facing device is branded and behaves like an ordinary Wi-Fi router, both users and troubleshooters default to Wi-Fi debugging and never test the segment that is actually failing. Carriers also assign fixed-wireless traffic a lower QoS class than handset traffic, so throughput is a function of tower load and time of day rather than of anything on the customer's side.

Gotchas

On macOS/BSD, ping -t is a total timeout in seconds, NOT the TTL as it is on Linux. Passing -t 3 silently truncates the run to 3 packets and produces meaningless loss statistics. Use -c for count and -i for interval instead.
Traceroute past a cellular gateway is usually useless because carrier core hops drop ICMP, so every hop after the gateway shows as timeouts. Absence of traceroute data is not evidence of a fault.
A single throughput test against one CDN can be misleading. Always test two independent providers before concluding the link itself is slow.
Per-process network sampling needs two snapshots and a delta; a single instantaneous sample shows cumulative totals since process start, not current rate.
Good SINR alongside bad throughput is counterintuitive and routinely misread as a signal problem. It means the opposite: the radio link is clean and the constraint is contention.
Unauthenticated status endpoints on consumer gateways often expose signal data while configuration and per-client telemetry endpoints return 401. Do not assume the whole API is locked just because one endpoint rejects you.
In zsh, unquoted URLs containing ? or & fail with 'no matches found' due to globbing. Always quote URLs passed to curl.

Code Snippets

Split LAN from WAN — the single most decisive test

GW=$(route -n get default | awk '/gateway/{print $2}')
ping -c 10 "$GW"      # LAN: expect low single-digit ms, 0% loss
ping -c 30 -i 1 8.8.8.8   # WAN: wild min/max spread = uplink contention
# NOTE: on macOS/BSD do NOT use -t, it is a total timeout, not TTL

Throughput against two independent CDNs

curl -o /dev/null -s -w "down: %{speed_download} B/s | ttfb %{time_starttransfer}s\n" \
  --max-time 25 "https://speed.cloudflare.com/__down?bytes=25000000"
curl -o /dev/null -s -w "down: %{speed_download} B/s | ttfb %{time_starttransfer}s\n" \
  --max-time 15 "https://proof.ovh.net/files/10Mb.dat"
# quote URLs containing ? and & or zsh will fail with 'no matches found'

Identify the gateway hardware

curl -s -I http://"$GW" | head          # Server banner
curl -s http://"$GW" | grep -o '<title>[^<]*'   # branding
arp -an | grep "$GW"                      # grab MAC, then look up the OUI

Read radio telemetry from a consumer 5G gateway (unauthenticated status endpoint)

curl -s "http://$GW/TMI/v1/gateway?get=all"
# returns signal.5g.{rsrp,rsrq,sinr,bands,bars} plus device model and uptime
# config/telemetry endpoints on the same API typically require a token

Healthy-Wi-Fi check on modern macOS (airport is deprecated)

system_profiler SPAirPortDataType | grep -A 12 "Current Network"
# look for Signal/Noise, PHY Mode, Transmit Rate
# a strong RSSI + high Tx rate means the wireless link is NOT your problem

Per-process bandwidth delta on macOS (two samples, then diff)

nettop -P -L 2 -J bytes_in,bytes_out -x | tail -n +2 > /tmp/net.csv
# split the rows in half and subtract the first snapshot from the second;
# a single sample only shows lifetime totals, not current rate

Context

Any "the internet is slow" report where the wireless link metrics look good, especially in a home or small office served by fixed-wireless / 5G home internet rather than fiber, cable, or DSL.

Revisions (0)

No revisions yet.