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.

[Datalink]

@ffdhfhf sorry, don't have any idea if Rogers will allow access to read-only SNMP.  Thats a question for @RogersIan.  Same goes for the rise in the upstream power levels with version 7.1.1.32 loaded.  Is this a math error by chance?  Yet another question for @RogersIan.

[Davedes]

Hey Folks,

How do I go about getting version 7.1.1.32 loaded on my CODA modem?  I'm running 36T8 now.

Thanks

Dave

[RogersMoin]

Hello, @Davedes.

Thank you for your interest in the 7.1.1.32 firmware version. As mentioned by @RogersIan, in the post 4439 of this thread; you have to be already on 7.1.x.x version, to get the 7.1.1.32 version. Since you are running the stable production firmware, we can enrol you in the firmware trial. 

Please send a private message to @CommunityHelps with the subject line Rogers WiFi Modem Firmware Trial. A member of our team will be in contact with you and provide you with further instructions.

Cheers,

RogersMoin

[MisterPinst]

I have the same issue...modem upgraded to 7.1.1.32 and local NAT hairpin stopped working. When on the LAN, I can't resolve a site hosted at my own public IP address (either my DDNS FQDN or the public IP address itself). When I'm off the LAN, I can access my own IP address / DDNS FQDN with no problems.

I've been using the previous firmware 2.0.1036T6 up until this morning when it auto-updated. Everything was working perfectly until then. I also notice that this firmware removed the DDNS option for "no-ip" which is also disappointing as I am using them for DDNS.

[MisterPinst]

Hi all - I see that my post #4477 has been marked as a 'solution'. Just to be clear - this hasn't been solved for me. I'd love to see an update from someone at Rogers to understand if NAT loopback will be added in versions beyond 7.1.1.32. This is a fairly simple question to ask as I'm sure that they are aware of it.

[adri21]

@MisterPinst Thanks for bubbling this up. I saw it showed “solved” too and I was confused. I’m having the same problem and it has made various services I use no longer work properly (my home security cameras, etc.)

Can someone from Rogers please let us know what the status of this issue is and when we can expect to have NAT loopback working again?

[RogersIan]

@adri21  @MisterPinst  we have raised the NAT loopback issue with our vendor.

Currently I don't have an eta on when the fix will be implemented, will provide more info when I have it.

RogersIan

[MisterPinst]

That's great news @rogerslan. Thanks for acknowledging this issue and looking into it with the vendor.

Looking forward to hearing about your progress on this...

[jayrabbit]

I'm having a bunch of connectivity issues related to 7.1.1.32.

The modem "disconnects" frequently: not from the Internet - from the whole network.  When it does, DHCP isn't working and it won't renew IP addresses.  The DNS server is also buggy.  Previously, you could specify manual DNS server settings to a remote IP (I use Cloudflare's 1.1.1.1 and 1.0.0.1) and it didn't matter if a client computer had a static IP or not, but would still look upstream for a DNS server and get it from the modem.  The option to offer DNS proxy for manual DNS is no longer present either, which is what I used to use.  Now it seems like any static IP device needs to have DNS specificed manually on it.  IPv6 DNS is no longer present as an option although it looks like this was an expected change in the current firmware.

Also, Reserve IP's can no longer be specified outside of the DHCP Range, despite what the subnet is set to, whereas before the modem would accept any valid IP within the subnet.

This started happening at ~2:30 Tuesday morning for me.  That whole day, both DHCP devices and static IP devices on my network would experience a disconnection from the network where the modem would not issue DHCP IP's, nor would it show any kind of Internet connection.  The modem lights DID NOT indicate that it was rebooted.

On Wednesday, I had a technician come and replace a 3db attenuator inside my home with a "reverse tap" outside, and even replaced the modem with another CODA w/ the same hardware revision and firmware.  I'm seeing errors and warnings in the logs.  But someone please explain how 2 separate modems will not respond to DHCP IP address renewals to any *wired Ethernet* or wireless computers or devices when it appears to be on and NOT in a reboot state, whether the Internet is connected or not.  Shouldn't the DHCP server ALWAYS function on the modem?  This has NEVER been an issue with a CODA modem prior to this week, nor to any router that I've ever seen (aside from Bell's, which reboot if they don't detect an Internet connection).

I've been using custom settings with my modem since I got Rogers, and since this problem started happening, I tried hard resetting the (previous) modem, as well as the current replacement, and running with the default settings with all dynamic IP's, and it's still showing the same problem.  I suspect there's more to it than just blaming a faulty Ethernet cable considering it affects every PC and device in my home, and I'm reading about numerous issues lately about similar problems.  Maybe someone should look at possible firmware bugs.

Here's a bunch of info from the modem:

System Information

This menu displays general information of the device

Hardware Version	1A
Software Version	7.1.1.32
Gateway Serial Number	9999999 (obfuscated for privacy)
HFC MAC Address	9999999  (ditto)
System Time	2020-07-09 17:23:08
Time Zone	UTC-05:00 Eastern Time(US & Canada)
LAN Up Time	000 day 01h:03m:02s

WAN IP Address
WAN Receiving	72.52M Bytes
WAN Sending	12.20M Bytes
Private LAN IP Address	10.0.0.1/8
LAN Receiving	28.84M Bytes
LAN Sending	42.55M Bytes
WAN Up Time	000 day 01h:03m:25s

DOCSIS WAN

This menu displays both upstream and downstream signal parameters

DOCSIS Overview

Network Access	Permitted
IP Address
Subnet Mask	255.255.252.0
Gateway IP Address
DHCP Lease Time	😧 6 H: 18 M: 42 S: 41

Downstream Overview

Port ID	Frequency (MHz)	Modulation	Signal strength (dBmV)	Channel ID	Signal noise ratio (dB)
1	597000000	QAM256	-2.799	8	38.983
2	849000000	QAM256	-2.200	2	38.605
3	855000000	QAM256	-2.700	3	38.605
4	861000000	QAM256	-3.500	4	38.605
5	579000000	QAM256	-2.799	5	38.605
6	585000000	QAM256	-2.599	6	38.983
7	591000000	QAM256	-2.599	7	38.983
8	279000000	QAM256	-4.700	1	38.605
9	603000000	QAM256	-2.799	9	38.983
10	609000000	QAM256	-2.799	10	38.983
11	615000000	QAM256	-2.400	11	38.983
12	621000000	QAM256	-1.900	12	38.983
13	633000000	QAM256	-2.099	13	38.983
14	639000000	QAM256	-2.099	14	38.983
15	645000000	QAM256	-2.500	15	38.605
16	651000000	QAM256	-2.000	16	38.983
17	657000000	QAM256	-2.299	17	38.605
18	663000000	QAM256	-2.200	18	38.605
19	669000000	QAM256	-2.099	19	38.983
20	675000000	QAM256	-2.200	20	38.605
21	681000000	QAM256	-2.200	21	38.983
22	687000000	QAM256	-2.400	22	38.983
23	693000000	QAM256	-2.700	23	38.605
24	699000000	QAM256	-2.000	24	38.605
25	705000000	QAM256	-2.099	25	38.605
26	711000000	QAM256	-2.099	26	38.983
27	717000000	QAM256	-1.900	27	38.605
28	723000000	QAM256	-2.299	28	38.605
29	825000000	QAM256	-2.000	29	38.605
30	831000000	QAM256	-1.799	30	38.983
31	837000000	QAM256	-1.900	31	38.983
32	843000000	QAM256	-2.099	32	38.983

OFDM Downstream Overview

Receiver	FFT type	Subcarr 0 Frequency(MHz)	PLC locked	NCP locked	MDC1 locked	PLC power(dBmv)
0	NA	NA	NO	NO	NO	NA
1	4K	275600000	YES	YES	YES	-4.700001

Upstream Overview

Port ID	Frequency (MHz)	Modulation	Signal strength (dBmV)	Channel ID	Bandwidth
1	30596000	64QAM	47.020	3	6400000
2	36996000	64QAM	47.020	4	6400000
3	22100000	64QAM	46.010	1	3200000
4	25300000	64QAM	46.010	2	3200000
5	0	QAM_NONE	-	---	1600000
6	0	QAM_NONE	-	---	1600000
7	0	QAM_NONE	-	---	1600000
8	0	QAM_NONE	-	---	1600000

OFDM/OFDMA Overview

Channel Index	State	lin Digital Att	Digital Att	BW (sc's*fft)	Report Power	Report Power1_6	FFT Size
0	DISABLED	0.0000	0.0000	0.0000	0.0000	0.0000	2K
1	DISABLED	0.0000	0.0000	0.0000	0.0000	0.0000	2K

[zajzjkajk]

I am also experiencing the NAT Loopback issue, where all of my internal services are unavailable from inside my  network. This is extremely frustrating and disappointing and I urge you to deploy a fix as soon as possible.

The lack of communication regarding this issue is also disappointing, I spent two hours trying to debug this issue before stumbling upon this thread. There is a great deal of room for improvement both on the firmware dev side and the communication side from Rogers.

[blues_clues]

I am not too sure what our worth is on this thread anymore as firmware is being rolled out with bugs this group has identified.

[jayrabbit]

I've ordered a (expensive) router which should be here on Monday sometime and I plan to put the modem in bridge mode to see if it's just network related, or if the whole modem is stalling out.  From what I've seen on a few other message threads here, I'm not hopeful that bridge mode will fix this.

Here's another bug that I'm noticing:  Disabling DNS Proxy under the Auto section of DNS still forwards the modem IP to clients even after a modem reboot and doesn't forward the external Rogers DNS server IP's (I forget what they are - 64.71.whatever I think).  This is horribly broken.

I talked to a technician again about these issues and he said he can offer a roll-back to one of the CGN3 models which don't run the same firmware code.  One of these will work for me because I'm only on 150Mbps service and those are certified for plans up to that speed (although the modem hardware itself can actually do Gigabit connections according to Hitron).

[Pir8pete]

you rogers people want feed back here's feed back;

with the new firmware update 7-32 the modems http gets unreachable every time, was on T8 and it was fine

[code]

The connection has timed out

The server at 192.168.100.1 is taking too long to respond.

The site could be temporarily unavailable or too busy. Try again in a few moments.
If you are unable to load any pages, check your computer’s network connection.
If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the Web.

[/code]

[MisterPinst]

+1 to this issue as well on the new 7.1.1.32 firmware in bridged mode.

It would be reachable for a day or two, then seemed to take a while to reach, and then after a few days I couldn't bring up anything when trying to reach 192.168.100.1. I received the same error messages as Pir8pete.

When the router is in gateway mode I can reach it fine after 10 days and counting (knock wood).

[jayrabbit]

Ya it's definitely network-related.  I got my new router set up and the CODA modem in bridge mode (disabled Residential Gateway Function and is no longer accessible via 192.168.0.1 address - is now forwarding the WAN IP directly to the router) and it seems to be good so far.  Previously, some days I could only go like 5 minutes after a modem reboot before the network would completely disconnect on Ethernet computers ("no network access" in Windows - not just "no internet") because the router functionality of the modem would just drop out altogether, on and off again.  A few weeknights last week were the worst times for it.

I'm using a Ubiquiti Dream Machine as my router now.  Expensive, but has so many good options for monitoring network activity.  Ubiquiti has them on sale cheaper than most other online retailers, at $400CAD.  It doesn't have native DNS-over-HTTPS/TLS though, but it's a frequently requested feature for Unifi OS (the controller's Linux-based OS UI), so I'm hoping they add it eventually.

Just out of curiosity, what is Rogers' policy on DNS privacy?  Do they sell, monetize, or otherwise provide the DNS realtime searches or search history of customers (home, or business) to third-parties, outside of the scope of providing Internet services that require DNS?

[duckrabbit]

I'm glad I found this post to confirm there is an issue with the latest firmware version regarding NAT loopback and that I didn't mess something up locally. Any update on when this might get fixed?

Also, it seems that on the DDNS settings page for the 4582U, you cannot set a DDNS provider other than the 6 provided. I am using freedns.afraid.org and previously had been able to manually enter the information needed to automatically update my DNS information. This no longer works. It isn't a huge issue for me as I can do the same with a script on my computer, but curious if this ability will be added back to the firmware or if only the 6 predefined entries will remain?

[smblkpus420]

I have both of the same issues... rogers where are we at with the fix for 2 issues that shouldn't even be issues if you knew how to properly release firmware updates?
How on earth can a company release a broken update and then 2 months later its still not fixed... SHAME

[sgobiraj]

I am also having the same issue as others. The modem was super stable in bridge mode without a reboot for months on 36T8. I consistently got the advertised speed and low ping times of 5-8ms. Ever since I got upgraded to 7.1.1.x the modem has become sluggish. The internet speed starts to slow down and the ping times go into the 100-200ms range. Sometimes the pings timeout all together resulting in a total loss of internet. The 192.168.100.1 management interface becomes unreachable. Once you reboot the modem everything is fast like it was on 36T8. After a few hours or days it starts acting up again. I've even tried a factory reset. The only way to fix this is via a reboot of the modem. I've brought this up twice to the tech support staff and they say "firmware can't slow a connection down" as if they are software engineers. I'm an engineer and dumbfounded at how flawed that statement is. Their initial "fix" was to put it into gateway mode which means I'm going to get double NAT'd and going through two firewalls. I said I can't settle for gateway mode and then they say they need to send a tech. The problem is once the modem is rebooted it will be snappy again and will take hours to days to get back into that bad state. So I don't know what good a tech would do in this situation. The thing they don't seem to understand is that it was super stable on 36T8 and the only variable here is this huge firmware upgrade. How does this not raise any alarm bells?

[vari]

Rogers modem/router details:

CODA-4582U

Hardware Version	1A
Software Version	7.1.1.32

NAT hair pinning / loopback used to work flawlessly on my network. I.e. I could use my public IP plus port number to view my security cameras (relevant ports were forwarded on the rogers router). It was working up to at least May2020, however when I checked them 2 weeks ago (and even now) I could no longer use the public IP to access the cameras. All relevant ports are forwarded and if I access the cameras from a different network, it works fine so its definitely an issue with NAT hair pinning / loop back on the CUDA-4582U.  

I've never had to configure anything apart from ports to get everything to work in the past so I suspect that the router had a software update sometime after May 2020 or Rogers has changed something on their network which caused this to stop working. Any help in restoring the NAT loopback feature would be really appreciated! 

(I've taken a look at the settings in the router but nothing seems relevant to NAT loopback as far as I can tell).

[duckrabbit]

This isn't a fix, but if you are able to setup a VPN connection from your computer to a provider outside your home network, you can bypass the NAT loopback issue. The router thinks you are outside your home network in this case and you can then access the public IP. Not ideal, but at least it works. Fixing the firmware would be a better route.

[vari]

Thanks for the suggestion, but using a VPN is not a viable solution for me (especially when I usually check the cameras using my phone and I'd rather not deal with setting up a VPN on my phone).

Frankly, I'm surprised Rogers is fine with upgrading firmware for customer's devices when they have not enrolled in any beta program and the lack of communication with respect to a "Known Issues" page anywhere is rather ridiculous. I've wasted sooo many hours across several days resetting various things, reconfiguring stuff to try and find a solution to the NAT hairpining problem that appeared out of the blue. I'm also in the tech industry, and software updates / improvements to devices are common. Naturally there will be bugs but that's why you have testing, and you need to communicate with users about the known issues. At the very least give them the option to not update until issues are resolved. I'm disappointed with the way Rogers is handling this and really hope that they use this as a learning to experience to make real changes to how they handle firmware updates. I shouldn't have to read a 400+ page forum post to find out that a recent firmware update (which doesn't really seem like its even out of beta given this post's title and initial purpose) caused the issue I was running into.

Does anyone know how I can revert back to the old firmware? And how I can prevent automatic firmware upgrades in the future (or at least be notified of the fact that the firmware is going to update so that I'm not blindsided by things breaking after an update that I knew nothing about 😒)?