No Ranging Response received - T3 time-out

Need Help?

That's what we're here for! The goal of the Rogers Community is to help you find answers on everything Rogers. Can't find what you're looking for? Just ask!
cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Highlighted
I Plan to Stick Around
Posts: 8

Re: No Ranging Response received - T3 time-out

I fail to see how this could be related to my home network. The modem is sending a request out to the Rogers network and isn't receiving a response. I never have any problem connecting to the modem through my network, nor do I have issues with LAN connectivity while this happens so I'm inclined to think the issue is outside my home network. The modem can say "Wan is up" all it likes, doesn't always make it true.
Highlighted
I'm Here A Lot
Posts: 5

Re: No Ranging Response received - T3 time-out

I have exactly the same problem but just found out that my phone modem also reboots the same time as Internet Modem. Anybody having Rogers phone and Internet please check your phone modem when you getting Internet Modem rebooting.

Highlighted
I've Been Here Awhile
Posts: 2

Re: No Ranging Response received - T3 time-out

unhealthy DOCSIS Logs
 
i'm not sure if there is any issues in my area but when i check my DOCSIS Logs thats what i see. i would like a recommendation about what are the errors and if i need to change anything. thank you DOCSIS Logs
 

The DOCSIS event logs are shown here

No. Time Type Priority Event
1 08/03/2020 14:37:14 74010100 Notice CM-STATUS message sent. Event Type Code: 5; Chan ID: 2; DSID: N/A; MAC Addr: N/A; OFDM/OFDMA Profile ID: N/A.;VER=3.1;
2 08/03/2020 17:37:17 82000200 Critical No Ranging Response received - T3 time-out;VER=3.1;
3 08/03/2020 22:02:54 82001200 Warning RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW;CM-VER=3.1;
4 08/04/2020 02:34:10 66030111 Alert CM Certificate Error;VER=3.1;
5 08/04/2020 02:46:22 90000000 Warning MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;VER=3.1;
6 08/04/2020 02:46:25 73050400 Warning REG-RSP-MP Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-VER=3.1;
7 08/04/2020 02:46:33 66030111 Alert CM Certificate Error;VER=3.1;
8 08/04/2020 03:59:34 82000200 Critical No Ranging Response received - T3 time-out;CM-VER=3.1;
9 08/04/2020 16:19:23 82001200 Warning RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW;CM-VER=3.1;
10 08/04/2020 17:34:13 82000200 Critical No Ranging Response received - T3 time-out;CM-VER=3.1;
11 08/04/2020 18:23:41 66030111 Alert CM Certificate Error;VER=3.1;
12 08/04/2020 21:52:10 82001200 Warning RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW;VER=3.1;
13 08/05/2020 00:34:05 90000000 Warning MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-VER=3.1;
14 08/05/2020 00:34:08 73050400 Warning REG-RSP-MP Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-VER=3.1;
15 08/05/2020 00:34:16 66030111 Alert CM Certificate Error;CM-VER=3.1;
Highlighted
Moderator
Moderator
Posts: 2,251

Re: No Ranging Response received - T3 time-out

Good evening @mohdkatlash,

 

Welcome to the Rogers Community and thanks you for your post! I hope you're doing well and staying safe. 🙂

 

We appreciate you took the time to share these findings with us regarding your internet service. Are you experiencing any issues with your service, at this time?

 

The ideal to do would be to describe us the symptoms that occur when you notice time-outs along with the troubleshooting steps you perform?

 

We definitely want to assist you with resolving this matter as soon as possible. Looking forward to your reply!

 

RogersMaude

Highlighted
I've Been Here Awhile
Posts: 2

Re: No Ranging Response received - T3 time-out

Hello

 

Thank you for your reply first, and same goes out to you. 

 

And yes i am experiencing issues, the service seem to stops many time during the day as if the internet freeze and for troubleshooting steps mostly i just unplug the router for couple of minutes and plug it again. i am not an expert when it comes out to this thats why i was hoping to find a solution to this issue here 

 

 

Highlighted
Moderator
Moderator
Posts: 58

Re: No Ranging Response received - T3 time-out

Thanks for posting the DOCSIS logs in the previous post @mohdkatlash.

 

Would you please log into the modem and navigate to Status/DOCSIS WAN and post the Downstream, Upstream and OFDM sections so that we can examine the signal levels?   

 

Awaiting your reply. 

RogersRob
 

Highlighted
I Plan to Stick Around
Posts: 14

Re: No Ranging Response received - T3 time-out

I've also been experiencing these errors for a while with intermittent internet connection and latency issues.

The errors I get include the T3 timeouts, DHCP RENEW WARNING - Field invalid in response v4 option, CM certificate error, but also a new one that I haven't seen before, RNG-RSP CCAP Commanded Power in Excess of 6 dB below the Value Corresponding to the Top. 

In my last discussion with support they weren't aware of the last RNG-RSP error or what it might indicate, is this something that might point to any issue?  I can't find any explanation of what it might mean. 

In the past few weeks we've also had issues with accessing our 192.168.0.1 page, which gets stuck in a loading loop and never loads, unless the modem is unplugged and then plugged back in, which gives us access to the page for about 24 hrs before it gets stuck in loading loops again.

We've been suggested to swap out our modem to see if it might be the issue, but we received an older CGN3 unit, and we have been using a CODA-4582, so I'm reluctant to go through the process of swapping it over at the moment.  Just hoping to see if these error logs, particularly the newer RNG-RSP error might help pinpoint something before doing a bunch more work.

Highlighted
Resident Expert
Resident Expert
Posts: 6,985

Re: No Ranging Response received - T3 time-out

@RLMS there is a new firmware version, 7.1.1.32 that is loading on 4582 modems across the network.  That version is responsible for the unusual alerts that you were seeing, and for the inability to log into the modem after a period of time.  @RogersIan is aware of the access issues and loss of log events which are recovered after a modem reboot is done.  Version 7.1.1.32 is built on a new kernel to support DOCSIS 3.1 upstream.  The initial release was .30, .32 is loaded now, and one of these days the next version should show up.  @RogersIan really needs to explain to the crowd what the event log errors mean and what to do about them. 

 

That modem shouldn't be the cause of any disconnects.  Having said that, the 4582 modem uses a DOCSIS 3.1 Orthogonal Frequency Division Multiplex (OFDM) channel for its downstream data which runs in the 300 to 500 Mhz range these days.  There isn't enough data presented to the user to asses the health of that OFDM channel, so, it really requires a message to @CommunityHelps, specifically @RogersAndy to check the OFDM data in order to determine if a problem exists within the OFDM channel. 

 

The CGN3 modems do not use an OFDM channel as they are not fitted with the hardware to use OFDM data transmission.  The result of that is that the CGN3 modems use upstream DOCSIS 3.0 channels which run in the 5 to 42 Mhz range and DOCSIS 3.0 downstream channels in the 500 to 900 Mhz range, possible slightly higher.  

 

So, because of the difference in frequency ranges used by the modems on the downstream side, you might not see any issues with the modem.  That would or should confirm that your cable system has problems in the 300 to 500 Mhz range, for which there aren't enough data points with a CGN3 modem to make a proper assessment.  That would require a field tech to check with the proper test equipment.  

 

If you see the same intermittent internet connection and latency issues, that points to an issue with the upstream channels running in the 5 to 42 Mhz range.  Latency could be a network issue which has been seen since January.  Rogers has been and continues to be totally radio silent on the network problems that a good number of users, both Rogers and TPIA customers have seen.   

 

Ok, so, fwiw, if you have the patience and time, log into the modem, navigate to the STATUS .... DOCSIS WAN tab and copy the Downstream and Upstream data, starting with the Downstream Overview line.  Select or highlight that entire table region in one go, right click .... Copy.   Then in a new post, right click .... Paste.  That should paste in the table, as is seen in the modem's UI.  Disregard the data that sits above the signal table, as that is specific to the modem and shouldn't be posted in an open forum. 

 

Personal opinion, I'd go back to the 4582 in order to use the OFDM downstream channel.  It should give you better performance on the downstream side.  Now, that does depend on the health of that channel, which at this point is an unknown factor.  One of these days Rogers will throw the switch and enable OFDM upstream.   When is a good question.  



Highlighted
I Plan to Stick Around
Posts: 14

Re: No Ranging Response received - T3 time-out

Thanks so much for the in depth response!  Ok good to know that is the cause of the new error, it was something I hadn’t seen in months of looking at the logs and the issue with not being able to access the modems login was new to me as well.  Hopefully we can get some more info on that over time.

 
I appreciate the info in regards to looking into the OFDM channel as well, I’ll reach out to see if they can verify that all is well in regards to that.
 
I had a feeling the CGN3 wouldn’t have the same technology and features as the newer CODA unit, we will let them know we are hoping to return the CGN3 and if they wish to send a new unit to confirm the modem we have isn’t a cause of any of our problems we’ll ask if they can send a 4582. 
 
We’ve been experiencing issues since around January so I have a feeling that it is likely related, but prior to a few tech visits earlier this year, some of our issues related to external RG6 (which when replaced improved our ping spikes from 7000ms to 250ms) and I’d read a month or two ago that some people in the latency discussion on the forums saw the issues lower in frequency and in some cases seemed solved, it just hasn’t been the case for us so I wondered if it could be possible we still have issues on our end.  I really hope they’ll disclose something in regards to that, as it has been quite a long road and lots of time spent trying to figure this out that could be saved if I knew the issue wasn’t on our end.
 
I’d be glad to post the chart and see if anything looks out of the ordinary, here it is as of today after replugging the modem to gain access to the page.
 
Downstream Overview
Port IDFrequency (MHz)ModulationSignal strength (dBmV)Channel IDSignal noise ratio (dB)
1651000000QAM2563.0001640.946
2591000000QAM2562.000740.366
3597000000QAM2562.599840.366
4849000000QAM2565.500240.366
5855000000QAM2565.900340.946
6861000000QAM2565.699440.366
7579000000QAM2561.799540.366
8585000000QAM2561.599638.983
9603000000QAM2562.400940.946
10609000000QAM2562.0991038.983
11615000000QAM2562.2991140.366
12621000000QAM2562.5001240.366
13633000000QAM2563.4001340.946
14639000000QAM2563.2991440.946
15645000000QAM2563.0991540.366
16279000000QAM256-1.700138.983
17657000000QAM2563.5001740.366
18663000000QAM2563.7001840.366
19669000000QAM2563.7991940.946
20675000000QAM2563.5992040.366
21681000000QAM2563.5992140.366
22687000000QAM2563.7992240.366
23693000000QAM2564.1992340.366
24699000000QAM2564.4002440.366
25705000000QAM2563.9002540.366
26711000000QAM2563.7992640.366
27717000000QAM2563.7992740.366
28723000000QAM2563.9002840.366
29825000000QAM2565.5002940.946
30831000000QAM2565.1993040.366
31837000000QAM2565.0993140.946
32843000000QAM2565.0993240.366
OFDM Downstream Overview
ReceiverFFT typeSubcarr 0 Frequency(MHz)PLC lockedNCP lockedMDC1 lockedPLC power(dBmv)
0NANANONONONA
14K275600000YESYESYES-0.200001
Upstream Overview
Port IDFrequency (MHz)ModulationSignal strength (dBmV)Channel IDBandwidth
13699600064QAM46.27086400000
22210000064QAM45.26053200000
33059600064QAM46.27076400000
42530000064QAM45.26063200000
50QAM_NONE----1600000
60QAM_NONE----1600000
70QAM_NONE----1600000
80QAM_NONE----1600000
OFDM/OFDMA Overview
Channel IndexStatelin Digital AttDigital AttBW (sc's*fft)Report PowerReport Power1_6FFT Size
0DISABLED0.00000.00000.00000.00000.00002K
1DISABLED0.00000.00000.00000.00000.00002K
Highlighted
Resident Expert
Resident Expert
Posts: 6,985

Re: No Ranging Response received - T3 time-out

Are you running any other Rogers services such as Nextbox's or Home Phone?   I'm wondering about that as your DOCSIS 3.0 upstream channels are higher than normal, which is around 30 to 32 dBmV.  A splitter installed for multiple services would or could explain that difference in output power levels.  Or, this could be a result of the new firmware.

 

Ok, so, the upper DOCSIS 3.0 channels (1 to 32) look ok.   Your signal levels are fine as are the signal to noise ratios.  The signal level low point is at 279 Mhz at -1.7 dbmV, next point after that is 579 Mhz at 1.799 dBmV.  That covers the entire OFDM range, so there's an upwards signal slope running.  Question is, does it break the allowable limits?  @RogersAndy would be able to tell you that.  Beyond that, above 750 Mhz, the signal levels rise, which is unusual, nice to see as they usually drop, so it looks like Rogers has done some work in your area replacing old equipment.  Given that the modem's OFDM channel is running, these DOCSIS 3.0 channels aren't used.  

 

The OFDM channel might be ok, but, there isn't enough data to really know.  @RogersAndy will have to let you know. 

 

Your upstream channels are running higher than normal, as indicated above, but, again, part of that might be caused by a splitter, which drops the signal levels in both directions.  As a result, the Cable Modem Termination System (CMTS) commands the modem to run higher upstream levels to counteract the upstream signal drop due to the splitter. 

 

The problem with having to unplug and plug the modem back in is that it causes the signal levels to return to their normal levels, even if there is a problem with the external cabling.  The one exception would be if the external cables and connectors were severely degraded.  Prior to reaching that point, a modem reboot/restart can temporarily resolve cable issues, but it doesn't solve the underlying problems that exist with the cabling or its connectors.  Ideally one has to be able to log into the modem at any time to review the signal data, looking for any possible problems.  For now, the user interface is not operational after a period of time, but it appears that tech support and the moderators would be able to see that data via the TR-69 path into the modem.  Not ideal, but, that works.  We're going to have to wait for the next firmware version (I hope) to see this situation corrected. 

 

So, for now, just following a modem restart, the signal levels look ok.  Give that a few hours and try to log back into the modem to grab the signal levels again, just to see if their starting to diverge from the data shown above. 

 

Hunting for intermittent connections and latency:

 

First step, look for lost packets between the modem and CMTS, using a pc or laptop connected via ethernet to the modem or router.  This can't be done via wifi due to wifi's usual losses that occur.     

 

1.  Run a trace to anywhere, for example to google:      tracert -4 www.google.ca

 

2.  With the modem in Gateway mode, or the modem in Bridge mode with a router behind it, the first IP address in the trace is the modem, or router, depending on what the modem operating mode is.  The second IP address is the CMTS.  Use this address to ping the CMTS.

 

3.  Ping the CMTS using that address and run the test for at least an hour, longer if you prefer:

 

ping -n 3600 xxx.xxx.xxx.xxx         where xxx.xxx.xxx.xxx is the trace's second hop IP address.   

 

That test will run for one hour and then terminate.  Ignore the higher return times as they will be due to an internal modem timing issue introduced in version 2.0.10.27.  That issue is also present in new firmware version.  The question is, what's the lost packet count?

 

4.  You can run that test for several hours by using:

 

ping -t xxx.xxx.xxx.xxx            You will need to use     Ctrl c      (simultaneous use) to bail out of the test.

 

 

To look for packet loss and potential latency, ping the Rogers primary IPV4 DNS address:   64.71.255.204

 

Ping -n 3600 64.71.255.204      Once again that will run for one hour and terminate automatically.  Run that for a long er period by increasing the "3600" figure, or use:

 

ping -t 64.71.255.204

 

For the ping test to the CMTS and DNS, you should be at or less than 0.1 % losses.

 

For the ping test to the DNS, you should in a 9 to 13 milli-second range for an average.  If you take a glance at the test occasionally you should not be seeing regular high time ping times.  But, once again, we're in that situation that you noted since January where packet loss and high latency have been observed by Rogers and TPIA customers.  

 

 

To copy the results from the command box, right click on the top title bar of the command box and select Edit ..... Select All.  Right click again and select Edit .... Copy.  Then you can paste that data into something like notepad so that you can grab the bottom results and paste those results into a post.

 

Also to note, it appears that Rogers has a throttling policy on the go, for which I haven't seen any official notice.  It appears to be Covid related, but no one but Rogers employees probably know the details.  There are standing terms and conditions that Rogers has in the event that you're a bandwidth hog, but, this appears to go beyond those stated terms and conditions.  If you use remote backups, tying up a lot of upstream bandwidth over the course of a 24 or 48 hour period, you will find your upload rates throttled back to somewhere around 5 Mb/s or so for at least 24 hours, perhaps longer.  This is an anecdotal observation by other users, both Rogers and TPIA.  This is where @CommunityHelps should step in and clear the air, so that everyone knows what the policy actually is.  

 

Ok, that should do it for now, personal opinion I'd keep the 4582 and return the CGN3.  Any odd results that you see for packet loss or latency won't be due to the modem, unless its tied to poor performance of the OFDM channel.  In that case the correct solution is to dispatch a tech to resolve the cable / connectors issues or any issues further upstream, and not avoid the issue by switching to the CGN3 which uses the higher frequency SC-QAM channels for its downstream data.  Fix the problem instead of avoiding it .......