 jimkPremium join:2006-04-15 Raleigh, NC | reply to Scotsman
Re: [TWC] Time warner cable and Motorola Surfboard 6141 Please post your event log from the modem (blank out any MAC addresses) and the firmware version.
Signals look good so far. However, there are some upstream stats that you can't see on your modem.
What modem did you have previously? |
|
 | Thanks. I had some ancient scientific atlanta WebSTAR EPC2203
Firmware info:
Model Name: SB6141 Vendor Name: Motorola Firmware Name: SB_KOMODO-1.0.6.3-SCM03-NOSH Boot Version: PSPU-Boot(25CLK) 1.0.12. Hardware Version: 7.0 Serial Number: 348781213900943606010001 Firmware Build Time: Aug 18 2011 10:27:53
Event log:
Jan 18 2013 22:01:42 5-Warning Z00.0 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=xxxxx;CMTS-MAC=00:15:f9:2a:29:60;CM-QOS=1.1;CM-VER=3.0; Jan 01 1970 00:00:14 6-Notice Cable Modem Reboot due to power reset ;CM-MAC=xxxxx;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.0; Jan 18 2013 21:42:14 5-Warning Z00.0 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=xxxxx;CMTS-MAC=00:15:f9:2a:29:60;CM-QOS=1.1;CM-VER=3.0; Jan 01 1970 00:00:14 6-Notice Cable Modem Reboot due to power reset ;CM-MAC=xxxxx;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.0; Jan 18 2013 21:40:46 5-Warning Z00.0 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=xxxxx;CMTS-MAC=00:15:f9:2a:29:60;CM-QOS=1.1;CM-VER=3.0; Jan 01 1970 00:00:14 6-Notice Cable Modem Reboot due to power reset ;CM-MAC=xxxxx;CMTS-MAC=00:15:f9:2a:29:60;CM-QOS=1.1;CM-VER=3.0; Jan 18 2013 21:34:58 5-Warning Z00.0 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=20:xxxxx;CMTS-MAC=00:15:f9:2a:29:60;CM-QOS=1.1;CM-VER=3.0; Jan 01 1970 00:00:14 6-Notice Cable Modem Reboot due to power reset ;CM-MAC=xxxxx;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.0; Jan 18 2013 21:33:33 5-Warning Z00.0 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=xxxxx;CMTS-MAC=xxxxx;CM-QOS=1.1;CM-VER=3.0; Jan 01 1970 00:00:14 6-Notice Cable Modem Reboot due to power reset ;CM-MAC=xxxxx;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.0; Jan 18 2013 20:46:45 5-Warning Z00.0 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=xxxxx;CMTS-MAC=xxxxx;CM-QOS=1.1;CM-VER=3.0; Jan 01 1970 00:00:14 6-Notice Cable Modem Reboot due to power reset ;CM-MAC=xxxxx;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.0; Jan 18 2013 20:28:41 5-Warning Z00.0 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=xxxxx;CMTS-MAC=xxxxx;CM-QOS=1.1;CM-VER=3.0; Jan 01 1970 00:00:14 6-Notice Cable Modem Reboot due to power reset ;CM-MAC=xxxxx;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.0; Jan 18 2013 20:17:08 5-Warning Z00.0 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=20:e5:64:5b:b8:58;CMTS-MAC=00:15:f9:2a:29:60;CM-QOS=1.1;CM-VER=3.0; Jan 01 1970 00:00:14 6-Notice Cable Modem Reboot due to power reset ;CM-MAC=xxxxx;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.0; Jan 18 2013 18:46:05 5-Warning Z00.0 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=xxxxx;CMTS-MAC=xxxxx;CM-QOS=1.1;CM-VER=3.0; Jan 01 1970 00:00:14 6-Notice Cable Modem Reboot due to power reset ;CM-MAC=xxxxx;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.0; Jan 18 2013 18:22:28 5-Warning Z00.0 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=xxxxx;CMTS-MAC=xxxxx;CM-QOS=1.1;CM-VER=3.0; Jan 01 1970 00:00:14 6-Notice Cable Modem Reboot due to power reset ;CM-MAC=xxxxx;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.0; |
|
 jimkPremium join:2006-04-15 Raleigh, NC Reviews:
·RoadRunner Cable
·voip.ms
| How often are you resetting it? I'm assuming that every single "Cable Modem Reboot due to power reset" event is you power cycling the modem, but if that is not the case and it is doing this on its own, you might have a power supply or modem issue.
When you start to have problems, does it eventually start working normally again without being power cycled? Or is a power cycle the only way to fix it?
If possible, it may be necessary to leave the modem on and grab the signal stats & logs during and immediately after the problem happens without rebooting the modem. |
|
|
|
 | I have been regularly resetting it. Seems to be the quickest way to clear the problem.
And yes, it does eventually start working again after sometime - the pings come back to a more usual 25ms or so.
I'll try and grab those logs at the point of failure as you suggest. Watch this space |
|
 | OK in the middle of a slowdown here's the signal levels and a traceroute & ping test
raceroute has started
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 72 byte packets
1 10.0.1.1 (10.0.1.1) 1.319 ms 0.725 ms 1.173 ms 2 * * * 3 tge7-2.austtxk-er01.texas.rr.com (66.68.1.245) 1477.595 ms 19.937 ms 8.302 ms 4 tge0-11-0-9.austtxa-cr01.texas.rr.com (24.175.41.74) 21.381 ms 21.348 ms 31.855 ms 5 agg22.dllatxl3-cr01.texas.rr.com (24.175.41.46) 23.834 ms 23.307 ms 15.972 ms 6 107.14.17.136 (107.14.17.136) 22.158 ms 26.579 ms 23.357 ms 7 107.14.17.232 (107.14.17.232) 15.277 ms 17.415 ms 16.907 ms 8 74.125.48.65 (74.125.48.65) 78.836 ms 75.936 ms * 9 * 72.14.233.67 (72.14.233.67) 371.583 ms 23.716 ms 10 72.14.237.217 (72.14.237.217) 29.557 ms 87.131 ms 72.14.237.221 (72.14.237.221) 37.461 ms 11 209.85.243.178 (209.85.243.178) 52.202 ms 216.239.47.121 (216.239.47.121) 24.709 ms 209.85.243.178 (209.85.243.178) 26.850 ms 12 216.239.46.59 (216.239.46.59) 24.728 ms 216.239.46.61 (216.239.46.61) 69.774 ms 216.239.46.59 (216.239.46.59) 911.212 ms 13 * * * 14 google-public-dns-a.google.com (8.8.8.8) 269.900 ms 152.609 ms 140.605 ms
PING 8.8.8.8 (8.8.8.8): 56 data bytes Request timeout for icmp_seq 0 Request timeout for icmp_seq 1 Request timeout for icmp_seq 2 Request timeout for icmp_seq 3 Request timeout for icmp_seq 4 64 bytes from 8.8.8.8: icmp_seq=0 ttl=45 time=5592.902 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=45 time=4710.106 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=45 time=3723.132 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=45 time=2834.900 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=45 time=1904.882 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=45 time=909.429 ms 64 bytes from 8.8.8.8: icmp_seq=6 ttl=45 time=26.834 ms 64 bytes from 8.8.8.8: icmp_seq=7 ttl=45 time=29.433 ms 64 bytes from 8.8.8.8: icmp_seq=8 ttl=45 time=3590.248 ms 64 bytes from 8.8.8.8: icmp_seq=9 ttl=45 time=2606.492 ms 64 bytes from 8.8.8.8: icmp_seq=10 ttl=45 time=1612.888 ms 64 bytes from 8.8.8.8: icmp_seq=11 ttl=45 time=614.727 ms Request timeout for icmp_seq 17 Request timeout for icmp_seq 18 Request timeout for icmp_seq 19 Request timeout for icmp_seq 20 64 bytes from 8.8.8.8: icmp_seq=12 ttl=45 time=9670.297 ms 64 bytes from 8.8.8.8: icmp_seq=13 ttl=45 time=8670.335 ms 64 bytes from 8.8.8.8: icmp_seq=14 ttl=45 time=7670.270 ms 64 bytes from 8.8.8.8: icmp_seq=15 ttl=45 time=6670.812 ms
Seems to get really bad getting beyond my LAN.
I read that the Motorola 6141 was the best, but perhaps I should be try a different one? This never happened with my old modem and slower speed. Called TWC a few times but they have no clue. |
|
 jimkPremium join:2006-04-15 Raleigh, NC Reviews:
·RoadRunner Cable
·voip.ms
| Your previous modem was not DOCSIS 3, so there could be an issue on TWC's side that only impacts DOCSIS 3 devices, but I kind of doubt it in this situation. Are you seeing any T3 or T4 timeouts anywhere in the modem logs?
If everything worked before and the modem is the only thing that changed, I would be inclined to try a different model of modem to rule out any strange firmware bugs or compatibility issues. There have been multiple firmware revisions since the one installed on your modem. Currently, TWC is currently refusing to even talk about pushing firmware updates to customer owned modems on the supported device list. You can't install it yourself either since Motorola won't provide it to customers and there is no interface to flash the update from the customer side.
The Zoom 5341J (note the J - the DOCSIS 3 8x4 model, not the old 5341 which is only 4x4 and not on the approved device list) is a good modem. A small number of people seem to have problems with it dropping the connection for a few seconds every 2.5 days, but that is a lot better than what you are seeing. It always comes back without a power cycle being required.
I assume you have already eliminated your router/firewall as the cause for the issue. I highly doubt that has anything to do with it but it makes sense to check just in case. |
|