I recently installed a new AX88U router at home and today internet access went down for a few minutes. When I checked the log, I noticed this error in router logs and this matches with the time when internet access had gone down:
Nov 21 12:16:57 rc_service: httpd 1219:notify_rc restart_wan_if 0
Nov 21 12:16:58 WAN Connection: ISP's DHCP did not function properly.
Nov 21 12:16:58 nat: apply redirect rules
Nov 21 12:16:59 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Nov 21 12:17:00 wan: finish adding multi routes
Nov 21 12:17:00 miniupnpd: shutting down MiniUPnPd
Nov 21 12:17:00 miniupnpd: version 1.9 started
Nov 21 12:17:00 miniupnpd: HTTP listening on port 48482
Nov 21 12:17:00 miniupnpd: Listening for NAT-PMP/PCP traffic on port 5351
I have Rogers white CODA modem running in bridge mode and AX88U running in wireless router mode. Anyone seen similar issues with AX88U before?
I have an Asus AC 86u, connected to Coda in bridge. I have noticed this error log too. I sure would like to know the answer as well.
Fwiw, there have been reports of problems with Rogers DHCP servers for several weeks, so, it appears to be another ongoing Rogers problem that doesn't seem to be receiving any recognition. Here's two threads from DSLReports on the subject:
@vikas-arora Rogers uses Native IPV6. Have a look at the following post:
If you do go ahead and enable IPV6 in the modem's settings, keep an eye open for strange connection issues to Google services, Instagram and Whatsapp. From what I've seen posted, that's usually an indication of IPV6 issues at the CMTS. Android devices seem to be particularly prone to IPV6 issues as they don't fail over to IPV4 as they should, leaving the device hanging when there's an IPV6 issue in the path from the device to the end server.
Also note, IPV6 DNS settings were included in Version 2.x. The 4582 modems are now running a brand new version these days, version 126.96.36.199, which has a new kernel to support DOCSIS 3.1 upstream. Seems that the IPV6 DNS settings were not included in version 7.x. Given that omission, you might not want to run IVP6. Two steps forward, one step back, as then say.
DOCSIS 3.1 upstream has been enabled at some CMTS locations and in their connected modems. This can be seen in the STATUS .... DOCSIS WAN tab, specifically in the very bottom OFDM/OFDMA section, which will show two OFDMA channels as being disabled or enabled. For those modems with OFDMA enabled, usually only one of two channels is enabled.
Thanks for the warning @Datalink 🙂 I'd rather not create more problems for myself, so I will not enable IPv6.
From what you have mentioned, it looks like Rogers have enabled DOCSIS 3.1 upstream in my area. I can see OFDMA channels, with one disabled, in my modem page. This also aligns with what a tech had told me earlier this week that they have been running into some issues with OFDMA and that the network might take a while to reach its optimal state. It sounded like they have been trying to optimize parameters because of huge volume of complaints they have been receiving recently.
I have had absolutely no problems with Rogers in last 6 months until earlier this week when I switched my modem to bridged mode. I don't even remember when it got switched to router mode in first place! I started to go through all the settings when I bought a new ASUS WiFi router and my problems started when I configured modem into bridge mode.
I'll monitor my router for the next few days and then decide what to do with AX88U. I absolutely love this router for its coverage and low latency, but at the same time I don't want to be stuck with a router that keeps running into issues with Rogers. Not sure but it seems people all over the world are running into this kind of issue with ASUS routers (or maybe OpenWRT based firmware).
@vikas-arora, I don't know if you're aware that Asus has embarked on the second, recent rewrite of its firmware. I think that the last was done around 4 years ago. Each rewrite is a major development, mostly behind the scenes with the user interface remaining nearly identical as the previous version. So, this time its a jump to a .386 version from the .384 versions. I don't know where the AX88U fits in with the grand scheme of the firmware versions, but, it looks like Asus is trying to end up with a single unified version across the various router types and versions, keeping in mind specific hardware capabilities of the various router types and versions.
It might be worth considering the Beta version, currently at 188.8.131.52.386.40947 Updated 2020/11/12
If you haven't been watching the Small Net Builder forums, the Asus threads are located at:
The ASUSWRT - Official threads are located at:
The thread for the beta version is the top thread on that sub-forum:
Beta ASUSWRT 386 RC2 public beta with full functions AiMesh 2.0
Also worth considering is the new Merlin version. Merlin has basically given up trying to keep up with the current situation where there are a multitude of versions used across the various existing Asus router types, so, he's been waiting for Asus to get its act together with version .386 That wait appears to be over, not completely, but getting there. So, there is now a Merlin Alpha build .386 as well. The Merlin sub-forum is located here:
In the Regular Thread section, there is a top thread titled:
[Thread - 1] [ 386.1_Alpha Build(s) ] Testing available build(s)
Looking at this thread, it looks like there's a new ALPHA3 Build available dated 2020-11-22. The build versions are stored on Merlin's One Drive, which is linked at the top of the thread.
So, for what its worth, if you're feeling adventurous, it might be worth trying the Asus or Merlin .386 build to see if it makes any difference in the DHCP situation, although, if this is an ongoing Rogers DHCP problem, it might not make any difference at all. There's no way of really knowing until you try the newer builds, looking for any difference in DHCP performance.
I recently went digging around in the settings of my 88U and found in the Wan config, under "Special Requirements from ISP", and changed the setting from it's default "Agressive" to "Normal". This seems to have solved the problem for now! If it returns I will share.