07-15-2021 03:58 PM - last edited on 07-15-2021 05:09 PM by RogersMoin
I tried unplugging modem and 3rd party router.
This problem seems to happen more frequently. I am now entering the info into my phone (notes) - time/day of disconnection and duration.
It went down Tuesday and now today. I don't recall how long it was out last time. Maybe 30 min or 1 hr total?
I also use a wifi Smart TV.
It has reconnected a few times only to drop 5 mins (estimate) later. Sometimes the speed is normal but often, the connection is at a much lower speed suggesting a problem.
I am wondering if there's an issue.
*Added Labels*
07-30-2020 09:39 AM
07-30-2020 10:55 AM - edited 07-30-2020 10:58 AM
@ChaeFam what modem do you have? The modems in use are:
1. Black Hitron CGN3xxxx modems where the exact modem model is seen on the product sticker at the back of the modem.
2. The white CODA-4582 modem. There is only one white modem in use by Rogers.
3. The Arris XB6 which is used with the new Ignite TV service. The modems are either the Arris TG-3482ER or Technicolor CGM-4140COM. The modem model is seen on the bottom of the modem.
Knowing what modem you have, I can post the correct instructions to post the modem's signal levels.
Have you already called tech support by chance, and if so, what did the Customer Service Rep have to say about the problem?
A problem such as this is usually caused by degradation of the external cable / connectors although there is always the possibility of an equipment failure at another point in the system.
07-30-2020 11:19 AM
Our modem is the second one, the white CODA-4582.
And no, I haven't contacted tech support yet. I was gonna give it some more time to see if it fixes on it its own because our usual internet problems are on the Rogers' side of things and does get fixed after a little while. But I saw this thread on here and thought I'd post about it.
07-30-2020 11:43 AM
07-30-2020 12:25 PM - edited 07-30-2020 12:29 PM
@MAliJafri @ChaeFam can you log into the modem and:
1. Have a look at the Software (firmware) version as shown on the STATUS page which is displayed when you log into the modem. Please let me know what version you have loaded. If you happen to have Version 7.1.1.32 loaded, reboot the modem, ADMIN .... DEVICE RESET .... Reboot. That is a new firmware version with a new kernel to support DOCSIS 3.1 upstream. Depending on what follows after the reboot and after looking at the signal levels, I might recommend running a factory reset for the modem. If the signal levels were ok, and a reboot doesn't solve any modem instability, I'll recommend a factory reset, but, first I'd like to have a look at the signal levels.
2. Navigate to the STATUS .... DOCSIS WAN tab. Copy the Downstream Overview table, all the way down the bottom right hand corner of the OFDM/OFDMA section which is at the bottom of the table. Starting with the Downstream Overview line, highlight or select that line and continue down to the bottom right hand corner of the OFDM/OFDMA section. Right click .... Copy. In a new post, right click .... Paste. That should paste in the table as it appears in the modems user interface.
07-30-2020 01:06 PM
Hi! I'm not the same user, but I am having the same issue. I have the firmware version you mentioned, rebooted my modem and have the following signal stats:
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Signal noise ratio (dB) |
1 | 591000000 | QAM256 | -2.500 | 7 | 38.605 |
2 | 597000000 | QAM256 | -2.500 | 8 | 38.983 |
3 | 603000000 | QAM256 | -2.099 | 9 | 38.605 |
4 | 855000000 | QAM256 | -1.700 | 3 | 38.983 |
5 | 861000000 | QAM256 | -1.700 | 4 | 38.605 |
6 | 579000000 | QAM256 | -2.599 | 5 | 38.983 |
7 | 585000000 | QAM256 | -2.500 | 6 | 38.605 |
8 | 849000000 | QAM256 | -1.500 | 2 | 38.605 |
9 | 609000000 | QAM256 | -2.099 | 10 | 38.605 |
10 | 615000000 | QAM256 | -1.900 | 11 | 38.605 |
11 | 621000000 | QAM256 | -1.700 | 12 | 38.605 |
12 | 633000000 | QAM256 | -1.200 | 13 | 38.605 |
13 | 639000000 | QAM256 | -0.900 | 14 | 38.605 |
14 | 645000000 | QAM256 | -0.799 | 15 | 38.983 |
15 | 651000000 | QAM256 | -0.599 | 16 | 38.605 |
16 | 657000000 | QAM256 | -0.400 | 17 | 38.983 |
17 | 663000000 | QAM256 | -0.299 | 18 | 38.605 |
18 | 669000000 | QAM256 | -0.299 | 19 | 38.605 |
19 | 675000000 | QAM256 | -0.200 | 20 | 38.605 |
20 | 681000000 | QAM256 | -0.099 | 21 | 38.983 |
21 | 687000000 | QAM256 | 0.000 | 22 | 38.983 |
22 | 693000000 | QAM256 | 0.099 | 23 | 38.605 |
23 | 699000000 | QAM256 | 0.099 | 24 | 38.983 |
24 | 705000000 | QAM256 | 0.099 | 25 | 38.983 |
25 | 711000000 | QAM256 | -0.299 | 26 | 38.983 |
26 | 717000000 | QAM256 | -0.200 | 27 | 38.983 |
27 | 723000000 | QAM256 | -0.299 | 28 | 38.605 |
28 | 825000000 | QAM256 | -1.599 | 29 | 38.983 |
29 | 831000000 | QAM256 | -1.599 | 30 | 38.983 |
30 | 837000000 | QAM256 | -1.299 | 31 | 38.605 |
31 | 843000000 | QAM256 | -1.400 | 32 | 38.605 |
32 | 279000000 | QAM256 | -4.400 | 1 | 37.636 |
Receiver | FFT type | Subcarr 0 Frequency(MHz) | PLC locked | NCP locked | MDC1 locked | PLC power(dBmv) |
0 | 4K | 275600000 | YES | YES | YES | -3.900002 |
1 | NA | NA | NO | NO | NO | NA |
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Bandwidth |
1 | 36996000 | 64QAM | 46.520 | 4 | 6400000 |
2 | 22100000 | 64QAM | 45.510 | 1 | 3200000 |
3 | 30596000 | 64QAM | 46.520 | 3 | 6400000 |
4 | 25300000 | 64QAM | 45.510 | 2 | 3200000 |
5 | 0 | QAM_NONE | - | --- | 1600000 |
6 | 0 | QAM_NONE | - | --- | 1600000 |
7 | 0 | QAM_NONE | - | --- | 1600000 |
8 | 0 | QAM_NONE | - | --- | 1600000 |
Channel Index | State | lin Digital Att | Digital Att | BW (sc's*fft) | Report Power | Report Power1_6 | FFT Size |
0 | DISABLED | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 2K |
1 | DISABLED | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 2K |
07-30-2020 05:41 PM
Gave it some time after doing the reboot but the issue still came up, so here's the DOCSIS WAN signals...
Downstream Overview
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Signal noise ratio (dB) |
1 | 591000000 | QAM256 | -0.900 | 7 | 36.386 |
2 | 597000000 | QAM256 | -1.000 | 8 | 36.386 |
3 | 603000000 | QAM256 | -1.099 | 9 | 36.386 |
4 | 849000000 | QAM256 | -6.099 | 2 | 32.676 |
5 | 855000000 | QAM256 | -6.500 | 3 | 32.321 |
6 | 861000000 | QAM256 | -6.900 | 4 | 32.237 |
7 | 579000000 | QAM256 | -1.000 | 5 | 36.386 |
8 | 585000000 | QAM256 | -0.700 | 6 | 36.386 |
9 | 303000000 | QAM256 | 1.200 | 1 | 38.605 |
10 | 609000000 | QAM256 | -1.200 | 10 | 36.609 |
11 | 615000000 | QAM256 | -1.000 | 11 | 36.609 |
12 | 621000000 | QAM256 | -0.799 | 12 | 36.609 |
13 | 633000000 | QAM256 | -0.900 | 13 | 36.386 |
14 | 639000000 | QAM256 | -1.000 | 14 | 36.386 |
15 | 645000000 | QAM256 | -0.799 | 15 | 36.386 |
16 | 651000000 | QAM256 | -0.900 | 16 | 36.386 |
17 | 657000000 | QAM256 | -0.799 | 17 | 36.386 |
18 | 663000000 | QAM256 | -0.900 | 18 | 36.386 |
19 | 669000000 | QAM256 | -1.099 | 19 | 36.386 |
20 | 675000000 | QAM256 | -1.099 | 20 | 36.386 |
21 | 681000000 | QAM256 | -1.400 | 21 | 35.779 |
22 | 687000000 | QAM256 | -1.500 | 22 | 35.595 |
23 | 693000000 | QAM256 | -2.000 | 23 | 35.779 |
24 | 699000000 | QAM256 | -2.000 | 24 | 35.595 |
25 | 705000000 | QAM256 | -2.299 | 25 | 35.083 |
26 | 711000000 | QAM256 | -2.400 | 26 | 35.595 |
27 | 717000000 | QAM256 | -2.500 | 27 | 34.925 |
28 | 723000000 | QAM256 | -3.200 | 28 | 34.925 |
29 | 825000000 | QAM256 | -4.799 | 29 | 33.376 |
30 | 831000000 | QAM256 | -5.000 | 30 | 32.962 |
31 | 837000000 | QAM256 | -5.299 | 31 | 32.962 |
32 | 843000000 | QAM256 | -5.500 | 32 | 32.676 |
Receiver | FFT type | Subcarr 0 Frequency(MHz) | PLC locked | NCP locked | MDC1 locked | PLC power(dBmv) |
0 | NA | NA | NO | NO | NO | NA |
1 | 4K | 290600000 | YES | YES | YES | 1.299999 |
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Bandwidth |
1 | 32300000 | 64QAM | 39.770 | 3 | 6400000 |
2 | 38700000 | 64QAM | 39.770 | 4 | 6400000 |
3 | 21100000 | 64QAM | 36.760 | 1 | 3200000 |
4 | 25900000 | 64QAM | 38.520 | 2 | 6400000 |
5 | 0 | QAM_NONE | - | --- | 1600000 |
6 | 0 | QAM_NONE | - | --- | 1600000 |
7 | 0 | QAM_NONE | - | --- | 1600000 |
8 | 0 | QAM_NONE | - | --- | 1600000 |
Channel Index | State | lin Digital Att | Digital Att | BW (sc's*fft) | Report Power | Report Power1_6 | FFT Size |
0 | DISABLED | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 2K |
1 | DISABLED | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 2K |
07-31-2020 01:18 PM
I am also having the same issue as others. The modem was super stable in bridge mode without a reboot for months on 36T8. I consistently got the advertised speed and low ping times of 5-8ms. Ever since I got upgraded to 7.1.1.x the modem has become sluggish. The internet speed starts to slow down and the ping times go into the 100-200ms range. Sometimes the pings timeout all together resulting in a total loss of internet. The 192.168.100.1 management interface becomes unreachable. Once you reboot the modem everything is fast like it was on 36T8. After a few hours or days it starts acting up again. I've even tried a factory reset. The only way to fix this is via a reboot of the modem. I've brought this up twice to the tech support staff and they say "firmware can't slow a connection down" as if they are software engineers. I'm an engineer and dumbfounded at how flawed that statement is. Their initial "fix" was to put it into gateway mode which means I'm going to get double NAT'd and going through two firewalls. I said I can't settle for gateway mode and then they say they need to send a tech. The problem is once the modem is rebooted it will be snappy again and will take hours to days to get back into that bad state. So I don't know what good a tech would do in this situation. The thing they don't seem to understand is that it was super stable on 36T8 and the only variable here is this huge firmware upgrade. How does this not raise any alarm bells?
07-31-2020 01:28 PM
Based on the data you've provided, there doesn't appear to be any noticeable signal issues. Your signals seem to be in spec.
We may need some additional information to investigate this matter further. You can send us a PM to get started.
Not sure how the send us a Private Message, please check here https://communityforums.rogers.com/t5/Rogers-Community-Forums-Blog/Get-to-know-your-Community-How-To...
Regards
RogersNiki
08-01-2020 10:15 PM
Just to update my particular situation, the constant disconnecting issues I've had for 4+ days was on the Rogers side of things. Last night, about 26 hours ago, Rogers shut down our area's internet and TV services as they did maintenance in our area for about 9 hours. Since then, our internet hasn't had any disconnecting issues all day today.
08-04-2020 11:31 AM - edited 08-04-2020 11:36 AM
I've been having intermittent internet issues since May. Had a couple tech visits where they replaced the modem (FYI, i have the black Hitron modem) and on the last visit, replaced the wire from the pole to the outside of the house and still I experience drops. I've noticed there are 2 types of scenarios, one is total outage (less frequent) and the other is the speed dramatically drops to the point devices trying to visit sites just times out, cause Teams calls to cut out, etc. (but strangely enough devices that are already streaming have no issues). The latter scenario will fix itself... usually by the time I run to the modem to connect my laptop to run tests. Sigh...
I noticed a huge slowdown so I ran a ping to my CMTS and saw 10% loss over wifi and then managed to run to the modem and saw 3% loss over LAN. I ran another ping over LAN and then it's back to 0% loss.
OVER WIFI
Pinging 174.114.130.1 with 32 bytes of data:
Reply from 174.114.130.1: bytes=32 time=50ms TTL=63
Reply from 174.114.130.1: bytes=32 time=15ms TTL=63
Reply from 174.114.130.1: bytes=32 time=13ms TTL=63
Reply from 174.114.130.1: bytes=32 time=13ms TTL=63
Reply from 174.114.130.1: bytes=32 time=11ms TTL=63
Reply from 174.114.130.1: bytes=32 time=33ms TTL=63
Reply from 174.114.130.1: bytes=32 time=16ms TTL=63
Reply from 174.114.130.1: bytes=32 time=20ms TTL=63
Reply from 174.114.130.1: bytes=32 time=14ms TTL=63
Reply from 174.114.130.1: bytes=32 time=11ms TTL=63
Request timed out.
Reply from 174.114.130.1: bytes=32 time=36ms TTL=63
Reply from 174.114.130.1: bytes=32 time=36ms TTL=63
Reply from 174.114.130.1: bytes=32 time=47ms TTL=63
Reply from 174.114.130.1: bytes=32 time=17ms TTL=63
Reply from 174.114.130.1: bytes=32 time=14ms TTL=63
Reply from 174.114.130.1: bytes=32 time=9ms TTL=63
Reply from 174.114.130.1: bytes=32 time=11ms TTL=63
Reply from 174.114.130.1: bytes=32 time=35ms TTL=63
Reply from 174.114.130.1: bytes=32 time=248ms TTL=63
Reply from 174.114.130.1: bytes=32 time=16ms TTL=63
Reply from 174.114.130.1: bytes=32 time=24ms TTL=63
Reply from 174.114.130.1: bytes=32 time=17ms TTL=63
Reply from 174.114.130.1: bytes=32 time=13ms TTL=63
Reply from 174.114.130.1: bytes=32 time=26ms TTL=63
Reply from 174.114.130.1: bytes=32 time=103ms TTL=63
Reply from 174.114.130.1: bytes=32 time=115ms TTL=63
Reply from 174.114.130.1: bytes=32 time=15ms TTL=63
Request timed out.
Reply from 174.114.130.1: bytes=32 time=16ms TTL=63
Reply from 174.114.130.1: bytes=32 time=27ms TTL=63
Reply from 174.114.130.1: bytes=32 time=12ms TTL=63
Reply from 174.114.130.1: bytes=32 time=13ms TTL=63
Request timed out.
Reply from 174.114.130.1: bytes=32 time=12ms TTL=63
Reply from 174.114.130.1: bytes=32 time=81ms TTL=63
Request timed out.
Reply from 174.114.130.1: bytes=32 time=20ms TTL=63
Reply from 174.114.130.1: bytes=32 time=31ms TTL=63
Reply from 174.114.130.1: bytes=32 time=16ms TTL=63
Request timed out.
Request timed out.
Reply from 174.114.130.1: bytes=32 time=23ms TTL=63
Request timed out.
Reply from 174.114.130.1: bytes=32 time=17ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=268ms TTL=63
Reply from 174.114.130.1: bytes=32 time=18ms TTL=63
Reply from 174.114.130.1: bytes=32 time=82ms TTL=63
Reply from 174.114.130.1: bytes=32 time=15ms TTL=63
Reply from 174.114.130.1: bytes=32 time=16ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=25ms TTL=63
Reply from 174.114.130.1: bytes=32 time=38ms TTL=63
Request timed out.
Request timed out.
Reply from 174.114.130.1: bytes=32 time=16ms TTL=63
Request timed out.
Reply from 174.114.130.1: bytes=32 time=11ms TTL=63
Reply from 174.114.130.1: bytes=32 time=16ms TTL=63
Ping statistics for 174.114.130.1:
Packets: Sent = 60, Received = 50, Lost = 10 (16% loss),
Approximate round trip times in milli-seconds:
Minimum = 9ms, Maximum = 268ms, Average = 35ms
OVER LAN
Pinging 174.114.130.1 with 32 bytes of data:
Request timed out.
Request timed out.
Reply from 174.114.130.1: bytes=32 time=11ms TTL=63
Reply from 174.114.130.1: bytes=32 time=14ms TTL=63
Reply from 174.114.130.1: bytes=32 time=18ms TTL=63
Reply from 174.114.130.1: bytes=32 time=15ms TTL=63
Reply from 174.114.130.1: bytes=32 time=13ms TTL=63
Reply from 174.114.130.1: bytes=32 time=16ms TTL=63
Reply from 174.114.130.1: bytes=32 time=9ms TTL=63
Reply from 174.114.130.1: bytes=32 time=13ms TTL=63
Reply from 174.114.130.1: bytes=32 time=17ms TTL=63
Reply from 174.114.130.1: bytes=32 time=19ms TTL=63
Reply from 174.114.130.1: bytes=32 time=12ms TTL=63
Reply from 174.114.130.1: bytes=32 time=11ms TTL=63
Reply from 174.114.130.1: bytes=32 time=15ms TTL=63
Reply from 174.114.130.1: bytes=32 time=11ms TTL=63
Reply from 174.114.130.1: bytes=32 time=18ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=8ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=8ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=9ms TTL=63
Reply from 174.114.130.1: bytes=32 time=13ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=14ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=11ms TTL=63
Reply from 174.114.130.1: bytes=32 time=8ms TTL=63
Reply from 174.114.130.1: bytes=32 time=8ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=7ms TTL=63
Reply from 174.114.130.1: bytes=32 time=13ms TTL=63
Reply from 174.114.130.1: bytes=32 time=9ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=14ms TTL=63
Reply from 174.114.130.1: bytes=32 time=11ms TTL=63
Reply from 174.114.130.1: bytes=32 time=9ms TTL=63
Reply from 174.114.130.1: bytes=32 time=8ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=8ms TTL=63
Reply from 174.114.130.1: bytes=32 time=13ms TTL=63
Reply from 174.114.130.1: bytes=32 time=11ms TTL=63
Reply from 174.114.130.1: bytes=32 time=11ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=8ms TTL=63
Reply from 174.114.130.1: bytes=32 time=14ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=13ms TTL=63
Reply from 174.114.130.1: bytes=32 time=7ms TTL=63
Reply from 174.114.130.1: bytes=32 time=8ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=9ms TTL=63
Reply from 174.114.130.1: bytes=32 time=9ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Reply from 174.114.130.1: bytes=32 time=9ms TTL=63
Reply from 174.114.130.1: bytes=32 time=14ms TTL=63
Reply from 174.114.130.1: bytes=32 time=11ms TTL=63
Reply from 174.114.130.1: bytes=32 time=17ms TTL=63
Reply from 174.114.130.1: bytes=32 time=10ms TTL=63
Ping statistics for 174.114.130.1:
Packets: Sent = 60, Received = 58, Lost = 2 (3% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 19ms, Average = 11ms
08-05-2020 11:38 AM - edited 08-05-2020 01:43 PM
Hey @12heater,
Welcome to the Rogers Community Forums and congratulations on your first post with us! 😊
I hope you're staying safe and sound. I know first hand how important it is to ensure you stay connected and how disruptive and what an inconvenience it can be when it goes down especially during these times.
When this issue is transpiring, does it affect all devices at the same time? Are you able to connect your SmartPhones/Tablets to your Wi-Fi network, or is it mainly happening on a specific device? Is it possible to run a speed test to see what results you actually get when this happens? When you run the speed test, please ensure you are hardwired directly to the modem and utilizing speedtest.net to do so. 👍
We've also got some great Resident Experts who may be able to provide more insight on this for you. I will tag them into this post for you: @Datalink, @Gdkitty, @-G-.
We look forward to your response!
RogersJo
08-05-2020 01:36 PM - edited 08-05-2020 02:02 PM
@12heater Could you please try running an hour-long ping test to both the default gateway IP address on your local LAN as well as to your CMTS router, simultaneously, in separate windows? (The command to do this on Windows is "ping -n 3600 IP_address"; on Linux/macOS, the command is "ping -c 3600 IP_address")
If the problem is purely on the Rogers side, you should only see packet loss when pinging the CMTS router.
Ideally, there should be no latency, packet loss or jitter on the local LAN, on wired or wireless connections... but if there is, then that's the first problem that needs to be solved.
Your ping tests show packet loss over both Ethernet and Wi-Fi. However, the latency and jitter is much worse over Wi-Fi.
Wi-Fi:
Packets: Sent = 60, Received = 50, Lost = 10 (16% loss),
Approximate round trip times in milli-seconds:
Minimum = 9ms, Maximum = 268ms, Average = 35ms
Ethernet:
Packets: Sent = 60, Received = 58, Lost = 2 (3% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 19ms, Average = 11ms
Ideally, those stats should be the same or, at at least very similar. In your one-minute ping test, the RTTs over Ethernet were all less than 20 ms. Over Wi-Fi, you had the following spikes in the 20-99 ms range:
Reply from 174.114.130.1: bytes=32 time=50ms TTL=63
Reply from 174.114.130.1: bytes=32 time=33ms TTL=63
Reply from 174.114.130.1: bytes=32 time=20ms TTL=63
Reply from 174.114.130.1: bytes=32 time=36ms TTL=63
Reply from 174.114.130.1: bytes=32 time=36ms TTL=63
Reply from 174.114.130.1: bytes=32 time=47ms TTL=63
Reply from 174.114.130.1: bytes=32 time=35ms TTL=63
Reply from 174.114.130.1: bytes=32 time=24ms TTL=63
Reply from 174.114.130.1: bytes=32 time=26ms TTL=63
Reply from 174.114.130.1: bytes=32 time=27ms TTL=63
Reply from 174.114.130.1: bytes=32 time=81ms TTL=63
Reply from 174.114.130.1: bytes=32 time=20ms TTL=63
Reply from 174.114.130.1: bytes=32 time=31ms TTL=63
Reply from 174.114.130.1: bytes=32 time=23ms TTL=63
Reply from 174.114.130.1: bytes=32 time=82ms TTL=63
Reply from 174.114.130.1: bytes=32 time=25ms TTL=63
Reply from 174.114.130.1: bytes=32 time=38ms TTL=63
... and a few exceeding 100 ms:
Reply from 174.114.130.1: bytes=32 time=248ms TTL=63
Reply from 174.114.130.1: bytes=32 time=103ms TTL=63
Reply from 174.114.130.1: bytes=32 time=115ms TTL=63
Reply from 174.114.130.1: bytes=32 time=268ms TTL=63
If you post your modem's Downstream and Upstream channel stats, we could have a look at them and confirm whether or not they are to spec. Please also check your modem's error logs to see if any critical DOCSIS events (or any other significant errors) are being reported. Rogers should be able to tell you whether the signal to your modem is normal or problematic, what the correctable and uncorrectable codeword error counts are in addition to the number of unerrored codewords, whether there are noise spikes in your area, and the loading of your local node.
If you see these problems at particular times of the day, it could be due to network traffic loads in your area.
Regardless, the first thing that you need to make sure of is that you do not have any problems on your local LAN and Wi-Fi networks.
08-07-2020 04:39 PM
my internet service is keep interrupting every days since ~3/4 weeks ago, failed to get connection many times per day, from 1 mins to ~30 mins, very frustratied. I tried to replace a new modem & power off/on the modem many times, but nothing help
my service plan is ignite 1G, modem is coda-4582 (bridge mode), ubiquiti usg + switch + aps, this setup is already 2 years old, no any problems so far
anyone knows what the problem is?
~~~ normal ~~~
Last login: Thu Aug 6 21:00:38 on ttys000
kevin@MBP15 ~ % ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=118 time=17.093 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=15.262 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=15.999 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=21.261 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=17.097 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=118 time=12.410 ms
^C
--- 8.8.8.8 ping statistics ---
6 packets transmitted, 6 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 12.410/16.520/21.261/2.642 ms
~~~ abnormal~~~
Last login: Thu Aug 6 21:30:50 on ttys000
kevin@MBP15 ~ % ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
92 bytes from usg (10.10.1.1): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 d7ef 0 0000 3f 01 883a 10.10.1.102 8.8.8.8
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
92 bytes from usg (10.10.1.1): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 88d6 0 0000 3f 01 d753 10.10.1.102 8.8.8.8
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
92 bytes from usg (10.10.1.1): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 13c1 0 0000 3f 01 4c69 10.10.1.102 8.8.8.8
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
^CRequest timeout for icmp_seq 8
Request timeout for icmp_seq 9
^C
--- 8.8.8.8 ping statistics ---
11 packets transmitted, 0 packets received, 100.0% packet loss
kevin@MBP15 ~ %
Last login: Fri Aug 7 16:25:48 on ttys000
kevin@MBP15 ~ % ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
92 bytes from usg (10.10.1.1): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 1f35 0 0000 3f 01 40f5 10.10.1.102 8.8.8.8
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
92 bytes from usg (10.10.1.1): Destination Host Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 5400 0d8b 0 0000 3f 01 529f 10.10.1.102 8.8.8.8
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
^C
--- 8.8.8.8 ping statistics ---
9 packets transmitted, 0 packets received, 100.0% packet loss
kevin@MBP15 ~ %
08-07-2020 08:49 PM
What firmware is your new replacement modem on? Is it on 36T8 or 7.1.1.32? 7.1.1.32 is problematic in bridge mode contrary to what the folks at Rogers seem to believe.
08-07-2020 11:48 PM
don't know the firmware version yet, need to re-enable the gateway mode for checking.
the issue happened with my old modem also, but the one was working fine for almost 2 years, so I guess the issue is not modem related.
08-08-2020 12:06 AM
08-08-2020 12:07 AM
@KCheng you don't have to re-enable Gateway mode to check the version. Simply log into the modem using 192.168.100.1 as the login address. That address will work when the modem is in Bridge mode. If the modem doesn't respond to the login attempts, thats an indication that version 7.1.1.32 is loaded. Pull the power from the modem, wait for 10 to 15 seconds and plug it back in. That forces a restart/reboot. You should be able to log into the modem after the restart is complete.
After you have logged into the modem, navigate to the STATUS .... DOCSIS WAN tab. Copy the entire signal table, starting at the Downstream Overview line and go all the way down the very bottom right hand corner of the table, which is the OFDM/OFDMA section. Select or highlight that entire area, right click .... Copy. In a new post, right click .... Paste. That should paste in the entire table as it appears in the modem's UI.
Ideally you should be able to log into the modem at any time, but, version 7.1.1.32 is proving to be a problem. Try to log in first to see if you can actually get past the login. If that fails, the restart the modem. I'd prefer to see the signal data prior to the restart if possible. Restarting the modem will temporarily clear up signal issues, unless they are really bad, so, its important to be able to see that data when the modem has been running for a period of time and misbehaving at that point.
08-08-2020 12:22 AM
08-08-2020 12:28 AM
08-08-2020 12:28 AM
Receiver | FFT type | Subcarr 0 Frequency(MHz) | PLC locked | NCP locked | MDC1 locked | PLC power(dBmv) |
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Bandwidth |
1 | 36996000 | 64QAM | 44.270 | 4 | 6400000 |
2 | 22100000 | 64QAM | 45.510 | 1 | 3200000 |
3 | 30596000 | 64QAM | 45.770 | 3 | 6400000 |
4 | 25300000 | 64QAM | 45.510 | 2 | 3200000 |
5 | 0 | QAM_NONE | - | --- | 1600000 |
6 | 0 | QAM_NONE | - | --- | 1600000 |
7 | 0 | QAM_NONE | - | --- | 1600000 |
8 | 0 | QAM_NONE | - | --- | 1600000 |
Channel Index | State | lin Digital Att | Digital Att | BW (sc's*fft) | Report Power | Report Power1_6 | FFT Size |