- last edited on by
RogersMaude
Announced 13-December-2016 by @RogersDave http://communityforums.rogers.com/t5/forums/forumtopicpage/board-id/Getting_connected/message-id/379...
Credit to @Hybrid_Noodle
Hitron website: http://www.hitron-americas.com/product/coda-4582/
Datasheet: http://www.hitron-americas.com/wp-content/uploads/2016/09/CODA-4582-Datasheet.pdf
60W Power Supply built into unit
Pictures of Hardware Version 1A:
***Added Labels***
Hello, @Geezup.
Have you modified the LAN or WAN settings? If you have changed the DNS servers in WAN Setup, then you can't change them in the DNS menu.
Thanks,
RogersMoin
Hello, @FiberInternet.
Thank you for posting your query in the Community. All CODA-4582 modems are DOCSIS 3.1 and backwards compatible. When the downstream signal locks on to DOCSIS 3.1, the light turns light blue. You may be seeing the whitish colour, but be assured it has locked on to DOCSIS 3.1 downstream signal. I appreciate your understanding.
Cheers,
RogersMoin
Hello, @djri
Welcome to the Rogers Community Forums!
Thanks so much for posting your concerns in the Community. I know how important it is to have good signal levels in order to have consistent service.
The signal results you've provided are within the correct operating range for optimal services. We've received your private message and look forward to discussing this matter with you further to find a solution.
RogersTony
@doctor80 go to grc.com
Select Services .... ShieldsUp! and follow the path to test All Service Ports.
I'll have a longer response later, but, for now, I'll state that the 4582 doesn't have chronic problems. I'd attribute any issues to external cable issues or IPV6 issues if you happen to have Dual mode selected in the Gateway Function in the modem.
@doctor80 ok, so the modem is in Bridge mode with a router behind it. What's the router model that you're using?
Are you seeing the dropouts on both ethernet and wifi connected devices? I'm assuming at this point that you see this on ethernet connected devices. Please let me know.
If you happen to have IPV6 enabled in the router, consider disabling it and then reboot the router. I'd reboot the connected devices as well. They should all kick over to IPV4 only, but, we've seen issues with cell phones in the past where they're slow to kick over to IPV4 in the event of an IPV6 failure, which in this case is simply caused by disabling IPV6. Run IPV4 for a day or two to see if there is a positive effect. If so, then you have an IPV6 issue at the CMTS. That does happen, again and again, and getting tech support to recognize the IPV6 problem is a problem in itself.
Its possible to see service dropouts with good signal data. Those dropouts will normally be too fast for the modem's signal levels to catch them, but, if the dropouts are just long enough, you might see the results of the dropouts indicated in the Event Log. The most likely indication is a Lost MDD Timeout and possibly a MIMO Event. There's no guarantee that you will see those in the Event log, but, a string of those would probably indicate an external cable issue.
To look for service dropouts, run a ping test to the CMTS. To do that, first run a trace to anywhere, google for example. Bring up a command prompt and enter:
tracert -4 www.google.com
With the modem in Bridge mode, and the router in full router mode:
1. The first hop in the trace is the router, the modem will not show up in the trace.
2. The second hop address is the CMTS.
Ping the CMTS and let that run for at least an hour. Let it run for 24 hours if you want to collect data for an entire day. You should only see a handful of lost packets during the course of the day, far less than 1%.
For a 1 hour ping, enter:
ping -n 3600 xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx is that second hop address.
For a 24 hour test, use:
ping -n 86400 xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx is that second hop address.
When that test is done, copy the bottom results and post them please. Select the result by holding down the left hand mouse button and sweeping thru the bottom results, from top to bottom. Use Ctrl c to copy the result to the clipboard and then paste them into a post.
The only problem with the command line ping test is that it only runs at 1 ping per second. If you want to run a higher ping rate, download HrPing from http://www.cfos.de/en/ping/ping.htm
Thats a command line program, like the Windows/Dos ping command. When that is unzipped to a location of your choice, navigate to that folder with an admin command prompt and enter:
hrping.exe -t -s500 -T -F c:\temp\hrpingtest.txt 64.71.255.204
If I remember this correctly, there is a licence prompt you have to acknowledge on the first run, and you need to be using an admin command prompt instead of the normal command prompt. So, when the downloaded file is unzipped and ready to go, start a command prompt using admin rights, then navigate to the folder and run the command.
As indicated at the download page:
-t is an continuous test that will only stop when you use Ctrl c
-s500 is a 500 milli-second interval. The default is 500 milli-seconds, but, you can shorten that if you prefer. Two pings per second isn't a terribly high rate, but it will suffice for the time being
-T adds a timestamp to the results line
-F c:\temp\hrpingtest.txt causes the program to write the results to a file, located at C:\temp\, in this case titled hrpingtest.txt You need the .txt at the end of the file name to result in a text file that will simply open with a text editor. You can change the file location to another folder if you don't have a C:\temp folder on your pc. It might be worth creating a folder on the C drive, something like C:\test, or something along those lines that you can use to hold the program and results, and which will be simple to navigate to by using the command line "change folder commands", up and down C drive's folder structure.
64.71.255.204 in this case is Rogers primary IPV4 DNS, which use for test purposes at various times. In this specific case, you would replace that with the CMTS IP address.
The lowest ping interval that you can probably use to the CMTS is about 17 milli-seconds (-s17). Below that you risk intentional packet loss if you run below the average of the return time. You could fine tune that and after one run, take the average and add 1 milli-second to that time. Then rerun the test.
Note that if you run a high rate (low interval) ping test to any target and let that run for a length of time, the results file will grow rather large, to several tens of Mb or possibly hundreds of Mb if you let it run long enough. Windows Notepad will choke on a large file size, so, I recommend something like Notepad++ https://notepad-plus-plus.org/
If you run a high rate (low interval) ping test to the CMTS, you will see groups of high time ping results that repeat. That's due to a firmware change that was adopted in Version 2.0.10.27, many months ago. That change appears to have been carried thru to the newer Version 7.x. The firmware change was mode to improve mixed protocol performance, but, one side effect was the introduction of high ping times from the CMTS. Ping times to any target beyond the CMTS are not affected. So, ignore the ping times, look for packet loss only.
Ok, that should just about do it. If you let a test run overnight, using something like a 500 milli-second interval, that should result in a good indication of the drop outs during the day.
Here's a few questions to work on:
1. What's the router model that you're using and is the firmware up to date? What's the date of the current router firmware?
2. Are you seeing the dropouts on both ethernet and wifi connected devices? The real test here is the ethernet devices, but the question has to be asked just to be sure of what's going on.
3. Do you have IPV6 enabled in the router?
4. Are you using a VPN of any type at the same time that there is other traffic thru the router, ie: gaming, streaming, etc, etc.
5. Can you log into the modem, thru the router and copy the signal data which is located in the STATUS .... DOCSIS WAN tab. Navigate to that tab, and select the entire table, from the Downstream Overview line all the way to the very bottom right hand corner of the OFDM/OFDMA Overview. Park your curser at the front of the Overview line, hold the shift key down and scroll down to the bottom of the table, or use the arrow keys to select the table, both right and downwards. When thats done, right click .... Copy. Then paste that into a post, right click .... Paste. The end result should look like the table from the modem's User Interface. If the modem's login page won't respond, that's most likely due to the presence of Firmware Version 7.x In that case, unplug the modem from the wall socket, wait for 10 to 15 seconds and plug it back in. After the modem restarts, you should be able to log into the modem, thru the router, using 192.168.100.1 to access the login page. From there, the modem should behave and allow you to copy the signal data. Despite your past tech visits, I'd like to see the data myself, at least, the data that the modem's UI actually shows.
6. When you have a dropout with the Hitron modem, do you see dropouts occurring with any other service such as cable tv service (Nextboxes) or with a Home Phone service which uses its own cable modem?
Just as a comment, the modem's are far more reliable than is assumed and presented by tech support and the field techs. The actual failure rate doesn't warrant their regular replacement. If you're getting service dropouts, then there's something that's driving it, either a cable issue somewhere between the modem and the neighbourhood node, or, possibly a mixed protocol issue, ergo my question about VPN usage. So, with a little information, hopefully we can sort out the cause of the problem.
-
512369 views
-
215 Likes
-
-
