@Datalink : Thank you for the prompt response.
The connection drops for both wifi and wired.
Just to give you some background on this : Unlike sites like Youtube where the content is buffered and therefore will usually not indicate that there has been a connection drop unless it is for an extended period,I have a corporate VPN that I connect to when working from home and that disconnects (and then tries to reconnect) as soon as the drop happens even if for a very brief period. Therefore I am usually aware when the drop happens (which is happening quite often now), which otherwise would have been very easy to miss given the very short duration of the outages.
Update : Web support asked me to change the modem. I am not convinced this a modem issue but I am not an expert either so will look forward to your expert advice
Here are the signal levels :
|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.750||2||6400000|
|2||38596000||ATDMA - 64QAM||44.250||3||3200000|
|3||30596000||ATDMA - 64QAM||43.250||1||6400000|
@maildc16 has this always been a problem with the VPN, or is this a recent occurrence? Are you connecting to the modem via ethernet or wifi?
If this has been a long standing issue, its due to Intel's firmware. VPNs thru the Puma 6 modems have been a pain from day one.
If this is a recent issue, there's a good chance that your getting very short disconnects which don't show up in the modem stats. The modem stats themselves are fine. The upstream is just a little higher than normal but well within its allowable range. Typically the upstream runs between 36 to 40 dBmV, so your's are fine.
To check for any external cable faults you can ping the CMTS, which the modem connects to for data and control purposes. To do that, on an ethernet connection:
1. Run a trace to anywhere, google for example.
2. Assuming that the modem is in Gateway mode with a direct connection, the first IP address is the modem, the second IP address is the CMTS.
3. Ping that second IP address. Let the ping run for several hours while your doing the usual internet related activities. I run 24 hour tests looking for latency, just as an example.
Typically, you shouldn't see any more than perhaps a dozen lost packets over the course of a 24 hour test. If you see a much higher packet loss count, then that could be indicative of a cable and/or connector issue. You might see high time ping times on the return. Ignore that for now. The Puma 6 modems have a history of latency thru the modem, which Intel has been working on over the course of the last two years+. ICMP was the first protocol that Intel tackled in 2016, so I know that it was resolved, but, since I don't run a CGN3ACSMR any more, I don't know if any subsequent updates have introduced any latency thru the modem as an unintentional by product.
If you were to run Pingplotter, the program would generate packet loss indications on the plot which are easy to understand. Its actually useful to run this overnight with Pingplotter as you would see any changes that might occur between the highly loaded evening hours and no load hours after midnight. Pingplotter runs for 14 days in freebie pro mode until it locks down to a limited mode if you don't purchase a standard or pro licence.
Fwiw, I was able to crash a CGNM-3552 when my better half was running her corporate VPN and I was running a high rate ping test. The modem would start to show occasional packet loss and that packet loss would gradually become worse, little by little until the modem crashed and rebooted. The CGNM-3552 is a 32 channel modem whereas the CGN3ACSMR is a 24 channel modem. They're built with the same processor and a different cable tuner. Given that the firmware is basically the same, perhaps not identical but very close, its possible that in running the VPN, along with the other loads, that you might be seeing a low level packet loss at times when the total throughput thru the modem is higher than normal. That's something to keep in mind. Have you signed up for any online service that is running a data stream of any type, or are you possibly running backups to an offsite server somewhere? Just thinking of the possibilities here.
So, food for thought, old problem, new problem, does it occur without the VPN, or just when the VPN is running, any new services running? There are probably a few more that I could come up with....
@Datalink This is a recent problem since the last 3-4 weeks with the VPN and internet. I have been working 2-3 days/week from home for the last 12 months using this VPN and internet and never had a problem. When I first reported this problem to the concerned team in office, they investigated and found no issues with the VPN. At the same time, I started noticing the internet drops at home and on a closer look found that the VPN drops only when the connection drops.
So to answer your last question : The internet connection drop happens irrespective of whether I am connected to the VPN or not. Also I am not running any other services at present and apart from connecting to my office network from a Cisco AnyConnect VPN client, my usage is typical of a common household - emails, social media, Netflix and YouTube.
Now coming to some recent developments : I was asked by tech support to swap my modem so did that yesterday while returning from office. The associate at the Rogers store handed me a new modem and said it is the same model which I was swapping. I was in a hurry and did not check personally. On reaching home, I see that the model number is CGN3. Definitely not the same model as the outgoing one was CGN3ACSMR. Nevertheless, I power it up and hook my devices. Within minutes I see the internet drop and I have not even connected my VPN. I run a continuous ping to google and can see an average of 3-5 packet loss every 3 mins.
I connect to tech support again and frustratingly they say everything is fine. On some prodding, they agree to create a case (Case No. C138827752) for the engineering team to investigate.
Next Steps :
I will run the Pingplotter today as you have suggested . However, if the support guys cannot even detect a problem so evident, I don't think it is prudent to have high hopes that they would be able to resolve it. Do let me know if you have some ideas of how to tackle this better. Thank you again for all your help @Datalink, I really appreciate the good work you are doing.
@maildc16 don't ping Google. Ping the CMTS address as I've indicated. If you're having problems with packet loss, that will normally be caused by an external cable and/or connector issue. In order to detect that you only need to ping the first server beyond the modem, which happens to be the CMTS. That will restrict the signal path to the modem to the outside local tap to local node to CMTS and back again. That keeps any network issues beyond the CMTS completely out of the picture. The modem to local tap to local node path is copper cabling while the local node to CMTS will be fibre. The fault will usually be the external cable that connects the modem to the local tap. That local tap is either contained within a waist high green pedestal (in the case of underground cabling) which should be in view from your front step, or, its up on a utility pole in the case of overhead cabling. That cable and its connectors don't last forever and eventually fail. It sounds like this what your beginning to see.
There are a couple of cases which can occur. The ongoing cable and/or connector failure will result in reduced signal levels which can be seen in the modem's signal levels. The other is a series of very short disconnects which don't show up in the modem's signal data. The way to detect that is via ping test, but, the trick to this is to keep the overall path length to the ping target to an absolute minimum.
When you ping the CMTS with Pingplotter, any packet loss will be annotated with a vertical red bar. If you get to a time period where you see continuous intermittent packet loss, call tech support and advise the CSR that your seeing intermittent packet loss, but, that your able to detect it at the present time. Ask the CSR to ping the modem from the CMTS, or ping the CMTS from the modem, either one will work. Keep Pingplotter running. When you see packet loss, the CSR should see packet loss as well.
If you can cue the CSR at an appropriate time, then he or she should be able to detect the packet loss and arrange for a tech to inspect the cabling and connectors. The problem with this type of occurrence is that you have to be watching for it to occur. That's simply a matter of timing, right time, right place, as they say.
So, give this a go, ping the CMTS and let me know what you see. You can take a screen shot and post it if you're interested.
Just to note, we're looking for packet loss, not latency in this case. Pingplotter averages the latency data when you increase the plot time that is displayed on the plot, as in going from 60 seconds to 30 min to 48 hours, etc. This is a function of the ping interval and the displayed timeframe of the plot. When there is more data in the timeframe than can be displayed individually, Pingplotter averages the data. It doesn't preserve the high and low times. So, as you move to 12, 24, 48 hour plots, the plot itself looks better and better as you lose those high times due to the averaging. So, to see any latency, you have to scale the displayed timeframe down to 60 seconds, 5 min, maybe 10 minutes at most. Its all dependent on the ping interval.
Just to note, there are default ping intervals displayed. You can overwrite those times and enter your own interval time.
With Pingplotter running, right click on the column title bar to display the selected data columns. Select MAX and ERR to display the Maximum ping time and Error count (packet loss instances). Drag those columns to the right to sit beside the Min Time column.
Ok, that should do it for now.
@Datalink Thank you for such precise and to-the-point information. I ran ping plotter to the CMTS for 5 minutes through Ethernet and could see packet loss. Question is how do I prove this to the CSR to get the technician coming. I am afraid when I call CSR I may again not be in the 'right time , right place'
Can I not just send this report to prove the point?
I should have pointed out before that I live in an apartment which has both Rogers cable and Bell fibre pre-installed in each unit.
@maildc16 if you have Bell Fibre available, what are you doing running Rogers Cable? Just have to ask that question .....
Ok, if you can see packet loss occurring, tell the Tech Support Rep that you're pinging the CMTS and can see packet loss occurring. Ask him or her if you're actually connected to a CMTS which is external to the building, or to an MDU which is in the building. The MDU is a Multiple Dwelling Unit, which is similar to the CMTS but built for large multi-unit buildings such as apartments, highrises, condos, etc. Ask the support rep to ping the modem or ping the CMTS from the modem. Tell him or her to keep the ping test running, I don't know if there is a limit to the test that they run or if they can simply let it run forever. You should be able to cue the tech rep when you see the packet loss occurring.
Its possible that the support rep will take you at your word and accept the fact that there is packet loss occurring. If you're connected to an MDU, which will be located in the utility room in the building, that puts a different twist on this. There could be a cable issue, or, there could be a problem with the MDU itself. If the building is large enough there could be more than one MDU to service the building, so, at the very least, a tech might be able to switch you to another MDU if there was room available on another MDU. If this is an MDU issue, then it will require a tech who is qualified to service the MDU.
In any event you need to start the conversation with tech support. Make sure that your complaint is recorded. If you have to, keep calling in. Call every day if you have to, more than once a day if required. You need your VPN to work, and if the cable system keeps failing, that kills the VPN and any activity thru it. The list of complaints will add weight to the fact that there is a problem.
The CGN3 that you now have is the first model of that modem to be released by Rogers. If I remember this correctly, it doesn't have 802.11 ac available for the 5 Ghz wifi networks, so, that would result in a slower 5 Ghz network. If your mobile devices are 802.11 ac capable, you should return that modem and ask for another CGN3ACSMR, or for the CGNM-3552. The ACMR is a 24 channel modem (downstream) while the 3552 is a 32 channel modem (downstream). Both of those modems also receive firmware updates faster than the original CGN3, so, for that reason alone, I would swap the modem again. Check the modem model before you accept the replacement modem so that you know that you're receiving the correct modem.
Edit: Can you remind me, is that ping test running on an ethernet connection, or wifi. It should be done via ethernet.
@Datalink You have a very valid question for me in your first line. The recent experience proves that I might have made a big mistake.
Just finished chatting with the CSR and the experience is anything but frustrating. First he says that the CMTS IP I tested is incorrect and then after 10 mins says no - it is indeed correct. After spending a good 30 mins on chat, he just opens another area ticket. No word on what he thinks is the issue or whether a technician is going to visit or not.
I don't want to vent my frustration here but I think I am loosing my patience now.
You and this forum have been the only silver lining in the experience. Thank you again @Datalink for all your help.
PS : Just wanted to confirm that the test was run through Ethernet as you had advised.
Sorry to hear that. There's only so much that I can do as a forum volunteer, like the rest of the Resident Experts.
The next step, if tech support isn't providing any support is the forum moderators @CommunityHelps. If you follow that link, it will take you to their public page. On the right is a link to "Send this member a private message". Follow that link to the message composition page. It will already be addressed. Add the title and necessary details and hit send at the bottom.
When you're logged into the forum, look for a number overlaying your avatar at the upper right, which indicates a message or mention in the forum. Follow that avatar down to your profile and the message boxes.
Did the tech indicate if you're connected to a CMTS or an MDU. It sounds like its a CMTS if the tech opened an area ticket, but, that might also be applicable to apartment buildings with an MDU as well, don't know?
As I indicated above, call in every day if you have to. Be firm but polite, as they say and register yet another complaint. Be prepared for the usual robo call indicating that the ticket was closed as the problem was solved. The usual ping test will confirm or deny that theory. Unfortunately not all techs are sufficiently trained or experienced, personal opinion. Not trying to slag the techs, but, they have their scripts to follow which don't allow much flexibility. So, it might take a call or two to find a tech who really understands what your trying to get across