05-31-2016 08:42 AM - last edited on 03-14-2018 04:23 PM by RogersRoland
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.
05-31-2016 08:58 AM - last edited on 12-10-2021 04:31 AM by RogersIan
This post will be updated with a summary of the feedback reported with this firmware. I’ll be collecting all of the feedback and sharing it with internal teams as appropriate; I’ll do my best to respond to you in this thread but might not be able to reply to every single post. I may also include other issues identified through our own internal testing.
Thanks for your help!
Hitron CODA Series
Hitron CGN Series
Hitron CGN3
Enhancement requests
05-31-2016 12:32 PM
Thanks for your work on this guys.
I'm wondering - is there going to be an upcoming firmware update to start addressing the performance issues with IPv6 and IPSec? I still can't get more than about 20-25Mbps using IPSec (when I get can ~200Mbps to the same host with SSH/TCP).
05-31-2016 12:37 PM
The correction for the low speed when using ESP packets without UDP/TCP encapsulation (which is more common with IPv6) is not included in 4.5.8.21T6. It will however be added to the issue list for tracking.
05-31-2016 12:42 PM - edited 05-31-2016 12:43 PM
I assume you meant to say that encapsulation is more common in IPv4 (and ESP is more common in IPv6)?
Come to think of it, I don't think I've ever seen an IPv6 IPSec connection configured for 4500/NAT-T... I think racoon maybe even complains if you try this but I may be wrong - so I'd say 4500 encapsulation is basically non-existent with IPv6 in common practice.
05-31-2016 06:45 PM - edited 05-31-2016 06:46 PM
Okay you should let testers know if they are using the Modem/Router that they need to do a factory reset after getting any new firmware update as I don't use mine in bridge mode. IPv6 will not show up till a factory reset.
Thanks,
Daniel
05-31-2016 11:44 PM
06-01-2016 12:09 AM
Follow this link @CommunityHelps and on the right hand side of the linked page is another link to "send this user a private message" Follow that link to the message composition page, fill in the title of the message and the text that you want to include and hit the SEND button. A moderator will get back to you with further details and instructions.
06-01-2016 12:18 AM
06-01-2016 07:22 AM
@Triple_Helix wrote:Okay you should let testers know if they are using the Modem/Router that they need to do a factory reset after getting any new firmware update as I don't use mine in bridge mode. IPv6 will not show up till a factory reset.
Thanks,
Daniel
I have updated the notes in the second post to reflect that statement and provide more precisions.
06-01-2016 07:36 AM
06-01-2016 07:41 AM - edited 06-01-2016 07:44 AM
@Mo786 wrote:
I noticed enabling bridge mode breaks VOIP... had to go back in gateway mode which now prevents me to enable IPV6
In gateway mode to enable IPv6, you have to perform a one-time factory reset from the GUI. After performing this step, IPv6 will work correctly.
I am however interested to understand what is broken with VoIP in bridge mode. Do you believe it is an issue with the modem that should be adressed or a problem with your router configuration? I believe in gateway mode, we have a SIP ALG enabled which can help VoIP with NAT over IPv4.
06-01-2016 08:40 AM - edited 06-01-2016 08:49 AM
The SIP/ALG should be disabled as a default setting. This has caused continuous issues with users attempting to run VOIP, and the only solution has been to disable it or buy a third party router giving the user the ability to disable it, after which the VOIP phone works as it should. Front line tech support has obviously been instructed to turn down any requests to disable it and direct users to the Techxperts who will charge $69.99 to flip the disable/enable switch. This setting is also not saved in the phone settings, so if there is a power bump and the modem restarts, the SIP/ALG is once again enabled, putting the user back at square one, facing another $69.99 charge.
http://www.voip-info.org/wiki/view/Routers+SIP+ALG
06-01-2016 09:07 AM
I really wish I was able to test that firmware, however, there's too much ESP traffic on my network to try it.
Do we have an ETA as to when the ESP issues will be fixed within this new firmware?
Thanks a lot for making this available to us by the way, much appreciated!
06-01-2016 10:20 AM - edited 06-01-2016 10:21 AM
@cyco wrote:I really wish I was able to test that firmware, however, there's too much ESP traffic on my network to try it.
Do we have an ETA as to when the ESP issues will be fixed within this new firmware?
Thanks a lot for making this available to us by the way, much appreciated!
I don't think this trial firmware breaks ESP performance - ESP (and all non TCP/UDP/ICMP performance on Rogers) is already broken and the "known issues" list posted at the top of this thread is just acknowledging that this is an issue and that it's on the list of issues to eventually fix.
In my own experience, protocol 41 (IPv6 tunelling) and protocol 50 performance on the Rogers network has had poor performance for quite some time now - at least a couple years.
One thing I'm wondering about though - protocol 41 performance was poor on with the DPC3825 as well. I'm not sure this is an issue with the ACSMR firmware specifically but hopefully the RogersDave et al can track the issue down.
06-01-2016 10:37 AM
@Datalink wrote:The SIP/ALG should be disabled as a default setting.
Point noted. I have raised as an enchancement request (and updated the second post) that the SIP ALG setting should be exposed in the GUI.
06-01-2016 10:40 AM
@SimplePanda Thanks for the answer. I just never noticed any issues with the 3 of my VPNs running for work. Which is why i'm skeptical to try the newer firmware.
06-01-2016 03:34 PM
My CGN3ACSMR is in Bridge mode and so far I have not noticed any issues with this Trial firmware. I have 3 VoIP systems and all work as I expect. My L2TP over ipsec is stable when used.
06-01-2016 04:22 PM
Running 4.5.8.21 here now thanks in bridge mode
good so far
06-01-2016 04:34 PM
06-01-2016 04:41 PM - edited 06-01-2016 04:45 PM
@Triple_Helix wrote:Well all looks good here via my VPN via L2TP over IPsec as well. 250/20 plan.
Thanks,
Daniel
The issue isn't with NAT-T IPSec (port 4500 UDP encasulation) on IPv4. That works fine as it's tunelling over UDP.
The issue is with IP->next header->50 ESP encapsultion (pure ESP IPSec). It's definitely a problem on IPv6 and while I haven't tested, probably on IPv4 as well. IPv4 protocol 41 (IPv6 encapsulation) has similar performance problems so it seems the issue is with non UDP/TCP/ICMP packets.
FreeBSD 11-CURRENT to FreeBSD 11-CURRENT.
DO-TOR to DO-TOR over SSH (IPv6) = ~600Mbps.
DO-TOR to DO-TOR over SSH over IPSec (ESP) = ~600Mbps.
DO-TOR to Rogers 250u over SSH (IPv6) = ~270Mbps.
DO-TOR to Rogers 250u over SSH over ESP (Ipv6) = ~20Mbps.
Definitely a Rogers protocol 50 (ESP) issue, which Rogers has been able to reproduce on their end (hence why it's in the release notes as a known issue).
While this doesn't seem like a big deal right now it will become a very big deal as IPv6 becomes more pervasive. ESP IPSec tunelling is the RFC compliant way to do peer-to-peer in an all IPv6 world.