Didn't find what you were looking for?
We have advanced search options to make it easier to locate posts, questions and answers on this community.
More information can be found at Advanced Search Options
If you are looking for something specific, please check if someone else has already asked or answered the same question.
A note regarding upgrades and Network Evolution:
Customers will be notified by their preferred communication method (email or text) when upgrades are available in their area for a specific service address
Power outage require power cycle of UPS-connected cable modem
I have an UPS to which my router, my switch, and my cable modem are all connected. We just lost power, and the whole home generator kicked on (as expected), so nothing runs from the UPS for more than ~20 seconds. (It says it can run for ~70 minutes under current load.) The router, and presumably the switch never lost power (it's unmanaged so no logging). My assumption is neither did the cable modem. (Verified it's plugged into a powered socket, not a surge-protected socket on the UPS.) However, every time we lose power, I have to reset the cable modem in order to regain internet access. The cable modem log shows this at the time of the power outage: "Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=xx:xx:xx:xx:xx:xx<redacted>;CMTS-MAC=00:90:f0:25:00:00;CM-QOS=1.1;CM-VER=3.1;" Based on this, it appears as though Upstream scheduling is broken — the CMTS is supposed to periodically grant my modem's specific Service ID (SID) a private "unicast maintenance opportunity" slot to do ranging/keepalive. It's not doing that for my modem specifically, even though it's still broadcasting to everyone. After ~30-40 seconds of not getting its own slot, the modem's T4 timer expires and it's required by the DOCSIS spec to tear down and fully re-initialize (re-scan, re-range, re-register, fresh DHCP). Can I get someone at Spectrum to check if there's a known issue with stale SID state on that CMTS after node power events? Some CMTS software versions have documented bugs with this.
FYI: This is 100% reproducible on every outage.
I'd be happy to supply my address in a private chat if that will help troubleshooting. Thank you in advance!
Best Answer
-
Smaller UPS batteries are commodity items and prone to failure. Most of these batteries have a date of manufacture stamped on their case and two years of service would be stretching it.
The only true way to test UPS batteries is to fail the input power of your UPS with the modem connected (pull the plug test) to see how long it lasts.
1
Answers
-
As stated, no devices connected to the UPS lost power. This is not a UPS issue. Please fully read the post.
0 -
Sounds like a Spectrum node may be going down too? Have you noticed the modem rethunking for new signal lock when it initially goes down?
If these are just localized outages, may be an infrustructure issue in play somewhat with the 3.1 expansions. In the past, under 2.0/3.0, ours tended to stay up unless it was a major outage, like the whole power substation goes offline and we lost upstream nodes or even the headend too.
I run on a UPS also (1100 model), but haven't had any power issues since we cut over to 3.1 this summer—roughly only a month in so far. Will be interesting to see if we have the same issue... like if the upgrades caused some changes to the upstream power structure that creates recovery issues.
1 -
Good question — worth clarifying because it points at exactly where the fault lives.
The modem does go through a full re-init when this happens (re-scan, re-range, re-register, fresh DHCP) — so from the outside it looks like it "lost lock." But looking at the actual log line at the moment of failure, that's not what triggers it. Downstream broadcast MAPs are still being received fine right up until the timeout — the modem is hearing the CMTS. What's missing is a unicast maintenance/ranging opportunity for our specific Service ID. After ~30-40s without one, DOCSIS spec requires the modem to tear itself down and reinit. So the "rescan for signal lock" you're seeing is really the symptom of the forced re-init, not the original cause — the original cause is upstream scheduling, not downstream signal loss.
That actually lines up with your 3.1 theory. Under 2.0/3.0, upstream was TDMA/ATDMA — simpler EQ/GRANT bookkeeping per modem. 3.1 upstream leans on OFDMA, which means the CMTS is tracking a lot more per-SID scheduling state (minislot maps, profile assignments, etc.) for each modem. More state = more surface area for something to get stuck stale on the CMTS side after a node/amp blips and comes back, especially if the CMTS doesn't cleanly expire or rebuild that state on reconnect. A node blip that used to be a total non-event under 3.0 could now be enough to leave your SID's scheduling entry orphaned under 3.1 without anything on the customer end (modem, wiring, UPS) actually failing.
You're about a month into 3.1 with no issues — I'd genuinely be curious if that holds. If you do hit one, the log line to watch for is the same one I posted: "Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out." If you see that exact line during a future blip, it'd be a good data point that this is a broader 3.1-rollout scheduling bug rather than something specific to my node/CMTS.
1
