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.
Thank you for your interest in the 126.96.36.199 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 188.8.131.52 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.
I have the same issue...modem upgraded to 184.108.40.206 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.
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 220.127.116.11. This is a fairly simple question to ask as I'm sure that they are aware of it.
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...
I'm having a bunch of connectivity issues related to 18.104.22.168.
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 22.214.171.124 and 126.96.36.199) 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:
This menu displays general information of the device
|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|
This menu displays both upstream and downstream signal parameters
|Gateway IP Address|
|DHCP Lease Time||😧 6 H: 18 M: 42 S: 41|
|Port ID||Frequency (MHz)||Modulation||Signal strength (dBmV)||Channel ID||Signal noise ratio (dB)|
|Receiver||FFT type||Subcarr 0 Frequency(MHz)||PLC locked||NCP locked||MDC1 locked||PLC power(dBmv)|
|Port ID||Frequency (MHz)||Modulation||Signal strength (dBmV)||Channel ID||Bandwidth|
|Channel Index||State||lin Digital Att||Digital Att||BW (sc's*fft)||Report Power||Report Power1_6||FFT Size|
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.
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).
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
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.
+1 to this issue as well on the new 188.8.131.52 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).
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?
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?
Rogers modem/router details:
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).
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 😒)?