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.

[User1445713]

@RogersSergio thank you for update regarding CODA modem features.

I'm sure the objective of modem is functionality of residential router / gateway keeping cost in mind.

This is what we are asking for. We are not after VPN commercial router with management functions.

All we need is working DHCP with ability to forward ports to dedicated devices. We just need to check the status of network camera, thermostat, wake up computer, do Remote Desktop, etc. Nothing too complex that would require additional sophisticated router or secondary DHCP on home network. I should be able to log in to my NAS using http://WDMYCLOUD as per WD instructions rather than trying to figure out IP number from CODA connected device list.

So we have couple of simple issues that prevent this from working smoothly:

1. DHCP reservation table is not working. It takes the name, MAC address and predefined IP but it does not assign the correct IP. In the Connected Devices table the device in question will have random IP from the bottom of the pool with "DHCP Reserved" label beside it.

2. Devices are dropped from connected devices list within 30s when in stand by mode with reduced speed 10Mbps. This makes it impossible to send a Magic Packet to computer from the Internet to wake it up.

Hard reboots after DHCP table update is annoying but it works. The 2 issues above don't work.

The table with rules for forwarding port number is also getting crowded with apps like Skype, WD NAS Cloud, printers and custom sets. Maybe we are running out of memory or something similar causing those issues.

[user12343543]

I'm really happy with the amount of work and attention you're putting into fixing these bugs!

[cflat]

Two recent observations:

* 2.0.10.28T2 shipped with my device and did not update for the last 4 months until I enrolled in the trial program

* 2.0.10.33T11 was first pushed to my modem (last night) and has substantially improved my internet reliability

Outstanding question: why wasn't the more recent firmware pushed?

Previously, I was struggling with latency (~30ms) and inconsistent throughputs (max speeds of 80mbps to 400mbps). Now after the firmware update my latency has halved (~15ms) and my max throughput can see > 900mbps.

I have a set of scripts that poll the modem for changes in levels. Again since the firmware update the levels have substantially improved. As an example, my upstream (which I care more about because of regular use of video conference calls for work)

before:

{"frequency":"23700000","signalStrength":"29.000","bandwidth":"6400000","channelId":"5"}
{"frequency":"38596000","signalStrength":"31.500","bandwidth":"3200000","channelId":"6"}
{"frequency":"30596000","signalStrength":"29.500","bandwidth":"6400000","channelId":"4"}

after:

{"frequency":"23700000","signalStrength":"33.750","bandwidth":"6400000","channelId":"5"}
{"frequency":"38596000","signalStrength":"36.500","bandwidth":"3200000","channelId":"6"}
{"frequency":"30596000","signalStrength":"34.000","bandwidth":"6400000","channelId":"4"}

(I've been logging signal changes to slack for the last year so I've got a pretty solid history with the CGN3 and now the CODA4582)

Still, it's frustrating that a firmware update would have solved my recent challenges and that I was using a firmware version that was months out of date.

[AOD999]

If I had to guess, your modem possibly was in the trial program before you got it when maybe someone did a modem swap and didn’t tell either @RogersDave or @RogersSergio about their swap and when you are enrolled into the trial program they put your modems MAC address into the auto firmware exclusion list so it doesn’t revert trial firmware back to production firmware.

[deus]

" 2.0.10.33T11 was first pushed to my modem (last night) and has substantially improved my internet reliability."

I agree with the assessment. The code gives the strongest up and down rates I've seen on this modem, e.g., d/l on a 150 plan went from 21.30 MBs to solid 21.55. Not huge but significant.

[zardoz99]

I would like to repeat my request for read-only SNMP access to be made available to the modems, exactly so we can track performance in an objective manner over time and updates.

Those of us with the tools to access the SNMP data could make great use of the metrics when demonstrating performance changes across updates, as well as seasonal/daily trends.

It's well known that ADSL is greatly affected by external propagation factors. While this may be much less the case with cable, it's still worth watching for "blips" caused by external factors.

Really, how hard is it to enable?

[cflat]

+1 for snmp.

As a stop gap, I've just up a cronjob that pulls the apis from the console and checks for deltas. Deltas or error messages are logged to a slack channel which pages me when it becomes too noisy. (more valuable when I'm traveling and the wife and kids are having internet problems)

I've discovered many anomalies with this approach. For example, prior to my firmware update, I would see timedrift on the modem. The result was that some of the 'logs' would be scrubbed/eaten. More specifically, the logs you see in the console are less than the actual logs! Only because I was picking the logs up every minute could I see when the timedrift re-snapped and the logs got pruned. 

[Datalink]

@cflat when you have time, can you provide examples of the timedrift and log issues to @RogersSergio.  Sounds to me like a sync problem which might be specific to your external cable.  But, I wouldn't have expected a large timedrift or an impact on the logs.  Can you also include your modem type with the data.  Thanks in advance. 

[cflat]

I'll have to go back. It's usually related to one of the following where I would see a burst of errors, but only one (or none) logged. I've mostly ignored these situations now, but its usually one of these:

{
    "time": "2018-03-05T21:03:59.000Z",
    "type": "90000000",
    "priority": "warning",
    "event": "MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=XXXXXXX;CMTS-MAC=XXXX;CM-QOS=1.1;CM-VER=3.1;"
}

{
    "time": "2018-03-05T00:34:22.000Z",
    "type": "68010300",
    "priority": "error",
    "event": "DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=XXXXX;CMTS-MAC=XXXXX;CM-QOS=1.1;CM-VER=3.1;"
}

{
    "time": "2018-03-04T16:54:25.000Z",
    "type": "82000200",
    "priority": "critical",
    "event": "No Ranging Response received - T3 time-out;CM-MAC=XXXX;CMTS-MAC=XXXX;CM-QOS=1.1;CM-VER=3.1;"
}

 /cc @RogersSergio

[cflat]

Actually, here's one that showed up as one T3 error, but as you can see there are multiple and a signal re-negotiation in the middle:

[
    {
        "time": "2018-03-02T23:12:27.000Z",
        "type": "82000200",
        "priority": "critical",
        "event": "No Ranging Response received - T3 time-out;CM-MAC=XXXX;CMTS-MAC=XXXX;CM-QOS=1.1;CM-VER=3.1;"
    },
    {
        "time": "2018-03-03T00:34:22.000Z",
        "type": "68010300",
        "priority": "error",
        "event": "DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=XXXX;CMTS-MAC=XXXX;CM-QOS=1.1;CM-VER=3.1;"
    }
]
{"frequency":"23700000","signalStrength":"31.000","bandwidth":"6400000","channelId":"5"}
{"frequency":"38595805","signalStrength":"33.000","bandwidth":"3200000","channelId":"6"}
{"frequency":"30596000","signalStrength":"30.750","bandwidth":"6400000","channelId":"4"}
{
    "time": "2018-03-03T01:09:59.000Z",
    "type": "82000200",
    "priority": "critical",
    "event": "No Ranging Response received - T3 time-out;CM-MAC=XXXX;CMTS-MAC=XXXX;CM-QOS=1.1;CM-VER=3.1;"
}
{
    "time": "2018-03-03T02:34:37.000Z",
    "type": "82000200",
    "priority": "critical",
    "event": "No Ranging Response received - T3 time-out;CM-MAC=XXXX;CMTS-MAC=XXXX;CM-QOS=1.1;CM-VER=3.1;"
}

/cc @RogersSergio

[RogersSergio]

@cflat

To answer your question about why you didn't receive the newer code sooner/on boot.

We have rolled out two codes previous to the 33T11 code (we had 33T3 and 33T03) both of which we discovered WiFi issues once they were deployed. As a result Rogers opted not to force an upgrade until we were confident that this issue had been resolved. By leaving the 28T2 code as the upgrade on boot option it allowed any customer impacted by the Wifi issue (a number of upgrades were completed) to factory reset which then would result in a downgrade to the known "good" (yes I know this is a loaded word... that is why i have quotes around it 🙂 ) firmware.

As for rolling out the latest code... we also took a conservative approach to this where we stagger how many upgrades are completed over a period of time. I can confirm we have wrapped up the rollouts and things are looking good... we are finalizing the update to have 33T11 be the new upgrade on boot firmware... that should be in place next week.

It's always a difficult balance between pushing out fixes and potentially introducing a new issue that was not captured during testing. That's one of the reasons for setting up the Firmware Trials, to provide those who are eager to get their hands on the latest code (with the understanding that there may be issues). That said if your device is still on 33T11 you will be upgraded to our latest test code soon.

I look forward to your participation in the trial and we will do our best to address issues raised

RogersSergio

[RogersSergio]

It's been a week and I wanted to reach out to see how things have been going with customers running the new 4.5.8.38T5 code on AC devices?

Anyone have any feedback... ideally it's good but I also want the bad

Thanks,

RogersSergio

[cflat]

too bad you can't detect those that have the modem in bridgemode (like myself) since we wouldn't be impacted by any wifi changes 😉

[mrq]

14

04/18/18 07:21:28

84000500

critical

SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=

Got 4 of these on Apr 18 around 7AM .

AC 4.5.8.38T5 here .

[mcsandy]

When do you expect the firmware for the improved traffic handling to be ready for testing?

we wont hold you to anything just a general idea 🙂

Thanks

[awais22]

How do I update modem firmware in bridge mode?

I am still on the old firmware : 2.0.10.28T2

Please let me know.

[Datalink]

@awais22, have a look at the following post:

http://communityforums.rogers.com/t5/Internet/FEEDBACK-Rogers-Rocket-Wi-Fi-Modem-Firmware-Trial/m-p/...

Looks like 33T11 will be the current update as of next week. 

[RogersSergio]

@cflat

I get your point but when we are looking at managing this many devices (all rogers devices, not just testers) sometimes it's best to keep firmware as streamlined as possible... 😄

[Makaveli99]

---

@cflatwrote:

too bad you can't detect those that have the modem in bridgemode (like myself) since we wouldn't be impacted by any wifi changes 😉

---

What do you mean by this?

Rogers can see if the modem is in gateway or bridge mode.

[cflat]

@Makaveli99
I was being sarcastic 😉

Given that I don’t use the WiFi features I was implying that I could have had the firmware rolled out sooner without risk.

[zzoubian]

I just got updated to .34T6, and noticed wifi performance has degraded significantly.