Slow internet on GLiNet router

Hi - Just happened again 10:40-10:42

Update: Flint 3 slowdowns captured on Ethernet and Wi-Fi

My GL.iNet GL-BE9300 / Flint 3, firmware 4.9.0, uses a Spectrum-supplied modem. Severe slowdowns occur once or twice a day, then clear. Between episodes, the Mac has measured around 1.1 Gbps.

Investigation window: September 21, 2026, 11:27–11:34 am EDT (UTC−4), especially 11:29–11:34. Both an Ethernet-connected Home Assistant box and a Wi-Fi Mac lost internet replies while their local router checks stayed clear.

• 11:27:03: First recorded internet loss, then a clean reading.
• 11:29–11:33: Repeated internet loss. Wired checks peaked at 4/5 replies lost to Cloudflare and 3/5 to Google, in separate batches. Local router loss stayed at 0%.
• 11:32:51–11:33:03: A wired 128 KiB download timed out after 12 seconds, with only 15,104 bytes received.
• 11:34:20: A wired download completed in 0.194 seconds. Service recovered without a reboot or settings change; later tests still caught isolated missed replies.

What should I capture next to separate the Flint 3's WAN side from the modem or Spectrum? Wi-Fi alone cannot explain this event. The router is not ruled out: its CPU, traffic and link checks started at 11:33:54, after the worst part. Modem signal and event logs are still missing.

All times below are September 21, EDT.

Ping results

The continuous wired monitor recorded Google loss of 3/5 at 11:29:40 and Cloudflare loss of 4/5 at 11:31:27. These are five-ping batch peaks, not whole-event averages. Cloudflare returned to 0% at 11:32:58; Google still showed loss at 11:33:32, then 0% at 11:33:46. Router loss stayed at 0% throughout the exported window.

Independent checks below show lost replies / probes sent:

| Source / time | Router | Cloudflare | Google |
| --- | ---: | ---: | ---: |
| Wired box, starting 11:31:36 | 0/12 | 5/12 | 2/12 |
| Wi-Fi Mac, 11:31:40–11:33:11 | 0/91 | 9/74 | 13/64 |
| Wi-Fi Mac, 11:33:54–11:34:56 | 0/61 | 0/60 | 0/60 |
| Router itself, 11:33:54–11:34:56 | — | 0/58 | 1/58 |
| Wired box, 11:34:20–11:35:20 | 0/60 | 1/60 | 0/60 |

During the bad period, wired router replies averaged 0.658 ms; Mac router replies were 2.5–7.6 ms. Failed probes took longer, so probe totals differ. The later isolated misses do not show that the severe slowdown continued.

Small HTTPS downloads

Each test requested 131,072 bytes (128 KiB):

| Start time / source | Result |
| --- | --- |
| 11:17:35 / HA Core | Complete in 0.174 s |
| 11:30:45 / HA Core | Failed; detailed error not retained in CSV |
| 11:31:05 / HA Core | Complete in 2.518 s |
| 11:31:40 / Mac | Complete in 8.397 s |
| 11:32:51 / HA Core | Timeout at 12.001 s; 15,104 bytes received |
| Capture starting 11:33:54 / router and Mac | Complete in 0.778 s / 0.117 s |
| 11:34:20 / wired SSH app | Complete in 0.194 s |

For the wired timeout, cumulative curl timings were: DNS 0.002 s, TCP 0.025 s, TLS 3.964 s, first byte 4.770 s, timeout 12.001 s (curl error 28).

On the Mac's slow download, the first byte arrived at 0.320 s, but the whole request took 8.397 s.

Router checks after the worst period

Router SSH had expired; capture resumed at 11:33:54. At 11:33:55, the modem-facing link was 2.5 Gbps full duplex, interface/drop/CRC error counters were zero, CPU was 59% idle with a diagnostic download running, and the connection table had 3,438 entries.

Later sampled WAN traffic peaked at 6.67 Mbps down / 13.11 Mbps up (interval averages). This cannot rule out a load spike during the earlier fault.

Router-to-Spectrum first-hop pings received 45/45 replies, averaging 13.452 ms, during 11:33:55–11:34:39. This was after the worst period and before the later router-to-Google miss, so it does not locate the fault.

The modem status address 192.168.100.1 did not respond; signal levels and DOCSIS event logs remain unavailable.

How I captured it

An Ethernet-connected Home Assistant Green runs the built-in Ping integration against the router (192.168.8.1), Cloudflare (1.1.1.1) and Google (8.8.8.8). It sends five pings per batch, with updates requested every 10 seconds; results normally arrive about every 15 seconds. It records connectivity, reply times and loss, even while the Mac sleeps. Exported CSV rows are state changes, not every batch.

A manual button uses IPv4 curl to request https://speed.cloudflare.com/__down?bytes=131072, with a 5-second connection limit, 12-second total limit and 128 KiB body cap. It saves bytes, timings and errors. This checks for stalls; it is not a full speed test.

Extra pings and downloads ran from the Mac, wired SSH app and router. Router checks used ethtool, CPU readings and timed eth0 byte counters. Mac Wi-Fi checks read existing logs without a scan. No network settings changed. The wired monitor remains running, and timestamped logs and the HA CSV are saved.

Update: I replaced the GL.iNet Flint 3 with a TP-Link Archer AX73, using the same Spectrum-supplied modem. The same slowdown returned, including on Ethernet.

Please check September 22, 2026, 12:57–1:00 pm EDT. During that window:

• Wired Home Assistant → router: 50/50 replies, 0% loss, 1.25 ms average.
• Wired → Cloudflare (1.1.1.1): 38/50 replies, 24% loss.
• Wired → Google (8.8.8.8): 36/50 replies, 28% loss.
• Mac over Wi-Fi: 0% loss to the router, but 25% to Cloudflare and 20% to Google in an earlier sample.

Real downloads also stalled. One 128 KiB wired HTTPS download took 9.73 seconds. A separate wired request timed out after 12 seconds, receiving only 125,808 of 131,072 bytes. The same dashboard check took 0.18 seconds that morning.

Around 1:02 pm, wired and Wi-Fi ping checks were clean again, without a reboot or settings change. A Mac download of the same small file then took 0.14 seconds. A connection to Fast.com during the slowdown gave me a 280kb download speed.

The replacement AX73 runs firmware 1.3.1 Build 20260430. We enabled OFDMA/MU-MIMO and set 2.4 GHz to 20 MHz earlier that morning. The wired tests bypass Wi-Fi entirely.

To capture this, we ran simultaneous pings to the router and two public IPs from the Ethernet-connected Home Assistant box, plus separate Mac probes. Small HTTPS requests had a 128 KiB cap and 12-second timeout. Timestamped results were saved.

This shows the fault is not limited to Wi-Fi or the Flint 3. It does not yet separate the modem-facing cable, modem, Spectrum, or the replacement router’s internet forwarding. I haven't been able to do a modem only test because too many people/things in the house use the wifi and I'll need to figure out how I'm going to do that.

Given the same fault with two routers, could Spectrum review packet loss and modem/line history for this exact window, beyond the earlier healthy signal-level snapshot?

Ok fair enough. Assuming a house of people using WiFi every day and the issue appearing just enough to be detrimental but not so much it’s easy to catch. How would I prove the modem is the issue?