@Datalink One thing I forgot to mention is that this issue occurs even when the screen is on. For example, I am watching a youtube video and randomly it disconnects and reconnects itself.
I will check out the link. Thanks!
EDIT: Not sure if it's related but in the DOCSIS log, I am having some "No Ranging Response received" issue.
@OMWTS ok that might change things then. Can you have a look at the following post:
Look specifically at the section concerning inSSIDer and all the way to the bottom of the post. Perhaps looking at you're wifi environment might provide some explanation as well.
Edit: In response to your edit, can you:
1. Look at the product sticker at the back of the modem and let me know what model of modem you have. It will be a CGN3XXXX variety or possibly a CGNM-3552; and
2. Log into the modem and determine what Software Version (Firmware) is currently loaded: and
3. Navigate to the STATUS .... DOCSIS WAN page, copy the Downstream and Upstream tables and paste those into a post along with the Firmware version. The copy and paste process will paste in the text contents of the tables.
@Datalink I just found out another user has posted about the same disconnection issue at http://communityforums.rogers.com/t5/forums/forumtopicpage/board-id/Getting_connected/thread-id/3129...
I think that's what causing the disconnection.
2. 184.108.40.206 (I am on the trial version) This happened on 220.127.116.11 too.
|Port ID||Frequency (MHz)||Modulation||Signal strength (dBmV)||Channel ID||Signal noise ratio (dB)|
|Port ID||Frequency (MHz)||Modulation||Signal strength (dBmV)||Channel ID||BandWidth|
|1||23700000||ATDMA - 64QAM||42.250||2||6400000|
|2||38596000||ATDMA - 64QAM||44.000||3||3200000|
|3||30596000||ATDMA - 64QAM||42.750||1||6400000|
Its actually normal to see errors in the log, so I don't get overly exited about them. The Docsis system is built to allow timeouts to occur. I start to look at them when there are problems with connectivity. That could be a cable or connector problem, or possibly a CMTS issue. So, it takes some looking at the numbers to start sorting out the problems.
Your signal levels are good, both downstream and upstream. The signal to noise ratios are good as well. With those signal levels I wouldn't expect any problems. Its possible to pursue this further by running pingplotter to watch the modem to CMTS path for packet loss and ping times. Let me know if you want to pursue that. I suspect that this might be more of a wifi issue however.
You're running 18.104.22.168 which has a problem with a hidden SSID beacon that is broadcast in the 2.4 Ghz band. If you look at your wifi environment with inSSIDer, you should be able to see it. I'm really hoping that it will disappear in the next firmware update as I think its causing nothing but problems. In theory, it shoudn't, but the anecdotal comments indicate otherwise. That beacon, combined with an already crowded 2.4 Ghz environment if problematic to say the least.
Are you connecting via 2.4 or 5 Ghz wifi?
I am connected to the 5GHz, but the disconnects happen on both 2.4GHz and 5GHz. I am willing to try out the pingplotter.
Ok, I would recommend reading thru that post section that I indicated earlier. Then load inSSIDer to have a look at your wifi environment. You should be using channel 149 or higher due to the higher power limits of the upper 5 Ghz channels. If you're not there already, you might find that would make a difference. Of course, seeing who else is operating in that band helps.
Have a read of the following post for using pingplotter to keep an eye on the modem to CMTS path and give that a go after looking for wifi issues:
@OMWTS one thing to note. You can load pingplotter as a Windows Service to collect data in the background. There is selection for that when you install it. Don't select that. I've tried in on a Windows 10 pc and it seemed to cause more errors in the data than were actually happening. Load pingplotter as a normal application and it should run without problem.
@Datalink I have performed the inSSIDer and pingplotter tests. Below are the results.
inSSIDer result seems fine.
IPv4 pingplotter with no packet loss.
IPv6 with pack loss.
IPv6 - Focus time 5 seconds
@OMWTS your inSSIDer screen shot doesn't look too bad. There is another network on the same channel but its fairly far below yours in terms of received power so it shouldn't be an issue. The one recommendation I would make is to use a different network name, something that doesn't identify the ISP, modem type, your home or anything personal. I use completely random sequences and fill the entire alphanumeric field which is 32 characters. I do the same for the passphrase field, using all 63 or 64 characters, depending on the character type that is used. You can use the following page to generate both:
Refreshing that field causes the character fields to regenerate. The longer the network name and passphrase, and the more random the characters, the tougher it is to crack the network security. Normally you never have to enter the network name into a device, so using a longer network name is a simple copy and paste. Entering the passphrase is admittedly a little more work. With that set up and running, anyone driving around looking to crack wifi security will probably pick a much easier target somewhere else.
The IPV6 pingplots are a little interesting. Can you go to ipv6-test.com which is an IPV4 and IPV6 test page. That will show some score X/20. If you see on the lower left that IPV6 ICMP is missing, you will need to add an exemption to the Windows and possibly Anti-Virus firewall for IPV6 ICMP. Add that solely for IPV6 ICMP, not IPV4 ICMP. When that is done, reboot the pc.
The other missing element would be an IPV6 hostname which Rogers is not supplying at this time.
With the IPV6 ICMP added, return the the ipv6-test.com page to check the results again. You should see 19/20. Refresh the page a couple of times to ensure that you are getting consistent results. I say that as I've seen inconsistent results from that site, so running a page refresh more than once will confirm the results.
When that is done, rerun the IPV6 pingplot, looking for packet loss again. I'll be interested in whether or not you added the IPV6 ICMP exemption and what difference it makes to the IPV6 pingplot.