@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....
@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.
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 😞
Hello and welcome to our Community @vovalos!
Should you be experiencing any Internet-related disruptions, you've come to the right place to get support.
I'd like to run some tests on your modem and the area to see if I can discern the root cause of the issues you're facing. Please PM us @CommunityHelps so that I can get started.
If you're not familiar with our PMing process, you can find instructions here.
Regards,
RogersCorey
Hey @Suse1!
Welcome to the community!
Intermittent service can certainly be difficult to troubleshoot but no worries, you're in good hands within the community. Thank you as well for posting the information you have as that definitely rules out any visible concern with signal levels. Your second post here identifies your LAN uptime but are you able to post your WAN uptime with the LAN uptime? This information would be helpful in determining if the disconnects you're experiencing are occurring due to a disconnect from the cmts.
Thanks!
Hey @Suse1!
Thank you for the provided information. The data you've provided indicates that you're not losing internet service which is good news, so this looks like it may just be home network/WiFi related. Can you confirm for us if the disconnects occur only on WiFi? Testing of this can be done by using a wired device directly to the modem and confirming internet connectivity on that device when your WiFi drops.
Thanks!
Hello @TTrueman!
My name is Corey and I'd like to take a closer look into this matter and troubleshoot with you today.
Please PM us @CommunityHelps. If you're not familiar with our PMing process, you can find instructions here.
Regards,
RogersCorey
Hey @arayhbs!
Welcome to the community!
Sorry to hear you're having intermittent service issues. I can appreciate wanting to get to the bottom of this asap. To assist there's just a few additional pieces of info we can use. Can you confirm the following for us?
- Is your modem connected directly to a wall outlet or to a power bar?
- Your RF signal levels appear to be within spec, have you communicated with tech support to identify the cause of the issue?
- Have you had a technician visit yet to assist in the resolution?
- Does this happen at any particular time of the day consistently?
Thanks!
-
12879 views
-
0 Likes
-
-
