If you're seeing disconnects on ethernet connected devices, my first guess would be a problem with the external cable and its connectors. So, you could have signal level problems, or disconnect problems with good signal levels. In both cases, it points to a failing cable and/or connectors with the disconnect issue being a more severe version of the problem.
You can copy the signal level table and codeword table and paste those into a post. Park your curser in front of the first character in top left hand column, hold down the shift key and scroll right and downwards to include the last bottom right character in the bottom row. Release the shift key and right click .... Copy. In a new post, right click .... Paste. The table should paste in just as it appear in the modem's user interface.
Copy and paste in both signal level codeword tables, one at a time. That's the starting point, to see if there's an obvious problem.
@DrMike log into your modem and navigate to Gateway -> Connection -> Rogers Network.
Give that about 20 to 30 seconds to populate the page and scroll down towards the bottom of the page. You should, at some point, see three separate tables there, a Downstream and an Upstream Signal Level table and Codeword table.
Unfortunately, their all horizontal tables (ugh), so you have to scroll right, just to scan thru all of the numbers. When you copy them and paste them into a post, they will also appear in the post as horizontal tables with a scroll bar underneath them.
Ok, thats not too bad. Its interesting that there's a large number of correctable codewords for channel 1 and 33, which are sitting next to each other in the frequency band, but, at the end of the day, their all corrected. Your the second person to post that type of situation.
Ok, on to Plan B.
Are you in a house, condo, highrise, etc, etc ?
If you're in a house, would you happen to know how long its been since the external cable has been replaced?
If you're in a house, do you have underground or overhead cabling?
The question at hand is whether or not there is an issue with the external cable and/or its connectors. To do that, ping the Cable Modem Termination System (CMTS), which is one level beyond the neighbourhood node. If there is an issue with the external cable, it will show up in the ping test results.
First, run a trace to anywhere at a command prompt. Use:
tracert -4 www.google.com
Note the 2nd hop IP address in the trace. The first will be the modem or router, the second will be the CMTS.
Then, ping the CMTS, using that second hop IP address:
ping -n 3600 xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx is the CMTS (second hop IP address)
That test will run for one hour and then terminate.
When its finished, select the bottom results and use Ctrl c to copy the results to the clipboard.
Then paste those results into a post.
You can run a longer test by increasing the 3600 number, keeping in mind that Windows will ping once per second.
If you want to run an indefinite test, use:
ping -t xxx.xxx.xxx.xxx
That will continue until you use Ctrl c to terminate the test. So, if you wanted to let it run overnight and stop it at some point in the morning, that's one way to do it. Or just multiply 3600 by the number of hours that you want to run the test.
You can leave that running in the background throughout the day, just to see what happens over a 24 hour period.
I would expect the results for a one hour test or longer to be well under 1 %
Note this ping test has to run vie ethernet, not wifi.
Just to note, its interesting that you don't have an OFDMA upstream channel running. When and if you're chatting with tech support, one question to ask is whether or not OFDMA upstream is enabled for your CMTS. If it is, you're data doesn't show it, which implies that there's an issue in the 5 to 42 Mhz range in your external cable system that is preventing the modem from using an OFMDA upstream channel. That might be part of the problem, but, you would have to know whether or not an OFDMA upstream channel is enabled for your CMTS and neighbourhood node.
@DrMike , the other possibility here is an IPV6 issue at the CMTS. That keeps popping up from time to time. I’m assuming that you have IPV6 running as a default setting on the modem. You can run a couple of tests to see if IPV6 is causing problems.
- You can run an IPV6 ping test to the CMTS, looking for packet loss. In theory, if you were to run this at the same time as in IPV4 ping test, the results should be nearly identical in terms of the packet loss. If the IPV6 results show a significantly higher number of lost packets, then there is a problem at the CMTS, which should affect everyone in the neighbourhood who uses Rogers as their ISP.
- You can disable IPV6 in the ethernet or wifi adapter of your desktop or laptop and reboot the device so that it ends up running IPV4 only for test purposes. If you were seeing disconnects on an ethernet connected desktop, disabled IPV4, and then didn’t see an more disconnects or greatly decreased the number of disconnects, the obvious conclusion is that there is an IPV6 problem on the go. Its hard to speculate without seeing any test results.
To run an IPV6 ping test, run a trace to anywhere at a command prompt:
tracert -6 www.google.com
That will return the much longer IPV6 addresses. The trace should run to the end at google.com. If it doesn’t then there is a IPV6 problem. If the trace can’t resolve the end address, then there’s also a DNS problem. If the trace doesn’t go past hop #2, then there is a CMTS configuration problem which isn’t allowing the return data to run from the CMTS to the modem.
Highlight or select the Hop #2 address portion, which will be a 2607……… address. Then use Ctrl c to copy the address to the clipboard.
At a command prompt, type in:
ping -6 -n 3600 (right click) The right click will paste in the IPV6 address that you just copied
Same as before you can run a much longer test simply by increasing the 3600 number.
And, you can also run an indefinite test by using:
ping -6 -t (right click) which will require using Ctrl c to terminate the test
As before, please copy the bottom test results. Select or highlight the bottom results, use Ctrl c to copy the results to the clipboard and then paste them into a post, right click ….. Paste or Ctrl v
To disable IPV6 in an ethernet or Wifi adapter, go Start ….. Control Panel ….. network and Sharing Center ….. Change Adapter Settings ….. Network Connections. Select the adapter and right click to select the Properties selection. That will bring up the Ethernet or Wifi Properties popup. Scroll down and deselect the Internet Protocol Version 6 (TCP/IPv6) checkbox. Hit Ok, close all of the open panels and reboot the desktop/laptop. The preferred device would be an ethernet connected desktop or laptop in order to keep any potential wifi issues out of the mix.
If you were experiencing any disconnects related to IPV6 problems, disabling IPV6 in the adapter should tell you in pretty short order if there is an IPV6 issue on the go.
The preferred way to do this would be to disable IPV6 in the modem. The set top boxes might squawk at this but they shouldn’t have any problems running IPV4 only for test purposes. That is something you would have to judge, but there have been posts which indicate that running IPV4 only isn’t an issue.
Just for the heck of it, when you have time, or maybe you already know. Have a look at the cables in the basement where they should be accessible. Check the cable jacket for the cable type. Ideally it would be RG-6, but, its probably RG-59 which has higher losses in the upper frequency ranges. Its designed for antenna purposes, not for cable. Although you don't want to rip open walls, consider if there's any location where an RG-6 cable could be easily pulled from the basement.
These days, with the use of OFDM and OFDMA channels which runs below 500 Mhz according to your current signal data, RG-59 losses aren't so bad. If Rogers ever moves the OFDM channel for your area up beyond 500 Mhz, then you'll have more problems on your hands. There is the issue of impedance mismatching due to the external RG-6 which is a 76 Ohm cable and the internal RG-59 (?) which is a 50 Ohm cable. You will end up with signal reflection at the cable joint and at the modem. That's unavoidable, simply due to the construction of the cables. So, its worth considering, depending on how this turns out, if its feasible to run a single RG-6 cable to some location on the main floor.
@DrMike can you delete all after 2607: on the hop #1 line for the IPV6 trace. That is your modem's IPV6 address which should not be posted in an open forum.
When you run an IPV4 trace, the first thing that shows up is the LAN internal address, 192.168.0.1 or 10.0.0.1 depending on the modem that you have.
When you run an IPV6 trace, the first hop that shows up is the modem's IP address.
If you go to https://whatismyipaddress.com/ that should show you your external IPV4 and IPV6 address. That external IPV6 address should be the same as the Hop #1 internal address from the trace, from what I remember from long ago. Its been a while since I've looked at this. Whenever you have time, can you try https://whatismyipaddress.com/ and compare that to the Hop #1 address. Please let me know if I remember this correctly or not.
Interestingly, the fact that there's no packet loss is good. The high time ping numbers aren't great, but typically that happens on the first ping. The average times look typical, so, if there are any high time returns in the data, there can't be that many.
I need to work on the plotting instructions so that other customers in trouble shooting mode can actually see what the data looks like after the test run is complete. Its been on my list of things to do ......
Hi @stepy2015 I did see your previous post and I've been thinking about it. Have you been able to go beyond the Level I Tech Support and chat with a Level II tech or a Level I manager? Those are the people that you need to be yakking with in order to get anywhere with this. For anything at or beyond the CMTS, you're wasting your time chatting with Level I techs. The primary question to ask a Level I tech, "Can you fix a CMTS or routing issue?". If yes, ok, lets get on with this, if not, pass me on to a Level II tech who can do something about this. My guess is that the Level II tech can't fix the problem, but he or she can pass this up to the Network Operations Center or to the Network Engineering Staff.
What happens when you run an IPV6 trace to anywhere? Say www.google.com for example. Does the trace manage to resolve the IP address in order to run the trace? And, does the trace complete, or does it quit after Hop #1which is your modem. If there's nothing after Hop #1, then the CMTS is not configured properly. Its not returning its own address or allowing return data to pass thru the CMTS enroute to the modem. There should be no difference in the behavior of a trace, either an IPV4 or an IPV6. Both should run and complete thru to the end point, and all of the enroute hops should show up in the trace, possibly with one or two exceptions.
Ah, ok, very interesting. I'm going to have to look at this again. If you type in ipconfig or ipconfig/all at a command prompt and look down thru the data for the IPV6 address, you might find that the whatismyipaddress.com IPV6 address matches the temporary IPV6 that windows is using at the time. Windows 10 generates temporary IPV6 addresses for internet security and privacy concerns. I've forgotten the roll-over time, that that time can be controlled to decrease the time that any temporary IPV6 address is used, or lengthen it if desired.
@toolcubed I did look at those packet loss numbers as you indicated. Their a very very small number compared to the overall codeword numbers so I didn't think they would have much of an impact. My bigger concern were the corrected codeword counts, which were corrected, but, I wonder what affect that has due to the processing required to correct codewords in those amounts. What is it they say, you can pay me now or pay me later? Something like that.
Fwiw, I don't use IPV6 and my better half is on video conferences for a good portion of the day. We've never had any issues with disconnects, but, that is also dependent on the load at the neighbourhood node and CMTS. In @DrMike's case, maybe it would be an idea to turn off IPV6 altogether for a few days, maybe a week to see if that has any impact on the disconnects? Just thinking aloud here.
-
9329 views
-
4 Likes
-
-
