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.

[RogersDave]

I have edited the 2nd post to include this as a request.

We still need to investigate with our vendor to see if it is doable but at least it will be tracked.

[Jaxx_HS]

While there's definitely improvements from the previous firmware, there's still some ping spikes with this trial firmware.   Here are my ping results to 192.168.100.1, and to www.google.ca

[ping 192.168.100.1]

...

Reply from 192.168.100.1: bytes=32 time=25ms TTL=63
Reply from 192.168.100.1: bytes=32 time=5ms TTL=63
Reply from 192.168.100.1: bytes=32 time=2ms TTL=63
Reply from 192.168.100.1: bytes=32 time=4ms TTL=63
Reply from 192.168.100.1: bytes=32 time=3ms TTL=63
Reply from 192.168.100.1: bytes=32 time=59ms TTL=63
Reply from 192.168.100.1: bytes=32 time=3ms TTL=63
Reply from 192.168.100.1: bytes=32 time=3ms TTL=63
Reply from 192.168.100.1: bytes=32 time=2ms TTL=63
Reply from 192.168.100.1: bytes=32 time=3ms TTL=63
Reply from 192.168.100.1: bytes=32 time=5ms TTL=63
Reply from 192.168.100.1: bytes=32 time=1ms TTL=63
Reply from 192.168.100.1: bytes=32 time=15ms TTL=63
Reply from 192.168.100.1: bytes=32 time=2ms TTL=63
Reply from 192.168.100.1: bytes=32 time=2ms TTL=63
Reply from 192.168.100.1: bytes=32 time=3ms TTL=63
Reply from 192.168.100.1: bytes=32 time=3ms TTL=63
Reply from 192.168.100.1: bytes=32 time=3ms TTL=63
Reply from 192.168.100.1: bytes=32 time=11ms TTL=63
Reply from 192.168.100.1: bytes=32 time=3ms TTL=63

Ping statistics for 192.168.100.1:
Packets: Sent = 1000, Received = 1000, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 97ms, Average = 3ms

[ping www.google.ca]

...

Reply from 172.217.0.163: bytes=32 time=27ms TTL=56
Reply from 172.217.0.163: bytes=32 time=200ms TTL=56
Reply from 172.217.0.163: bytes=32 time=24ms TTL=56
Reply from 172.217.0.163: bytes=32 time=31ms TTL=56
Reply from 172.217.0.163: bytes=32 time=23ms TTL=56
Reply from 172.217.0.163: bytes=32 time=146ms TTL=56
Reply from 172.217.0.163: bytes=32 time=53ms TTL=56

Ping statistics for 172.217.0.163:
Packets: Sent = 1000, Received = 997, Lost = 3 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 11ms, Maximum = 271ms, Average = 27ms

[blues_clues]

---

@RogersDave wrote:

---

@zardoz99 wrote:

I would like to make a "Feature request" while the possibility of doing so within the trial exists.

Please could we have read-only access to the SNMP metrics within the modem, visible only from the LAN/Wifi side?

There will be a few (admittedly) interested parties that like to monitor their link status/quality as well as traffic patterns using things like MRTG, Cacti or the various commercial equivalents. The lack of monitoring ability is somewhat frustrating to those of us "in the trade".

Thanks.

---

@zardoz99, I will add this to the feature request list but there is a caveat.

In gateway mode, the Hitron acts as a CPE + CM. The SNMP could provide CPE metric, for example volume and throughput. Not sure if there is anything else you would like to see.

In router mode, the Hitron acts as a CM only. Because this is L2 bridge (albeight with some added L3 features), I'm not sure if we can run a meaningful SNMP agent. In this case, KPIs should be collected from the CPE (which is the 3rd party router).

Does that make sense?

---

I would rather we not trade off performance with SNMP functionality if it will chew up CPU cycles on the modem/router.   Another option would be for Rogers to offer customers a, "looking glass", type functionality similar to what large ISPs give to customers.  That way we can see utilization and trending of bandwidth usage in our area.  We can then schedule our heaviest work around the avaialble bandwidth in our areas.

[Alex4161]

2 Features that would be really helpful to have on the modem:

1) Wifi site survey feature that lets you scan your area to find out what wifi channels are being used and what are free or very distant from your modem.  The device currently tries to do an auto channel detect and am not sure if this feature is already buried in the current menus.   This will help users from downloading something like this for their troubleshooting:  http://www.nirsoft.net/utils/wifi_information_view.html.  This type of tool may also help Support to determine why wifi speeds are slow for the customer.

2) Usage counter that will display how much you have downloaded for the day, week, month, etc.  This would be helpful for those who have not secured their network and noticed a spike in usage.  Most users with unlimited accounts won't find a need for this, but it is a helpful feature.  

Thanks

[RogersDave]

Thanks Mahomed for your feedback.

There is already a WiFi survey functionality available from the Wireless menu. Can you try this feature and let me know if it is sufficient or if you are expecting anything else additional?

Regarding the usage counters, I will add this to the feature request list in the 2nd post of this thread.

[Alex4161]

Hello,

The current wifi site survey does not work for my modem.  When I click on it, I see a screen with no info at all.  I have the latest firmware and I have not seen it work on 21 or 22 firmware versions.

thanks

[Sunfox]

I just signed up for the beta, and looks like .22 just got pushed to my modem sometime earlier today. I'm in bridge mode, and over the past week have had LAN die about 4 times - very frustrating.

No useful feedback yet, although I can confirm some minor latency spikes:

Pinging 192.168.100.1 with 32 bytes of data:
101 iterations (warmup 1) ping test:
...
Reply from 192.168.100.1: 3.43ms
Reply from 192.168.100.1: 3.94ms
Reply from 192.168.100.1: 3.66ms
Reply from 192.168.100.1: 4.84ms
Reply from 192.168.100.1: 2.90ms
Reply from 192.168.100.1: 3.07ms
Reply from 192.168.100.1: 3.01ms
Reply from 192.168.100.1: 3.23ms
Reply from 192.168.100.1: 3.04ms
Reply from 192.168.100.1: 3.06ms
Reply from 192.168.100.1: 3.58ms
Reply from 192.168.100.1: 34.64ms
Reply from 192.168.100.1: 3.04ms
Reply from 192.168.100.1: 3.20ms
Reply from 192.168.100.1: 23.63ms
Reply from 192.168.100.1: 3.28ms
Reply from 192.168.100.1: 3.66ms
Reply from 192.168.100.1: 3.46ms
Reply from 192.168.100.1: 3.19ms
Reply from 192.168.100.1: 4.05ms
Reply from 192.168.100.1: 3.63ms

Ping statistics for 192.168.100.1:
Sent = 100, Received = 100, Lost = 0 (0% loss),
Minimum = 2.64ms, Maximum = 34.64ms, Average = 4.13ms

Latency Count
2.64 86
4.33 7
6.01 3
9.38 1
11.06 1
22.85 1
34.64 1

If I flood the modem with pings it gets worse:

Ping statistics for 192.168.100.1:
Sent = 10000, Received = 10000, Lost = 0 (0% loss),
Minimum = 1.94ms, Maximum = 223.68ms, Average = 3.67ms

Latency Count
1.94 9788
13.61 129
25.28 40
36.95 15
48.62 3
60.29 4
71.96 2
83.63 4
95.30 1
118.64 1
130.31 6
141.98 3
153.66 2
165.33 1
223.68 1

Compared to flooding my router:

Ping statistics for 192.168.0.1:
Sent = 10000, Received = 10000, Lost = 0 (0% loss),
Minimum = 0.76ms, Maximum = 5.28ms, Average = 1.20ms

Latency Count
0.76 3217
0.99 4257
1.23 595
1.47 410
1.71 1167
1.95 259
2.18 41
2.42 14
2.66 27
2.90 7
3.14 2
3.37 1
3.85 2
5.28 1

Google shows some spikes too:

Pinging 209.148.198.234 with 32 bytes of data:
101 iterations (warmup 1) ping test:
...
Reply from 209.148.198.234: 12.18ms
Reply from 209.148.198.234: 13.30ms
Reply from 209.148.198.234: 12.28ms
Reply from 209.148.198.234: 12.76ms
Reply from 209.148.198.234: 16.12ms
Reply from 209.148.198.234: 11.26ms
Reply from 209.148.198.234: 12.55ms
Reply from 209.148.198.234: 13.62ms
Reply from 209.148.198.234: 11.56ms
Reply from 209.148.198.234: 16.29ms
Reply from 209.148.198.234: 20.96ms
Reply from 209.148.198.234: 14.51ms
Reply from 209.148.198.234: 11.30ms
Reply from 209.148.198.234: 132.54ms
Reply from 209.148.198.234: 17.30ms
Reply from 209.148.198.234: 24.19ms
Reply from 209.148.198.234: 16.14ms
Reply from 209.148.198.234: 97.74ms
Reply from 209.148.198.234: 13.61ms

Ping statistics for 209.148.198.234:
Sent = 100, Received = 100, Lost = 0 (0% loss),
Minimum = 10.81ms, Maximum = 132.54ms, Average = 17.79ms

Latency Count
10.81 81
17.22 11
23.62 2
30.03 1
42.84 1
68.47 2
94.10 1
132.54 1

For a useful comparison, here's the same ping test conducted from the same computer via DSL (I have dual WAN):

Pinging 209.148.198.234 with 32 bytes of data:
101 iterations (warmup 1) ping test:

...
Reply from 209.148.198.234: 20.46ms
Reply from 209.148.198.234: 20.30ms
Reply from 209.148.198.234: 20.33ms
Reply from 209.148.198.234: 19.78ms
Reply from 209.148.198.234: 19.66ms
Reply from 209.148.198.234: 20.32ms
Reply from 209.148.198.234: 19.88ms
Reply from 209.148.198.234: 20.65ms
Reply from 209.148.198.234: 19.91ms
Reply from 209.148.198.234: 20.44ms
Reply from 209.148.198.234: 19.86ms
Reply from 209.148.198.234: 20.63ms
Reply from 209.148.198.234: 19.90ms
Reply from 209.148.198.234: 19.41ms
Reply from 209.148.198.234: 20.20ms
Reply from 209.148.198.234: 20.08ms
Reply from 209.148.198.234: 20.02ms

Ping statistics for 209.148.198.234:
  Sent = 100, Received = 100, Lost = 0 (0% loss),
  Minimum = 19.41ms, Maximum = 21.71ms, Average = 20.24ms

Latency Count
19.41   3
19.53   4
19.65   3
19.77   12
19.89   6
20.02   13
20.14   14
20.26   8
20.38   14
20.50   3
20.62   14
20.74   2
20.86   1
21.59   2
21.71  1

(Although, I'm normally directed to this Google host on that connection):

Ping statistics for 172.217.3.131:
 Sent = 100, Received = 100, Lost = 0 (0% loss),
 Minimum = 16.65ms, Maximum = 23.56ms, Average = 17.56ms

[at5]

After the .22 firmware push I'm not seeing any LAN port drops as I was before, but still seeing these a lot in the DOCSIS Events.   They seem to be repeat in groups of these 3 events.   I saw a lot of these prior to the beta FW too.  Is there an issue with my line or modem setup?

18	06/30/16 14:24:28	82000200	critical	No Ranging Response received - T3 time-out;CM-MAC=xx:xx:xx:xx:xx:xx;CMTS-MAC=00:17:10:91:04:29;CM-QOS=1.1;CM-VER=3.0;
19	06/30/16 14:34:36	90000000	warning	MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=xx:xx:xx:xx:xx:xx;CMTS-MAC=00:17:10:91:04:29;CM-QOS=1.1;CM-VER=3.0;
20	06/30/16 14:34:38	73040100	notice	TLV-11 - unrecognized OID;CM-MAC=xx:xx:xx:xx:xx:xx;CMTS-MAC=00:17:10:91:04:29;CM-QOS=1.1;CM-VER=3.0;

[noziel]

Another issue in terms of passwords, since the release of .21 and .22 firmware. You cannot use special characters such as ! for GUI passwords.

[Brent4]

I'd like to sign up for this firmware upgrade.. I have 3 chromecasts that worked on Bell but not working since I recently switched to Rogers. Thanks!

[Brent4]

Sign me up for firmware upgrade please

[Triple_Helix]

---

@Brent4 wrote:
Sign me up for firmware upgrade please

---

Please see here and follow the instructions: http://communityforums.rogers.com/t5/forums/forumtopicpage/board-id/Getting_connected/thread-id/3315...

If you are interested in participating, please send a private message to @CommunityHelps with the subject line “Rogers Rocket Wi-Fi Modem Firmware Trial”.  A member of our team will be in contact with you and provide you with further instructions.

[Brent4]

I do not know how to send a private message

[RogersAsif]

@Brent4

@CommunityHelps  <--------- Click this

On the following page, select "Send this user a Private Message"

You can also review our blog here for more detailed instructions.

RogersAsif

[Brent4]

Yup thanks. I figured it out

[BigMac9000]

Hello.

1st, thank you to the rogers help teamfor the very quick firmware trial upload, I did not expect it to be done within 24 hours.

I have a small question related to IPv6.  I did the factory reset as one of the Rogers posts said, and then when I came back in my modem, the WAN IP indeed looks like a big string which would mean it's IPv6.  But what I'm wondering is about DHCP as it relates to IPv6 modems.  According to online stuff I read, DHCP would be a thing of the past because IPv6 would handle all, but my modem still uses 192.168.0.10 / 11 / 12 for the connected devices.  Mainly I was excited about IPv6 because it would mean no more NAT issues in online games, as some of those help guides mentioned.  Am I doing something wrong or is it not implemented fully yet?

FYI - just tested my xbox 1 and it says ports are open, without even configuring anything in DHCP or forwarding any ports, but I know that in a few days, it might switch to strict again...

Should I go and update the DHCP reservation table again?

[BigMac9000]

update...
when I go to my modem's "connected devices" list it shows 2 IPs for my laptop and 2 IPs for my Xbox - 1 of them is the usual 192.168.0.10, and the other one is what I assume to be IPv6... and the modem lists the IPv6 as self-assigned.anyways, question still stands, is it possible my xbox 1 will revert to strict if I don't update the DHCP table?

[Datalink]

You should probably ensure that the XBox has a reserved IPV4 address for IPV4 fowarding to run properly.  that way, if the modem reboots for some reason, the XBox address won't change and the port forwarding that you should set up will remain valid.  The XBox, ie; XBox One will select the highest performing path to use for gaming and other purposes.  So that could be via IPV6, IPV4 or Teredo Tunneling.  Hopefully what users will start seeing it that the XBox is using an assigned IPV6 path and that NAT issues will become a thing of the past.  If for some reason, the XBox decides to use IPV4 as the preferred path, then, without the reserved IP address and assigned port forwarding, my guess is that you would end up with a strict NAT.  Even with everything set to run properly, you might still see a Strict NAT, but, if IPV6 is the chosen path, I would think that the Strict NAT wouldn't matter.  Can you post your impressions or comments of the IPV4/IPV6 use as you gain more experience with it.  I'm sure it would help others who use an XBox One.  

What you should be seeing is two addresses on your devices, an IPV4 address and IPV6 address.  That is because the majority of devices these days are probably built as dual stack devices.  A dual-stack device is a device with network interfaces that can originate and understand both IPv4 and IPv6 packets.  So, in theory, with IPV6 running, the preferred address will probably be an IPV6 address.  

[RogersDave]

---

@noziel wrote:
Another issue in terms of passwords, since the release of .21 and .22 firmware. You cannot use special characters such as ! for GUI passwords.

---

Thanks Noziel.

I confirm that WiFi passwords and cusadmin user password cannot contain special characters when set through the regular GUI but it works during the EasyConnect setup interface.

I have updated post #2 in this thread to log this as a bug.

[Vikentieff]

Ignite100, .22 on Cisco node.

Ping spikes, ping spikes everywhere.

Ping statistics for 192.168.100.1:
    Packets: Sent = 50, Received = 50, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 649ms, Average = 17ms

Ping statistics for 24.156.131.55:
    Packets: Sent = 50, Received = 50, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 15ms, Maximum = 35ms, Average = 22ms

It seems the average latency went up and the jitter went up comparing to .20, which was also rather problematic for any type of online gaming. DOCSIS 3.1 can't come soon enough to Rogers...

[Datalink]

Were those via ethernet or wifi?  The high time to the modem doesn't make sense, unless its via powerline adapter, wifi, or the modem was under some type of heavy load at the same time.  You're the second person to comment on that today:

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

Can you try this.  Run a trace to anywhere, google.ca or .com for example.  Then ping the second address in the trace list for something like 100 pings.  That is the CMTS, which is the first stop after the modem, enroute to everywhere else.  Please let me know what your final results are.