FEEDBACK - Rogers Rocket Wi-Fi Modem Firmware Trial

[RogersMargaret]

Hello Community,

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.

[RyzenFX]

@Alex4161

The .27 firmware is availiable for the 3552, however you need to ask @RogersDave to send you the update. From what I've heard with the .27 update for the 3552, people are getting weaker WiFi signals and so I wouldn't upgradrading the firmware.

Maybe anyone who has the 3552 and on the .27 firmware can confirm with having weaker WiFi signals?

[Mythen]

I don't know about weaker signal but it's so slow. Is this a known issue with .27

Mythen

[BS]

@Alex4161  I have similiar questions, but I am not sure from my researching there is a clean solution.  In my area, I have close to 30 2.4 signals operating within across the spectrum, and there is no avoiding conflicts with my neighbours.  Some are better than others, but if you have your choice set to automatic, which is the default setting, as most of my neighbours will have, it is constantly bouncing all over the channel spectrum.

But I still use it because 5, does not make it through the structural design of my home, so it is necessary to drop to the 2.4, or consider installing remote access points to extend the range.

My devices on 5, within the clean sections of my house are fantastic, and fortunately, most of my devices have both available, but there a couple, which I use rarely, and I just have to think where I am using them - why do I still use them - they have DVD burners in them, and I have a number of devices that don't have DVD readers in them.  Sure I could buy a portable burner as a solution, and what I do for now, is I transfer it to USB, or share it over my network. 

So there are pros and cons to the two ranges.

As for the beacon or ghost 2.4 signal, I have around 9 Rogers modems I can see in my neighbourhood, all which have these beacon signals, all providing additional interference across channels (I think).

So a good question to bring back up - it has been kind of set aside with the current discussion of .27 or .22 firmware and latency versus speed, which is also important, in particular for gamers, but my issue as with the poster impacts our day to day ability to connect period.

Only reliable solution I see is remote access points to extend range, keep both frequencies running and allow my devices to automatically connect to the appropriate frequency - in bad areas, my devices flip from 5 back to 2.4 as the device and modem loose connectivity.

But again, thanks, for keeping this question in the forefront - it would still be nice to no why this beacon signal exists - we have had guesses, but not clear answers.  None of the other non Rogers modems in my area have them and obviously there are some Acer and other routers being set in bridge modem so I am not even sure for them what modems they use.  I just don't feel like spending money on more hardware at this moment if I can avoid it.

Bruce

[Datalink]

Fwiw, I have had previous discussions with @RogersDave regarding this beacon.  I'd like to see it removed, but there is apparently a legitimate reason for its existence.  So, some compromise will be necessary.  Hopefully @RogersDave can provide an update on the progress of this issue. 

Also fwiw, this is not a new problem.  I'm not sure when it was first seen, .19, or .20 or perhaps even sooner.  I don't use the modem's wifi so I wasn't keeping track of it.

[Datalink]

@mhs2, those numbers which are for a powerline adapter are a little strange considering that the loss to the modem is so high while the follow one servers are better.  Usually its the other way around.  Is the powerline adapter set an older set, or is it one of the newer Homeplug AV2 sets?

http://www.homeplug.org/tech-resources/hpav2_next_gen/

My first thought at seeing this is to recommend a factory reset if you haven't done that alread.  Can you log into the modem and determine which version firmware is loaded.  Its shown on the STATUS page which comes up after you log into the modem. 

Can you rerun this with a direct connection to the modem?  Please unplug everything else from the modem's ethernet ports when you run that test.

[mhs2]

It's a Netgear powerline 1200 which is AV2 compliant according to the manual.  I'm on firmware 4.5.8.27 and these results are with a direct connection, nothing else is wired, wifi is on.  I haven't tried a factory reset yet

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| hitronhub.home - 95 | 17 | 1 | 3 | 3 | 3 | 3 |
| INTEL_CE_LINUX - 0 | 84 | 84 | 7 | 14 | 134 | 23 |
| INTEL_CE_LINUX - 0 | 84 | 84 | 7 | 14 | 26 | 15 |
| INTEL_CE_LINUX - 0 | 84 | 84 | 11 | 19 | 160 | 18 |
| INTEL_CE_LINUX - 0 | 84 | 84 | 9 | 15 | 155 | 29 |
| INTEL_CE_LINUX - 0 | 84 | 84 | 7 | 16 | 148 | 17 |
| INTEL_CE_LINUX - 0 | 84 | 84 | 9 | 20 | 186 | 25 |
| INTEL_CE_LINUX - 0 | 84 | 84 | 9 | 16 | 155 | 25 |
| yyz08s10-in-f164.1e100.net - 0 | 84 | 84 | 10 | 16 | 149 | 25 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

[Datalink]

Ok, I would recommend a factory reset in that case.  Before you do that, and considering that you are running a direct connection to the modem in this latest case, bring up a command prompt, run an ipconfig/all command.  Determine the Default Gateway Address, which should 192.168.0.1.  This will ensure that it is.  Then run a ping command:  ping 192.168.0.1 -n 100

Please copy the test and the bottom results and post those.  I'm curious as to what they will look like.  According to WinMTR, they should be miserable, but, lets see how they turn out.  If they are very bad, I wouldn't hesitate to run a factory reset.  Hold down the recessed reset button at the back of the modem for 30 seconds and release it, or, run the factory reset from the user interface:  ADMIN .... DEVICE RESET .... Factory Reset.

To copy the command window contents, right click on the top title bar of the Command Window, select Edit .... Select All.  Then right click again, select Edit .... Copy.  Then you can paste the contents into a post.  

[mhs2]

OK factory reset the modem and pinged 192.168.0.1:

Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>ping 192.168.0.1 -n 100

Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=42ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=23ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=5ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=4ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=7ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=8ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=7ms TTL=64
Reply from 192.168.0.1: bytes=32 time=13ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=6ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=3ms TTL=64
Reply from 192.168.0.1: bytes=32 time=5ms TTL=64
Reply from 192.168.0.1: bytes=32 time<1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=11ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.0.1:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 42ms, Average = 2ms

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| hitronhub.home - 96 | 22 | 1 | 3 | 3 | 3 | 3 |
| INTEL_CE_LINUX - 0 | 102 | 102 | 8 | 12 | 31 | 9 |
| INTEL_CE_LINUX - 0 | 102 | 102 | 7 | 13 | 33 | 9 |
| INTEL_CE_LINUX - 2 | 98 | 97 | 0 | 17 | 35 | 21 |
| INTEL_CE_LINUX - 2 | 98 | 97 | 0 | 15 | 63 | 13 |
| No response from host - 100 | 21 | 0 | 0 | 0 | 0 | 0 |
| INTEL_CE_LINUX - 2 | 98 | 97 | 0 | 17 | 73 | 11 |
| INTEL_CE_LINUX - 2 | 98 | 97 | 0 | 15 | 35 | 14 |
| yyz08s14-in-f132.1e100.net - 2 | 98 | 97 | 0 | 14 | 43 | 16 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

EDIT:  Okay I used 192.168.0.1 in WinMTR instead of www.google.com and got this (its over powerline again so the low% packetloss is fine).  I'll try a direct connection tomorrow

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| hitronhub.home - 7 | 95 | 89 | 2 | 5 | 35 | 3 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

[Datalink]

Ok, so the ping test doesn't show any packet loss to the modem.  Can you run WinMTR and use 192.168.0.1 as the target and post that.

[mhs2]

I used 192.168.0.1 in WinMTR instead of www.google.com and got this (its over powerline again so the low% packetloss is fine). I'll try a direct connection tomorrow

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| hitronhub.home - 7 | 95 | 89 | 2 | 5 | 35 | 3 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

[Datalink]

Yup, please try that tomorrow.  If you were not aware, the CGNM-3552 is a Puma 6MG modem, as is the CGN3xxx series.  Those modems have latency issues thru the modem due to the packet processing by the CPU instead of the hardware processor/accelerator.  That is an ongoing issue which firmware version 4.5.8.27 solves, but only for IPV4 ICMP.  Currently we're waiting for Intel and Arris to complete the development to change the other protocol processing from the CPU to the hardware processor/accelerator.  From looking at your data I would say that there is an issue when the WinMTR test runs past the CMTS, which is the second IP address in the trace or the WinMTR result.  That issue results in packet loss indications from the modem.  I'm wondering at this point if its an issue with the packets returning out of sequence which Wireshark would show, or if WinMTR is having a hard time with the returning packets for that reason or something that is closely related. 

When you run that connected test run it once, using the modem IP as the target and then run a second test using 99.231.80.1 as the second target.  Let that second test run for at least ten minute or more.  Looking at the previous results it looks like you have packet loss between the modem and CMTS.  This is one step to confirm it. 

Here are my results with WinMTR running out to the CMTS:

|----------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|-------------------------------------------|--------|-------|---------|--------|--------|-------|
|                              10.0.0.1 -    0 |  100 |  100 |        0 |       0 |       0 |      0 |
|                       99.239.32.1 -    0 |  100 |  100 |        9 |     27 |  220 |   21 |
|___________________________|_____|_____|______|_____|_____|____|
   WinMTR v1.00 GPLv2 (original by Appnor MSP - Fully Managed Hosting & Cloud Provider)

There is no packet loss to the modem or CMTS in this case but, the high time 220 ms return from the CMTS, back thru the modem is indicative of the latency of a Puma 6/6MG modem.

You can also use a ping test to the CMTS to look for packet loss.  What you can to is run the following command:

ping 99.231.80.1 -t >c:\temp\pingtest.txt

That will run a continuous ping test and write the results to a text file that you can review after you terminate the test.  The -t will run a test that continues until you use a "Ctrl c" to terminate it.  Then you can review that test looking for any indications of packet loss. 

The other way to do this is to use pingplotter to run the same test to the CMTS, looking for packet loss.  Have a read thru the following post on how to set up pingplotter to do that:

http://communityforums.rogers.com/t5/forums/forumtopicpage/board-id/Getting_connected/message-id/355...

If you go back to this post, you can see the various links for the current situation on the Puma 6/6MG latency.  The last link in that post is the current discussion thread:

http://communityforums.rogers.com/t5/forums/forumtopicpage/board-id/Getting_connected/message-id/377...

[NBomb]

I'm having what seems like a similar issue. It's not 100% loss, but it's getting up there. Or perhaps I'm setting this up wrong? It'a closer to 98.6% as of posting.

I am running bridged mode, wired direct to the router.

Further update: about 30 min later - it's now saying 'Destination address unreachable'.

[Datalink]

@NBomb with the modem in Bridge mode, connected directly to the modem, you will need to reboot the computer and after the reboot bring up a command prompt to run run an ipconfig/all command.  Look for the Default Gateway Address in the results and use that as a target to ping the modem.  The reboot should ensure that the pc picks up the correct IP address.  If there is still a problem, run the following commands:

ipconfig/release

ipconfig/flushdns

ipconfig/renew

After that reboot the pc.  Run the ipconfig/all command again to determine the Default Gateway Address.

If you run a trace to anywhere, google.ca for example, the first IP address in the trace will be the CMTS.  You can use that CMTS IP address as a target address to check for any packet loss to the CMTS and to see the latency in the modem if you happen to be running a CGN3ACSMR or CGNM-3552 with V4.5.8.22 or earlier loaded.  

[NBomb]

Hi Datalink,

Is this common, that I'll lose 100% of the packets when going through a router?

[JohnBeaudin]

@Datalink

I know you are super active in the DSLreports forums discussing the intel puma5 latency issue.. is there any progress so far? 

[Datalink]

@NBomb no thats not common at all.  There appears to be a quirk in the way that Pingplotter reports the results.  I ran into that before and I'm trying to remember what I did to resolve it.  Are you using the standard ping test, or using a TCP/IP or UDP test?

[Datalink]

@JohnBeaudin at the present time, everyone is waiting for Intel and Arris to come up with working firmware modifications to resolve the Puma 6 latency.  Until that happens, all of the other manufacturers, including Hitron are on hold.  So, the reason that you don't see any new news regarding this in the DSLReports thread is because there isn't any.  Whether that means that no progress is being made, or that Intel and Arris simply choose not to provide updates on the progress is a good question.  Intel has basically been completely silent on this issue so far.  That's left Netdog, who is an Arris engineer as the only one providing any news or comments on this, and even he isn't saying very much. 

[JohnBeaudin]

@Datalink

Intel seems to be in complete denial.. I don't think we will hear anything from them.

As a customer I would love that Rogers switch modem providers or give us the option to get our own modem so we don't have to use these modems.

[Mythen]

I agree. Rogers should replace these modems or give us the option to buy our own. I've been watching the DSL reports forums and I agree nothing from Intel or Arris either way

Mythen

[Datalink]

@Mythen, @JohnBeaudin buying your own modem as a solution isn't that easy, especially for higher channel counts.  At the present time the following manufacturers also use the Puma 6/6MG chipset:  Arris, AVM, Compal, Cisco, Hitron, Linksys, Netgear, Samsung, and SMC.  There are probably more companies, I just haven't come across them as of yet. 

So, presently, the Arris 6183 and Netgear CM600 are probably the best bet when you can actually buy your own. The next generation DOCSIS 3.1 modems will hopefully resolve this no matter what chipset is involved, Intel or Broadcom. 

[JohnBeaudin]

That's the thing other ISP's facing these issues have the choice to switch modem or get their own.. however us at Rogers we all stuck with the laggy chipset. We are in much more trouble than comcast and other cable ISP facing these issues. because we are all affected.