I'm trying to figure out what's causing my internet to stop working every day.
Reconnecting the WAN to the modem doesn't work, rebooting the router doesn't work, the cable modem says it has a solid lock, and rebooting the router doesn't work either.
But simply unplugging the Ethernet Cable and plugging it back in on the modem makes the internet work again.
If it happened once every year I could point to corrosion the contractors but this has happened several times in the last week.
And yes I've swapped the Ethernet cable and this one is brand new.
Has anyone else seen anything like this before?
It's been 4 days with no problems, the only thing that changed is that I had the modem hung vertically and it has been sitting on the table for 5 days horizontally.
Many devices have a better heat dissipation in vertical orientation, so it's quite possible that your modem was overheating before and ending up in a weird state.
So it happened again, except this time I was a little more patient and thorough in my investigation. I was browsing the internet and it slowed to a crawl and then stopped.
The devices are Arris TM1602 connected to Specturm (formerly BrightHouse) and a Netgear R6230 which is running the firmware for it's twin the R6220 running "OpenWrt 19.07.0 r10860-a3ffeb413b / LuCI openwrt-19.07 branch git-20.045.27998-49999e9".
I have installed luci-app-statistics which uses Collectd and RRDtool so I could document when the Ping command stopped returning from the internet (looking for patterns). When I went to view the data I got a memory error so I checked the system memory "Total available" was near 0% and "free" was at 12%.
I rebooted the router checked the memory currently 46% "Total Available" and 60% free. However the internet was still not available. I restarted the WAN interface twice to no avail. So then I re-seated the RJ-45 on the back of the modem and voila! it worked again.
Unfortunately all the log files for collectd were erased on reboot, and I just got done adding USB storage for logs. (Grumble grumble).
That was a brand new Ethernet cable with my new setup which was put in place a few weeks before my new router.
Yes of course I have extra packages installed isn't that the point of OpenWRT to customize it? I believe the memory bloat might be because the statistics plugin was writing log files to "/tmp/" which I have found out is ram. Is there an easy way to list the packages I have added?
One day later I am at 32% total memory available and 34% memory free. so something is still bloating the memory. It looks like https-dns-proxy is eating up about 8% of the memory according to the "Process" page in Luci.
Here is my one day Memory load
Well it just happened again 10:20 PM. At this point I'm using this post as an open journal tracking when it breaks.
Memory was fine, processor was fine.
Two things I noticed for the first time. I was able to successfully ping 1.1.1.1 from my computer even though the internet did not work.
When I looked at the back of the modem the Network indicator light was a solid green. When I re-plugged it was blinking as I would expect.
I will try a different brand of Ethernet cable now. I don't know it's lineage or how long it's been sitting in my cable drawer, or why it ended up there, but at least it looks different.
Oh hell I forgot to come update this page. It started failing again so during the first week of Covid I took the modem up to Spectrum and replaced it. The moron behind the counter was trying so hard to upsell me phone service that he didn't correctly assign the new modem to my account. I took it home not realizing this hooked it up and it didn't work. Called Spectrum and they went through all their procedures and said they couldn't contact the modem from their end so they had to roll a truck to me. The guy shows up and tests my signal level and it's great and then he realizes the moron in the office screwed up and calls to properly assign the modem to me. The good news is that suddenly I have 230 Mbps down!!! and 15 up.
So then less than a week later I have same issues again but i realized that they can be divided into two failures.
Inconsistently weekly occurring but consistently at 10:20 PM the modem just stops working for about 20 minutes. It seems like Spectrum is resetting some piece of equipment somewhere on a regular basis at 10:20 PM.
Randomly during intense internet usage (streaming video chatting etc.) the Ethernet port on the modem gets jammed up.
a) the green light that normally blinks is solid
b) unplugging the Ethernet cable from the modem and plugging it back in fixes it.
c) resetting the the connection, the router, or rebooting either does not fix it.
So when the modems WAN port locks up and needs to be unplugged there is a small trickle of data. Sometimes when I do the ping 1.1.1.1 command I will get one or two returns and three or four failures. Most of the time it's 5 failures. (when using the default 5 ping attempts in windows Linux will obviously keep going till the end of time.)
Well, this sounds like a purely Spectrum based problem. You probably should give their tech support a call, and try to immediately escalate.
shouldn't be occurring, resets daily at 10:20PM are not a normal part of routine maintenance on cable systems. Imagine all the late night comedy show fans who would revolt!
shouldn't happen either, and suggests a modem that has bugs / crashes under load. Perhaps spectrum bought the cheapest possible thing and it has bugs. Or perhaps they need to push a firmware upgrade?
sorry it's not daily with the 10:20 PM it's maybe bi-weekly or maybe monthly I notice it sporadically because I'm not always online at that time of night every day.
You might want to install collectd and turn on some kind of ping module and see if you can document the loss of connection. With that documentation it'll be easier to force Spectrum to do something.
Check the Ethernet switch status page and confirm the modem is linked at 1000 Mb. If it's not at 1000 there is some port or cable problem. The switch can be reconfigured to use a different port for WAN for testing the router side.
Especially if you're not using the telephone service I'd recommend buying your own modem. Many cable modems suffer from overheating. Always stand it vertically as the instructions show (even though the writing on the front is horizontal) and have plenty of free space around it. The modem usually has logs and statistics of its own that you can examine at 192.168.100.1.
Alright It happened again this morning, actually I have lost connection several time since the last time I posted but usually I don't have time to troubleshoot or I discover nothing new to report.
I noticed that the router's clock was WAYYYY off like by days and hours it's 9 AM on 5/22/20 and it said the time was 15:00 5/17/20. Now I'm not sure if this is related to only getting partial internte connection and NTP getting some malformed packets. Or if the router didn't update it's NTP time after I powered it off two days ago (installing lighting fixture).
the router said it's uptime was only 4 hours. I was asleep I didn't reboot the router.
I can confirm that when the WAN lockup happens I cannot log into my modem at 192.168.100.1.
When I plug the CAT5 back in I can log in and inspect the event log. More than once I have noticed a log note saying "RCS partial service", however the timestamp is usually after I noticed the no internet and have started picking at the scab.
Here is the event log of my Arris modem I modified the MAC addresses
DOCSIS(CM) Events
Date Time Event ID Event Level Description
5/16/2020 8:42 84000500 3 SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/16/2020 8:42 84000700 5 RCS Partial Service;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/16/2020 8:42 84000500 3 SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/16/2020 8:42 84000700 5 RCS Partial Service;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/18/2020 6:09 82000200 3 No Ranging Response received - T3 time-out;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/18/2020 11:08 84000700 5 RCS Partial Service;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/18/2020 11:08 84020200 5 Lost MDD Timeout;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/18/2020 11:08 84000700 5 RCS Partial Service;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/18/2020 17:16 68010600 6 DHCP Renew - lease parameters tftp file-?BEWGl2YsfoG+PAAKe+Pw@Cnvj8BEX8ejh2pB2Fh_LHaWQl3V8r+Mk modified;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/18/2020 18:07 84000700 5 RCS Partial Service;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/19/2020 15:46 73040200 3 TLV-11 - Illegal Set operation failed;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/19/2020 15:46 82000400 3 Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/19/2020 16:40 73040200 3 TLV-11 - Illegal Set operation failed;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/19/2020 17:14 84000700 5 RCS Partial Service;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/21/2020 8:44 82000200 3 No Ranging Response received - T3 time-out;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/21/2020 9:30 84000700 5 RCS Partial Service;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/21/2020 10:15 82000200 3 No Ranging Response received - T3 time-out;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/21/2020 12:00 84000700 5 RCS Partial Service;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/22/2020 2:28 82000200 3 No Ranging Response received - T3 time-out;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
5/22/2020 9:19 84000700 5 RCS Partial Service;CM-MAC=a0:a0:a0:be:3c:00;CMTS-MAC=00:a0:a0:a0:0c:ec;CM-QOS=1.1;CM-VER=3.0;
PacketCable(MTA) Events
Date Time Event ID Description
3/19/2020 1:09 16 MTA TFTP: Successful
3/19/2020 1:09 26 MTA PROV: Successful!
3/19/2020 1:09 3 Voice Line State Change, Line Number = 1, Prev State = OOS, New State = IS
3/19/2020 1:09 3 Voice Line State Change, Line Number = 2, Prev State = OOS, New State = IS
3/31/2020 11:34 4000960006 New time has been retrieved from ToD server.
Model information
` Hardware Information
System: ARRIS DOCSIS 3.0 / PacketCable 2.0 Touchstone Telephony Modem
HW_REV: 1
VENDOR: ARRIS Group, Inc.
BOOTR: 2.2.0.45
SW_REV: 9.1.103J8TW1.SIP.PC20.TW
MODEL: TM1602AP2
Serial Number: ###############
Options:
Firmware Build and Revisions
Firmware Name: TS0901103J8TW1_010918_1602.TM_PC20_TW
Firmware Build Time: Tue Jan 9 16:21:59 EST 2018`
OK so I have some more evidence pointing to this maybe being a router problem.
the clock and date were wrong again AND it said that the router had only been up for 43 minutes.
I took a screenshot of the Luci page right above the Win 10 system clock
I corrected the clock by syncing it with the browser but that did not remedy the connection with the Modem.
