01-25-2019 05:15 PM - last edited on 01-25-2019 06:09 PM by RogersZia
I have been experiencing intermittent disconnects of internet service for a few minutes at a time and have replaced the CODA-4582U with no improvement. The modem is is bridged mode and after reading some of the other posts I believe there may be a signal issue. I was able to capture the following info from the DOCSIS Event log today and was hoping someone could interpret and point me in the right direction to resolve the issue.
Thanks for your help.
**Removed logs due to Community Guideline: Keep personal info private. - RogersZia**
***Edited Labels***
Solved! Solved! Go to Solution.
03-17-2020 05:26 PM - edited 03-17-2020 05:41 PM
Yup, connect the TP-Link to the modem and then connect to the TP-Link.
Use 192.168.100.1 thru the router. You can also use that with a direct connection to the modem when its in Bridge mode.
I don't encourage a direct connection to the modem when its in Bridge mode due to the constant port scanning by various miscreants scattered across the internet, probing for open ports or mis-configured firewalls.
With V2.0.10.36T6, in the modem as indicated on the status page, you can use 192.168.01. or 192.168.100.1 when the modem is in Gateway mode. When its in Bridge mode you can only use 192.168.100.1, which will normally work thru any connected router. There are exceptions but they are few and far between, so to speak.
With V7.1.1.30 loaded you can only use 192.168.0.1 when the modem is in Gateway mode and only use 192.168.100.1 when the modem is in Bridge mode.
03-17-2020 05:51 PM
03-17-2020 07:25 PM
@MD83 there are a few ways to do this.
First:
1. connect directly to the modem, even though I'm not a huge fan of this.
2. As soon as the pc/laptop gains an IP address, log into the modem using 192.168.100.1 I'm assuming that the modem is stuck in Bridge mode.
3. kick the modem back into Gateway mode when you've managed to log in.
Second:
Call tech support and ask the CSR to switch your modem back into Gateway mode
Third.
Reset the modem. Ugh. Depress the recessed reset button at the back of the modem for at least 15 seconds. It should reset the modem, at which point the modem will reboot into Gateway mode. Unfortunately you would have to set the modem up from scratch.
With the modem in Bridge mode, if you rebooted the TP-Link router it should pick up its assigned external address from the modem and you should be able to use 192.168.100.1 to access the modem's login page. If you can't, then the TP-Link is blocking the path out to the modem. Usually thats taken care of by defining a route out to the modem, but, I don't know if the TP-Link will let you do that.
03-17-2020 08:44 PM - last edited on 03-17-2020 09:15 PM by RogersMoin
System Information
This menu displays general information of the device
Hardware Version 1A
Software Version 2.0.10.36T6
System Time Wed, 18 Mar 2020 01:40:55
Time Zone UTC+00:00 Greenwich Mean
Downstream Overview
Port ID Frequency (MHz) Modulation Signal strength (dBmV) Channel ID Signal noise ratio (dB)
1 591000000 256QAM 9.800 7 38.605
2 597000000 256QAM 9.800 8 38.605
3 603000000 256QAM 9.700 9 38.605
4 849000000 256QAM 7.100 2 37.356
5 855000000 256QAM 6.500 3 36.610
6 861000000 256QAM 5.800 4 36.387
7 579000000 256QAM 9.700 5 38.605
8 585000000 256QAM 9.800 6 38.605
9 279000000 256QAM 7.000 1 37.636
10 609000000 256QAM 9.600 10 38.605
11 615000000 256QAM 9.800 11 37.636
12 621000000 256QAM 9.800 12 38.605
13 633000000 256QAM 9.600 13 38.605
14 639000000 256QAM 9.500 14 37.636
15 645000000 256QAM 8.900 15 37.636
16 651000000 256QAM 8.800 16 37.636
17 657000000 256QAM 8.800 17 38.605
18 663000000 256QAM 8.700 18 37.636
19 669000000 256QAM 8.500 19 37.356
20 675000000 256QAM 8.700 20 38.605
21 681000000 256QAM 8.400 21 38.605
22 687000000 256QAM 8.400 22 37.636
23 693000000 256QAM 8.700 23 37.636
24 699000000 256QAM 8.700 24 38.258
25 705000000 256QAM 8.800 25 37.636
26 711000000 256QAM 8.700 26 37.636
27 717000000 256QAM 8.600 27 37.636
28 723000000 256QAM 8.400 28 37.636
29 825000000 256QAM 7.300 29 36.610
30 831000000 256QAM 7.400 30 36.610
31 837000000 256QAM 7.000 31 37.356
32 843000000 256QAM 7.200 32 37.356
OFDM Downstream Overview
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 275600000 YES YES YES 9.000000
Will get you trace route soon as I log on my laptop
03-17-2020 08:51 PM - edited 03-17-2020 08:52 PM
@savuser12 can you delete the HFC MAC Address data as it shouldn't be posted to an open forum. Can you also post the upstream channel data that sits below the OFDM channel data. There should be three or four upstream channels running.
03-17-2020 08:56 PM
Got it up and running again. We'll see if the problem still persists, as I assume it will. Any further ideas before the tech comes to check things out. Again, I really appreciate the time and effort given here.
03-17-2020 09:05 PM
@MD83 did you have to nuke the modem to get it back to Gateway mode?
What configuration are you in now, modem in Gateway or Bridge mode, TP-Link in Nat (Gateway) or Bridge mode?
03-17-2020 09:28 PM
@MD83 I'm assuming that Rogers is using that 45.xxx.xxx.xxx block internally, which is a little odd, but, it is what it is.
Just to see whats up, and not worry about any confusion with the modem or TP-Link configuration, try pinging Rogers primary IPV4 DNS: 64.71.255.204
I'd let that run in the background while you're running the normal household internet activities. That might cause higher latency, but, I suspect the family would revolt if you said, "no internet for an hour!" Ok, so, run:
ping -n 3600 64.71.255.204
Lets see how that turns out.
03-17-2020 09:42 PM
03-17-2020 09:44 PM
03-17-2020 09:54 PM - edited 03-17-2020 10:16 PM
03-17-2020 09:59 PM - edited 03-17-2020 10:00 PM
@wsxedc so that's a consequence of running google wifi, it takes over your trace routes?
I couldn't discount the format as I'm by no means aware of all of the trace commands and results available to Rogers customers. Maybe in a few more years 🙂
03-17-2020 10:09 PM
03-17-2020 10:14 PM
03-17-2020 11:05 PM
Sorry, I was getting that from phone and its selected all with copy. There is latest from laptop along with trace route from google. Please analyze and let me know as I have a tech visit tommorow and would like some insight before.
Oh yeah coda 4582 fw ver
Hardware Version | 1A |
Software Version | 2.0.10.36T6 |
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Signal noise ratio (dB) |
1 | 591000000 | 256QAM | 9.900 | 7 | 38.983 |
2 | 597000000 | 256QAM | 10.000 | 8 | 38.605 |
3 | 603000000 | 256QAM | 9.900 | 9 | 38.605 |
4 | 849000000 | 256QAM | 7.200 | 2 | 37.636 |
5 | 855000000 | 256QAM | 6.700 | 3 | 37.356 |
6 | 861000000 | 256QAM | 5.900 | 4 | 36.387 |
7 | 579000000 | 256QAM | 9.900 | 5 | 38.605 |
8 | 585000000 | 256QAM | 9.900 | 6 | 38.605 |
9 | 279000000 | 256QAM | 7.200 | 1 | 37.356 |
10 | 609000000 | 256QAM | 9.800 | 10 | 38.605 |
11 | 615000000 | 256QAM | 9.900 | 11 | 38.605 |
12 | 621000000 | 256QAM | 10.000 | 12 | 38.605 |
13 | 633000000 | 256QAM | 9.800 | 13 | 38.983 |
14 | 639000000 | 256QAM | 9.700 | 14 | 38.605 |
15 | 645000000 | 256QAM | 9.100 | 15 | 37.636 |
16 | 651000000 | 256QAM | 9.000 | 16 | 37.356 |
17 | 657000000 | 256QAM | 9.000 | 17 | 38.605 |
18 | 663000000 | 256QAM | 9.000 | 18 | 37.636 |
19 | 669000000 | 256QAM | 8.800 | 19 | 37.636 |
20 | 675000000 | 256QAM | 8.900 | 20 | 38.605 |
21 | 681000000 | 256QAM | 8.700 | 21 | 38.605 |
22 | 687000000 | 256QAM | 8.700 | 22 | 37.636 |
23 | 693000000 | 256QAM | 9.000 | 23 | 38.605 |
24 | 699000000 | 256QAM | 9.000 | 24 | 38.605 |
25 | 705000000 | 256QAM | 8.900 | 25 | 37.636 |
26 | 711000000 | 256QAM | 8.700 | 26 | 37.356 |
27 | 717000000 | 256QAM | 8.600 | 27 | 37.636 |
28 | 723000000 | 256QAM | 8.300 | 28 | 37.636 |
29 | 825000000 | 256QAM | 7.300 | 29 | 37.356 |
30 | 831000000 | 256QAM | 7.600 | 30 | 37.356 |
31 | 837000000 | 256QAM | 7.200 | 31 | 37.356 |
32 | 843000000 | 256QAM | 7.400 | 32 | 37.356 |
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 | 275600000 | YES | YES | YES | 9.199997 |
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Bandwidth |
1 | 22100000 | ATDMA - 64QAM | 33.250 | 1 | 3200000 |
2 | 36996000 | ATDMA - 64QAM | 28.000 | 4 | 6400000 |
3 | 30596000 | ATDMA - 64QAM | 30.000 | 3 | 6400000 |
4 | 25300000 | ATDMA - 64QAM | 34.500 | 2 | 3200000 |
Channel Index | State | lin Digital Att | Digital Att | BW (sc's*fft) | Report Power | Report Power1_6 | FFT Size |
0 | DISABLED | 0.5000 | 0.0000 | 0.0000 | -inf | -1.0000 | 4K |
1 | DISABLED | 0.5000 | 0.0000 | 0.0000 | -inf | -1.0000 | 4K |
Ping statistics for 172.217.1.164:
Packets: Sent = 3600, Received = 3537, Lost = 63 (1% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 3434ms, Average = 28ms
03-18-2020 12:16 AM
@savuser12 your DOCSIS 3.0 channels (1 to 32) are higher than they should be, arguably within spec, yes, but, then should be down around 0 dBmV. Your QAM levels are ok, the signal to noise ratios are ok as well.
The upstream DOCSIS 3.0 levels aren't too bad where they currently sit.
The DOCSIS 3.1 OFDM channel can't be assessed as the signal level, signal to noise ratio and QAM Level isn't presented to the user. Tech support has access to that data, and I would expect the field techs to have access to that data as well.
My personal opinion about the packet loss in the ping test is that its higher than it should be, but, I base that on my test results from West Ottawa, which are typically well under 1%. The distribution of the high ping times (latency) would be interesting to see and it might be the more important point here. That's something I have to work on to make it easy to accomplish.
On the surface, yes the downstream signal levels are higher than normal, but, given the problems with the Rogers network these days, you might not have any problems caused by local issues. That's really problematic these days, are the problems local, or are they network issues? Really the only thing the tech can do is check the cables and connectors for continuity. That's a minor check and might not do much if anything to address any latency and packet loss that you're seeing 😞
03-18-2020 09:56 AM
03-18-2020 10:11 AM
@Datalink Here are the results of the ping test to the second hop, with the computer plugged directly into the CODA. The test took about two hours to complete.
Ping statistics for 174.115.234.1:
Packets: Sent = 3600, Received = 3178, Lost = 422 (11% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 3981ms, Average = 277ms
03-18-2020 09:30 PM
Slightly off-topic, but would "upgrading " to Rogers Ignite Internet Gigabit" do anything to alleviate my ongoing issues? This at least would replace/upgrade the modem to the Arris XB6 , if that makes any difference at all..?
03-19-2020 11:45 PM
@MD83 I haven't forgotten about you. I just don't know if I can offer any productive advice at this point. Your case looks very much like that of @JSS_BRAMPTON
https://communityforums.rogers.com/t5/Internet/Question-about-Signal-Levels/m-p/458649#M59936
Maybe the solution is to request a tech visit to check for noise issues? Don't know. The modems themselves are equipped to check and monitor for noise and as far as I know there is a noise record kept to each modem, if not minute by minute, maybe every five minutes. Don't know why Rogers can't use that record to initiate further action to resolve upstream noise issues.
03-20-2020 12:05 PM
@Datalink is there anything I could further do (in relation to @JSS_BRAMPTON's case) that might work, ahead of the tech coming over? I started skimming through that thread, but don't know which parts, if any, would apply to my particular situation. Thanks again.