We are currently offering our users an exclusive opportunity to participate in an upcoming trial of the new firmware for our Rocket Wi-Fi Modem (CGN3ACR, CGN3AMR and CGN3ACSMR) and Rocket Gigabit Wi-Fi Modem (CGN3552 and CODA-4582). For details of this program, please see this thread.
This thread will be used for feedback regarding the firmware. We've invited @RogersSergio, @RogersSyd & @RogersBob from our Networking team to participate in this thread. Your feedback is very valuable and will be used to enhance the firmware before it is released publicly.
Thank you for your continued feedback and support.
No disrespect towards you Datalink, we truly appreciate your dedication and assistance bro but this company needs to address these issues direct. It's just getting way out of hand and frustrating. Like why is there even a forum? Plus we contribute our time to make the service better but it's like we're begging at the same paying our hard earn money monthly for this? Like this suppose to be a premium service that's why all of us is here and not with a third party company (which most of them have way better customer service). Ever since @RogersDave left it has gotten 10 times worst and none of us deserves this period! Only god knows why he left when thinking about it .
I disagree about there being poor service here. The issue I have with the CODA has not been fixed but is acknowledged and new code comes out frequently plus I am on the beta list. Whining about things is foolish . The forum is quiet because no one has additional things to say but the code keeps developing so work is going on.
How often do you be on here @deus? And is addressing spending your money for a service that's not delivering whining? If things are good for you i totally understand but before you make any assumptions please do your homework and look at my posts and other participants as well evaluate the dates, response and solution before typing anything.
Got the Update to:
|2||10/05/2018 07:39:24||69010100||notice||SW Download INIT - Via NMS|
|3||10/05/2018 07:39:54||69011100||notice||SW download Successful - Via NMS|
I wanted to chime in here too with some feedback, I for one am very happy with my results, last night I got updated to 184.108.40.206T5 overnight seamlessly. Today when I woke up, both myself and my wife typically work from home and we noticed a huge improvement in our speeds and even the wifi range. Not only that, the speeds are where they should be both on wifi and ethernet using only the rogers modem itself. This is the result consistent for my connection after the update to 36T5.
Before this, it was closer to 500ish with around 15-17 ping, upload about the same. Slightly higher on Ethernet, but not even close to this speed!
I have yet to test if bridge mode works now and has been fixed on my side, as it wasn't working before, but to be honest, if this is the speeds and consistency I will continue to have, then I will not even bridge my modem as this is optimal! I know that not everyone may have the same results and I do agree we have been dealing with a lot of frustrations and ups and downs for some time, but this to me is a HUGE improvement and makes me feel that the money I am spending for service is worth it and justified. This is my opinion only and I truly wanted to say thank you for making a change to Rogers, thank you to the Devs and Engineers that worked on this. I will keep you all posted on my results after a couple of days and let's hope this sticks!!
Edit: It might help to mention that I have 3 mobile phones on wifi, 3 computers on ethernet, PS4 on wifi, an IPAD on wifi, an IPTV Android Box on wifi, my Sony smart TV on wifi. Obviously not everything is used at the same time but with the test results, the TV was on, 3 cell phones are on (2 personal, 1 work constantly being used) IPTV Android Box was on, 2 laptops where on and I think my niece was using the IPAD at the same time too.
This is strictly conjecture but I doubt the firmware update has much to do with the better speedtest results.
I was upgraded to. Just tested on speedtest and dslreports. I get under 300 Mbps. Over the last 2-3 months I would more often than not hit 800-900 +.
The firmware changed I think maybe 1-2 times maybe.
I came back to cable recently after having left for DSL for a good 5 years. It still feels very much like it used to in that you really never know what you're going to get. Some days it's amazing. Some days it starts great then degrades throughout the day.
I hate to say it but with "the other guys" it was not as fast but it was consistent. 99.9% of the time.
If I could get FTTH I would leave this nonsense.
So far it's looking better than the previous firmware, I had loads of issues with the previous ones, Had to reboot modem twice a day. I changed to a new modem and the issue persisted, so Right now on new beta firmware I have not experienced these glitches so far, I will keep track of things and see how it goes.
@CChilderhose are you running a VPN of any type? I'm running my modem in Bridge mode with an Asus RT-AC86U behind it and I've never seen any issues with that combination. The only time that I reboot the modem is for firmware updates or more often, experimental purposes, which is deliberate instead of necessary.
On going internet issues
had 2 tech come over and still getting spikes while gaming or streaming videos. they checked everything and said not much they could do all signals look good. I am wondering if its my modem trial update since I am on the gaming one. 220.127.116.11T4 - 2A
Speeds seem the same as previous firmware i'm getting higher than 950 mbps on downstream but its probably just a bug on the site.
Also on the previous firmware i had an up time of over 30 days no reboots so my experience has been quite stable ever since 18.104.22.168T4
Ok, an interesting plot to say the least the first plot that is.
So, there are a couple of things to do.
To test Hop #2 you can do this three ways. Using that plot, click or double click on any of the individual hops to bring up the plot for that hop. You could actually select all of them if you wanted to. The plots will stack up vertically in order. To close any of the plots right click on the plot and select “close”. The real question at this point is whether or not any packet loss at Hop #2 relates to Hop #7, the target DNS address. Looking at both plots, one on top of the other will allow you to do that. If you look at the text data, there is only one error, or one packet loss instance for Hop #2, the CMTS, and 36 loss instances for Hop #7, the DNS. So, you may or may not be able to see if the one packet loss aligns with the DNS packet loss.
The other way to do this is to right click on Hop #2 and copy the IP address. Pause Pingplotter, paste that address into the address bar and let Pingplotter run. That my preference as Pingplotter causes a good deal of extra traffic that I would rather not see while a test of this type is running. You will see regular latency spikes from the CMTS. That’s a false indication due to the modem processing. Disregard the ping spikes. We’re looking for packet loss to and from the CMTS.
Lastly, you can do this via command prompt. Bring up a command prompt and ping the CMTS:
Ping 22.214.171.124 –t
That runs a continuous ping at 1 second intervals. Again, you will see high return times. Disregard those times as that’s a modem processing issue. When you want to stop the test, use Control^C. What we’re trying to confirm in this case is whether or not there is any packet loss. To post the bottom results, right click on the command box title bar. Select EDIT …. SELECT ALL. Right click again and select EDIT …. COPY. Paste that into notepad so that you can copy the bottom results section, or paste that into a post and delete the data above the bottom results. The question is, whats the packet loss to the CMTS? I usually run this for 24 hours, but, in your case keep an eye on the ping returns for a few short minutes to see if there are signs of packet loss. If not, just let it run for at least an hour or more. If yes, ok, stop the test and paste the results. From the Pingplotter results, you shouldn’t see much packet loss in this test.
Last test is for Hop #7, the DNS. I’d like to confirm the results that Pingplotter is indicating. In this case run a command ping to the DNS:
Ping 126.96.36.199 –t
Let that run for a few minutes and if you see continuous instances of no response, ok, that confirms the issue.
So, at this point there are two potential issues:
Tech support can help with the packet loss to and from the CMTS. That’s what the field techs would resolve, but, looking at the Pingplotter results, that appears to be a minimal problem. I’d have to see a much longer run to come to a real conclusion.
The packet loss and high latency to and from the DNS is a network issue. Those problems shouldn’t exist. For the specific cases of Hop # 6 and #7 (DNS) you need to talk to Level II tech support. Failing that, @CommunityHelps would need to become involved to get the network engineering staff involved. This is a rather important point as the path thru Hop #6 enroute to the DNS would be a common router for a number of customers. If you’re having problems with it, then so are a lot of other customers. It would be in Rogers best interest if a staff member somewhere pays attention to that server to determine what the problem is.
Just for comparison’s sake, here’s the result of an HrPing 10,000 ping run to the DNS, at 50 milli-second intervals:
Packets: sent=10000, rcvd=10000, error=0, lost=0 (0.0% loss) in 499.974018 sec
RTTs in ms: min/avg/max/dev: 5.332 / 10.788 / 38.816 / 1.923
Bandwidth in kbytes/sec: sent=1.200, rcvd=1.200
So, no packet loss and an average time of 10.8 seconds, which isn’t too bad. Top time is 38.8 seconds. That’s the high time in the run, with the remainder at or below 25 seconds. That’s a far cry from your max time of 523 seconds.
Here’s a Pingplotter run for comparison’s sake, with the ping interval set to 1 second. No packet losses or high latency except for the high ping time for Hop #2, the CMTS. Again thats a modem processing issue for the return from the CMTS, with no effect to targets after the CMTS. This plot shows an average of 10.8 seconds which agrees with the longer run using HrPing. This plot should be what your plot looks like, low normal latency with no packet loss throughout the path to and from the DNS.
Ok so, first task is to confirm that you don’t have any packet loss to Hop #2 using a command line ping.
Second task is to confirm that you have high latency and packet loss to 188.8.131.52 (the DNS), using a command line ping.
If and when you confirm that there is high latency and packet loss to the DNS, then its time to chat with Tech Support Level II or, get @CommunityHelps to send a request to the network staff to look at the server at Hop #6 and the impact on the DNS when the DNS is accessed thru the server at Hop #6.
Hope this helps. My apologies for taking a while to get this done ....
Ok, your second pingplotter image is a little ugly to say the least. I see you've found the show plot commands to show more than one plot. The combination is rather interesting.
In the above post, I've included instructions to confirm the packet loss using a command ping. When you have confirmed the packet loss, or not, we'll go from there.
Can you confirm for me that this is done via ethernet connected pc?
Are you using a power bar of any type to power your computer equipment?
Ran a quick test for you and already time outs. using CMD
Ping statistics for 184.108.40.206:
Packets: Sent = 17, Received = 13, Lost = 4 (23% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 50ms, Average = 23ms
Ping statistics for 220.127.116.11:
Packets: Sent = 129, Received = 129, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 410ms, Average = 27ms
yes it is done via Ethernet CODA right to PC connected
wall plug with 2 spots, one spot is my modem CODA plugged into the wall directly and the 2nd spot is my power bar directly into wall above modem plug. modem is not plugged into power bar tho. they are both (modem and power bar) plugged into same wall plug tho.
Ok, no packet loss from the CMTS, which is good, but, this is a very short run. You have a very high level of packet loss from the DNS, most likely due to the server at Hop #6. So, at this point you can try to chat with Level II tech support, or ask @CommunityHelps to get involved to resolve the issue at Hop #6 10.202.47.204 and its impact on the DNS 18.104.22.168.
Before you do that, and just to be absolutely sure, can you completely disconnect the power bar from the wall socket and the connected equipment and rerun the command ping. Run the equipment using extension cords just for temporary test purposes. Power bars can contain metal oxide varistors to prevent over-voltage damage to connected equipment. That will run for several years without any issues, but, if and when that varistor starts to fail, it can generate RF interference that is conducted along power, RG-6 or ethernet cables from the source to any connected equipment. There is also a possible radiated component from the power bar and from the power cabling. The common connection point in your case would be the wall socket. Tech support will ask customers to disconnect power bars and this is the actual reason, to eliminate any possible RF interference issues.
Can you have a look at the following as well by logging into your modem:
1. Check the STATUS page that is displayed when you log into the modem. On the upper left is the WAN IP address which might show two IP addresses if your modem is running in Dual Stack mode (IPV4 & IPV6). The IPV6 address is a much longer address.
2. Navigate to the BASIC .... DNS. Is the DNS Obtain set for Auto or Manual. If its set to Manual, what are you using for DNS addresses, Rogers, Google, OpenDNS, other?
3. Do you happen to have hard set DNS addresses in your pc and other devices? If so, what are they set to, Rogers, Google, OpenDNS, other?
If your using the Rogers DNS address, its easy to avoid the IPV4 DNS packet loss that your seeing with Pingplotter and with the command line ping. Thats simply a matter of using one of the other DNS providers such as Google, OpenDNS, Quad 9, or others. The only question that relates to this is the IPV6 status of the modem, ie: enabled or disabled. That can be seen on the BASIC .... GATEWAY FUNCTION tab. With Dual Stack running and the pc and other equipment using IPV6, you then have to provide both IPV4 and IPV6 DNS addresses for the entry windows in the BASIC .... DNS .... DNS Obtain .... Manual settings.
When I know what mode the modem is running in, IPV4 or Dual Stack, I might ask you to run a test to the IPV6 DNS address.