CODA-4582 - Open Issues for Investigation

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
HughR
I Plan to Stick Around
Posts: 43

Re: CODA-4582 - Open Issues for Investigation

@wes162

 

Thanks for your report.  It helps me learn about this system.  I'm not up on cable signaling, so I looked up a couple of things.

 

OFDM is Orthogonal frequency-division multiplexing

 

The "lock" is as in "phase-locked loop", i.e. that the modem is synchronized with the upstream signal.

 

It is not a lock in the sense of a computer program.  But it is a computer program that is reporting the lock status.

 

So: there could be a firmware bug reporting the locking status.

 

I would *guess* (and I'm not qualified to do so) that the actual locking is in hardware, not software (firmware).  At least some of it would be analogue.  But some bits might be in software.

 

Rogers seems to have done a lot to eliminate any problem between your modem and the stand.  Are there any other customers on your segment with the CODA?  Are they having problems (they might not notice -- people put up with a lot)?

 

I haven't noticed a lot of CODA customers reporting this problem.  Maybe we don't know how to find out if OFDM lock has been lost (I don't).  But it suggests that it's not one of these easy-to-diagnose black and white problems with every CODA.

 

Good luck: 4 months is  along time.

wes162
I Plan to Stick Around
Posts: 9

Re: CODA-4582 - Open Issues for Investigation

I am not privy to issues with other customers in the area but I have heard mixed things from the Rogers people working on the file.  Some say they do notice issues, mostly with erratic or jittery pings that most people would not notice unless they were gaming or using other latency intense applications, other techs have said they do not see area issues.  There was some area "noise" which Maintenance attributed to a rogue modem, but that tech said it would only have affected upload speeds, not download.

 

The issue with CODA CM's losing OFDM lock is a well known issue.  The initial post of this thread asks for people to comment on it, which is why I posted here in the first place.  There are other posts, on this thread and others, from other Rogers customers experiencing similar symptoms (ie. fast download after reboot followed by decay).  Not everyone gets into the nitty gritty of why the speeds decay.  Unfortunately out of necessity, I have had to.

daveinsurgent
I Plan to Stick Around
Posts: 43

Re: CODA-4582 - Open Issues for Investigation

Hi @wes162 - I noticed that my modem also obtains an OFDM lock on boot, and then loses it. However, my speeds are not impacted as far as I can tell. They vary wildly from 400 to 870Mbps (wired, to different speed tests sites and as an aside, I have been fighting an issue of packet loss for months now.

 

I had a tech come out today, and I pointed out the OFDM behavior and he said the OFDM lock is irrelevant has no impact on performance at all.

 

It seems very, very hard to get a straight answer out of all the 'superstition' among the different people we are forced to interact with as Rogers customers 😕

 

Datalink
Resident Expert
Resident Expert
Posts: 7,238

Re: CODA-4582 - Open Issues for Investigation

@daveinsurgent, did the tech do anything to address the packet loss issue?  

 

If the modem is in fact losing the ability to process the OFDM channel after a period of time, that would point to an cable/connector issue in the 200 to 500 Mhz range, where the OFDM channel is running.  This should be a simple process of elimination.  Are your neighbors modems (if they are 4582's) running in DOCSIS 3.1 mode.  If yes, then that points to an issue with your cable or potentially with the port on the local tap.  If the answer is no (and there are other 4582's connected to your local tap), then that points to an issue with the tap itself or with the infrastructure between the tap and the CMTS.  

 

Rebooting the modem, followed by successful operation, either in DOCSIS 3.0, or 3.1 mode points to some type of cable or connector issue.  The reboot will temporarily resolve the problem, but it does nothing to address the underlying cable/connector fault.  

 

The time to call tech support is when the modem has lost its OFDM processing.  In theory, its running DOCSIS 3.0 at that point and the question is, what about the other modems connected to the same local tap.  Are there any 4582s connected to that same local tap, and are they running in DOCSIS 3.0 or 3.1 modes?  The answer to that question would point to the source of the problem.  That's an easy check for tech support to carry out.   The answer to that question will also indicate what level of tech is required to resolve the issue, contract tech, Rogers tech or a Maintenance Crew. 

 

The tech statement that "OFDM lock is irrelevant" points to one of two things, 1: that the modem's indication of OFDM processing can't be relied upon for some reason, or 2: that the tech has absolutely no clue as to why DOCSIS 3.1 has been developed and is being implemented by MSO's around the world.  If that's a typical tech attitude, then those techs that hold that opinion aren't doing Rogers any favors these days, personal opinion.  I'm sure that not all techs hold that opinion, but its disheartening to hear that. 

 

Edit:  In a manner of speaking, the tech statement that "OFDM lock is irrelevant" could probably considered as partly correct if the modem simply switches over to DOCSIS 3.0 and runs the same data rates, but, that still completely defeats the pupose of developing DOCSIS 3.1 in the first place, along with all of the expense and trouble to develop the 3.1 CMTS equipment and modems and introduce them into service, not only with Rogers, but with any other MSO. 



daveinsurgent
I Plan to Stick Around
Posts: 43

Re: CODA-4582 - Open Issues for Investigation

Holy quick reply batman!

 

The (contract) tech snipped and re-crimped the leads of the coax cable coming in to my utility room, and replaced the pad that was installed by the first (contract) tech on Thursday; he said that pad must have been defective. He went outside to the box on the side of my house and said he made sure the ground was good. He said he can't really troubleshoot issues like packetloss, and that any configuration changes to the CODA-4582 gateway after a factory reset should be considered unsupported/unsustainable, especially putting it in to bridge mode and using a different router, since it's "pushing the modem to do things it can't do", and that this is always the cause of peoples problems.

 

Sorry, I was paraphrasing earlier: he specifically said that OFDM was not used and it going on and off is "Just Rogers doing stuff".

 

 

Datalink
Resident Expert
Resident Expert
Posts: 7,238

Re: CODA-4582 - Open Issues for Investigation

Grrr, I won't say what comes to mind.  Those statements would imply that the default parameters are the only parameters that he is willing to accept.  What happens when the engineering staff change the default parameters?  What does he say in that case?  

 

Ok, just to play ball here, if you run the modem in Gateway mode and still have packet loss to the DNS, then you're meeting his restrictive interpretations of what is or is not supported and if you still have packet loss to the DNS, then you're proving that he didn't resolve the issue.  Has the external cable been replaced at any stage of this problem, and is it underground to the local tap, or overhead to a utility pole?  If you're in a period of time where you see packet loss as a regular occurrence, we're talking an occurrence every few seconds or so, call tech support and ask the CSR to ping the modem from the CMTS, or ping the CMTS from the modem.  Either one will do.  When you see packet loss, then the CSR should also see packet loss.  That should be enough to convince the CSR that the problem still exists and that its time to dispatch a senior tech.  Beyond that its time to get @CommunityHelps involved to dispatch a senior (Rogers) tech. 

 

Fwiw, my own testing with the 4582 in Bridge mode with two routers connected results in very little packet loss over the course of a 24 or 48 hour test run, usually well under 0.1%, sometimes less than 0.01%. 



daveinsurgent
I Plan to Stick Around
Posts: 43

Re: CODA-4582 - Open Issues for Investigation

This is certainly an exercise in social engineering as much as it is anything.

 

Depending on who you talk to, there is a reason for everything.  They "ping the modem from their internal tools", which I don't fully understand. Like, I understand it as a mechanism of troubleshooting -- for example, if the modem internal IP (the 7.x.y.z number) does not respond, then boy we have a problem! But if it does work fine, that doesn't disprove the existence of an issue, know what I mean?

 

If the ping to the Rogers DNS shows problems (which it does), then it's just that that DNS that's a problem, and I have to try google. If google works - for a short period of time - then it's proof I don't have an issue. If Google does have an issue, over a longer time frame, then it's a sign that ICMP is an unreliable troubleshooting protocol and I have to go to the Rogers Speedtest and "that seems to be working and I don't see any signal issues".

 

I'm capable and possibly willing to write my own custom client-server test software, and run it in a few AWS regions, just to test non-ICMP delivery reliability...

Datalink
Resident Expert
Resident Expert
Posts: 7,238

Re: CODA-4582 - Open Issues for Investigation

Ok, can you have a look at the IP address for the modem or the router, depending on what you currently have in place.  If you log into the modem, with it running in gateway mode, you should see two addresses in the upper right hand corner of the STATUS data block.  Those should be an IPV4 address followed by a much longer IPV6 address.  If you're running the modem in Bridge mode with a follow-on router, check the external IP address.  Looking back at your trace, the second hop address (CMTS) is 174.114.112.1, so your IP address should be 174.114.112.xxx, as in anywhere from .2 to .254 if I'm correct here.  I just want to ensure that the CMTS address makes sense considering what your modem or router IP address is.  Assuming that the IP addresses make sense, that would definitely indicate that the CMTS address is a 174 address, although its not what I'm expecting to see.  So, roll with it and lets see where this leads.  Ping the CMTS, looking for packet loss.  Ignore the return times for now.  Lets assume for the sake of the argument that the IP numbers are correct at this point.  If they didn't match up, then that is another issue altogether.  Just run the ping test and lets see how this turns out.  

 

You can also do the same using IPV6.  Run an IPV6 trace:  tracert -6 www.google.com   If your pc is running IPV6, then you should see the entire trace from start to finish with IPV6 addresses.  Same as before, the first hop is the modem if its running in Gateway mode, 2nd hop is the CMTS.  If the modem is in Bridge mode with a follow-on router, first hop is the router, 2nd hop is the CMTS.  Ping the CMTS using the IPV6 address, again, looking for packet loss. 

 

Beyond that, if you wanted to ping the DNS using TCP/IP, download tcping64 from:

 

https://www.elifulkerson.com/projects/tcping.php

 

A command line to use, if you want to try this is: 

 

tcping64.exe -t -i 1.0 -d --tee c:\temp\tcping29jan.txt 64.71.255.204 53

 

That runs a tcp/ip ping to the 64.71.255.204 dns port 53

-t runs the ping test until stopped with a Control^C

-i 1 run the test once per second.  tcping64 will run intervals less than 1 second:  -i 0.50 for example runs every 500 ms.

-d prints a time stamp on every line

--tee c:\temp\tcping29jan.txt    writes the results to a text file as well in the c:\temp directory, if you have such a directory set up.  If you don't want the text file, delete this command 

 

So, beyond the CMTS, running a TCP/IP test to the DNS will indicate if there are packet loss issues within the Rogers network.  

 

If you want to do this with a DNS lookup to test UDP thru the modem, I can let you know how to run that as well.  I use a script to run a lookup, using the Rogers DNS, or any other DNS as the target DNS. 

 

 

 

 



daveinsurgent
I Plan to Stick Around
Posts: 43

Re: CODA-4582 - Open Issues for Investigation

Cool. I engaged Facebook support - another plug for them being very responsive and candid. They could not connect to my modem - as usual. What seems to happen is after it's been up for 30 minutes or so, something happens. I don't understand anything about cable technology enough to even begin to guess or pretend, but the OFDM lock disappears from the web GUI and support says they can't connect to my modem or that it appears offline, etc. -- this is the same behavior with the original modem and the replaced modem, as well as the changes that the two different on-site techs made (re-crimping wires, checking grounds, etc.)

 

While that was all going down, I decided to just go back to square 1 and really check my internal network out. I have iperf3 installed on all of my computers.

 

Here's a professional-grade image/diagram of my network topology:

 

map - Copy.png

 

I can ping 192.168.0.3 (the X4S in AP mode) as well as 192.168.0.2 (the switch) and 192.168.0.1 (the CODA in Gateway mode) aggressively (0.1 interval) and its 0% loss, rock solid, 0.5xx ms worst case ping.

 

I installed iperf3 on just about everything that I could, and I can run aggressive tests between D1 and D2, as well as D1 and S1 / D2 and S1 -- iperf3 -t 60 -u -b 0 --udp-counters-64bit -c {{ip}} spits out things like:

 

[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-60.00 sec 6.66 GBytes 953 Mbits/sec 0.030 ms 0/872558 (0%)
[ 4] Sent 872558 datagrams

 

I may get the occaisional lost packets, like 0.000x% (13 out of 1.75 million was the highest or "worst" run)

 

I feel like my internal network is "rock solid".  Even my MacBook - so L1 to S1,  pulls an iperf of 628Mbit/sec TCP and UDP:

 

[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-30.00  sec  2.10 GBytes   600 Mbits/sec  0.000 ms  0/1553838 (0%)  sender
[  5]   0.00-30.00  sec  2.10 GBytes   600 Mbits/sec  0.029 ms  0/1553838 (0%)  receiver

 

I think most people would be very happy with such characteristics internallly. I am going to look in to doing UDP/TCP testing of DNS etc. as you've suggested, but after rebooting my modem (in the span of writing this post) its already gone back to losing the OFDM lock and being unresponsive to remote support! Which I think is a good thing, because they're fixing to send a senior ("Rogers"?) tech!

 

** Edits **

 

The hop after my modem on a traceroute (my CMTS I guess) is 174.115.212.1 -- it's always "174.115.(X-1).1" if that formula makes sense - so my WAN IP is currently 174.115.213.#

daveinsurgent
I Plan to Stick Around
Posts: 43

Re: CODA-4582 - Open Issues for Investigation

Well, the adventure continues.

 

The third tech visit was not a Rogers-branded one, but still a third party contract. However I absolutely believe he was senior as the Facebook Chat agent indicated, because he immediately started telling me things that were useful, rather than telling me things that he didn't know about or weren't his job, etc.  -- so big +1 to this individual.

 

What's really interesting is he also told me a bunch of stuff completely contradictory - but far more believable - than what I've been told.

 

This tech: There are many modems in your area that are showing up unresponsive, and I am not sure why

Support: I looked in your area and your modem is the only one offline/not responding

 

This tech: There's noise/interference in your area that a technical team is trying to hunt down but currently does not know the source of, and the node / CMTS you connect to has concerning noise and issues as well

Support: Your area is fine

 

This tech: Losing OFDM is concerning, but it would not affect your download speeds. It would affect your upload speeds

Other tech: OFDM does not matter, it is not used

 

This tech: The line from your CME to the road box is faulty, must be replaced, and we need to run a temporary line from your neighbour until spring. Only after we install the temporary line can we continue to troubleshoot any remaining issues with packetloss - also why aren't you using the modem in bridge mode given the router that you have?

Other tech: There's no problem, we don't deal with packetloss, you must use the modem in gateway mode and not change settings

 

So, happy that I have someone who will help, but it looks like this is really the beginning of the actual troubleshooting.