Visitor
•
1 Message
Customer-owned ARRIS G54: firmware G5X.04.20.122 drops all connections every 30 min, need firmware escalation
Posting here because Xfinity pushes firmware to customer-owned modems. I need this escalated to whoever manages G54 firmware pushes, and I need to know what changed on my line on Sept 25, 2026, when the reloads stopped.
Subject: SURFboard G54 firmware G5X.04.20.122 reloads its firewall every 30 min and kills all active connections
Hello,
My customer-owned ARRIS SURFboard G54 (firmware G5X.04.20.122, Xfinity service) drops every active internet connection on a fixed 30-minute timer. Games disconnect, streams stall, and downloads abort, around the clock. It started around December 2025 after about 16 months of normal operation.
The gateway's own log shows the cause. Every event is logged by the G54 itself:
firewall: Reloading firewall due to ifupdate of wan (eth4)- 146 of these between 2026-09-20 and 2026-09-25 (about 30 per day), always on the same minute and second of the half hour (for example :13:44 / :43:44), which is a timer, not a line fault.
- Each reload wipes the connection table, so every connection with traffic in flight is reset.
- The WAN IP, gateway, and lease values do not change. It looks like a routine DHCP lease renewal is being treated as a WAN interface change.
What I have ruled out:
- The line and signal: 5.3 hours of pings with zero packet loss (gateway 1 ms, internet median 18 ms). Downstream levels are mid-spec (+3.6 to +4.4 dBmV, SNR ~40, all channels locked).
- My equipment: wired PC, and the problem started months after the PC and its network driver were installed.
- The far end: two downloads from unrelated providers (Hetzner in Ashburn and DataPacket in New York) die within 0.1 s of each other at each reload.
- Factory resets: done twice (July 2026). Each one just moves the timer to a new offset.
Predicted in advance: I predicted the exact second of the next two failures from the timer (2026-09-15, 14:58:46 and 15:28:46) and both hit within about 1 second.
Recent change I need explained: the reloads stopped after 2026-09-25 17:58 (gateway clock). A one-hour live test on 2026-09-27 saw no drops, and the gateway has logged no reloads since. The same WAN IP is still assigned. After ten months of this happening nearly every day, I need to know whether something was pushed to my device or changed on the DHCP side on September 25, and whether that is a permanent fix or just a pause.
What I am asking for:
- Escalate to firmware engineering: a DHCP renewal with unchanged lease values should not trigger a WAN interface update and firewall reload, and a firewall reload should not flush established connections.
- Tell me whether a firmware version with this fixed is available or scheduled for push, and push it to my device.
- If no fix is coming, tell me what replacement or exchange options you offer. The defect is in firmware your side pushes; the hardware itself is fine.
I can reproduce this live with about 30 minutes' notice, and I have full logs and timestamps available.
Thanks
Full evidence
Evidence
1. The gateway's own firewall log
Ten occurrences in one evening (2026-09-14, gateway clock, which runs exactly +1h vs local):
2026/09/14 17:58:44 firewall: Reloading firewall due to ifupdate of wan (eth4)2026/09/14 18:58:44 firewall: Reloading firewall due to ifupdate of wan (eth4)2026/09/14 19:28:43 firewall: Reloading firewall due to ifupdate of wan (eth4)2026/09/14 20:28:43 firewall: Reloading firewall due to ifupdate of wan (eth4)2026/09/14 20:58:43 firewall: Reloading firewall due to ifupdate of wan (eth4)2026/09/14 21:58:43 firewall: Reloading firewall due to ifupdate of wan (eth4)2026/09/14 22:28:43 firewall: Reloading firewall due to ifupdate of wan (eth4)2026/09/14 23:28:43 firewall: Reloading firewall due to ifupdate of wan (eth4)2026/09/14 23:58:43 firewall: Reloading firewall due to ifupdate of wan (eth4)2026/09/15 00:58:43 firewall: Reloading firewall due to ifupdate of wan (eth4)Note the fixed seconds value (:43/:44) — characteristic of a timer, not a line fault.
2. Simultaneous death of unrelated connections
Two continuous HTTPS downloads were held open from two different providers on two different networks (Hetzner, Ashburn VA and DataPacket, New York NY). At each firewall reload both died within milliseconds of each other:
2026-09-14 19:58:52.215 Hetzner Ashburn SSLEOFError (after 3320.8s, 54,329,344 bytes)2026-09-14 19:58:52.340 DataPacket NYC SSLEOFError (after 3320.8s, 54,329,344 bytes)^ 0.13s apart2026-09-15 15:28:46.690 DataPacket NYC SSLEOFError (after 1797.6s, 29,409,280 bytes)2026-09-15 15:28:46.762 Hetzner Ashburn SSLEOFError (after 1797.5s, 29,409,280 bytes)^ 0.07s apartTwo independent networks do not fail together. The only shared element is this gateway.
3. Failures predicted in advance, twice
Using the observed 30-minute cadence, the next two failures were predicted before they occurred:
| Predicted | Actual | Error |
|---|---|---|
| 2026-09-15 14:58:46 | 14:58:47.05 | +1.05s |
| 2026-09-15 15:28:46 | 15:28:46.69 | +0.69s |
A live video stream on the same network visibly stalled at the predicted second.
4. Independent corroboration: 83 game disconnects over three months
Path of Exile 2's client log records every dropped connection with a timestamp. Across 2026-06-04 to 2026-09-09 it logged 83 events of Abnormal disconnect: An unexpected disconnection occurred.
Intervals between consecutive disconnects within a session:
30 min ########### (11)60 min ####### (7)90 min ####### (7)120 min ### (3)150 min # (1)180 min # (1)Every interval is an exact multiple of 30 minutes. No intermediate values.
Grouped by minute-of-hour, each cluster is a pair of minutes exactly 30 apart, corresponding to distinct lease epochs:
| Minutes | Count | Date range |
|---|---|---|
| :13 / :43 | 20 | Jun 7 – Sep 9 |
| :03 / :33 | 16 | Jun 16 – Sep 4 |
| :18 / :48 | 13 | Jun 18 – Sep 9 |
| :08 / :38 | 9 | Jun 24 – 25 |
| :28 / :58 | 2 | Jul 7 – 8 |
These phases overlap in time rather than superseding one another, which suggests two concurrent renewal cycles — most likely the IPv4 and IPv6 WAN leases — with independent offsets.
5. The physical line is healthy — this is not a plant issue
Over a continuous 5.3-hour window:
ping 192.168.0.1 (gateway) 1899 samples 0 loss 1ms flatping 8.8.8.8 (internet) 1899 samples 0 loss median 18ms, p95 26ms, max 69msZero packet loss in either direction. Downstream levels were separately brought to mid-spec in July 2026 with a 9 dB attenuator (+12.7..+14.3 → +3.6..+4.4 dBmV, SNR ~40, all channels locked). Signal quality is not a factor.
Ruled out
- Customer equipment. Reproduced on a wired PC whose OS was installed 2025-09-27 and whose NIC driver dates to 2026-02-17 — both outside the December 2025 symptom onset.
- Bandwidth. Gigabit service; failures occur at 16 KB/s just as they do at 6 Mbps.
- Wi-Fi. Affected client is wired Ethernet.
- Cabling / signal. See section 5.
- Factory reset. Performed twice (2026-07-07, 2026-07-10). Each reset only re-anchored the timer to a new offset; the defect persisted.
- Remote end. Two unrelated providers fail simultaneously.
No Responses!