Asus AX88U - WAN Connection: ISP's DHCP did not function properly

[vikas-arora]

Hi,

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[1519]: shutting down MiniUPnPd
Nov 21 12:17:00 miniupnpd[29380]: version 1.9 started
Nov 21 12:17:00 miniupnpd[29380]: HTTP listening on port 48482
Nov 21 12:17:00 miniupnpd[29380]: 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?

Thanks!

**Labels Added**

[Hucklebury]

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.

[-G-]

Did you have any other devices (in addition to your router) plugged into your modem's LAN ports while it was in bridge mode?

[Hucklebury]

I do not have anything else connected to the Coda.

[vikas-arora]

No, there’s nothing else other than the router plugged into the modem. I am on stock ASUS firmware.

I was wondering wether DHCP error message was the trigger or the first log (notify_rc restart_wan_if 0) was the trigger. Also, I noticed that the DHCP error message even gets printed when router is restarted, but it does end up getting an IP assigned. Maybe something triggers WAN 0 restart due to which DHCP assignment process happens again. I looked at the log file multiple times and there wasn’t any error before WAN 0 restart log message. Lot of people have reported WAN link down message before this sequence but in my case it just appears to be an abrupt event.

[Datalink]

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:

https://www.dslreports.com/forum/r32838045-rCable-WAN-dhcp-issue-on-rCable-suggestions

https://www.dslreports.com/forum/r32876297-rCable-Weekly-at-least-disconnections-WAN-DHCP-issue

[vikas-arora]

I was thinking of enabling IPv6 since CODA modem runs a dual stack. Maybe that might make some difference on CMTS side. Do you know what the settings are supposed to be for IPv6? IPv6 native?

[Datalink]

@vikas-arora Rogers uses Native IPV6.  Have a look at the following post:

https://communityforums.rogers.com/t5/Internet/Rogers-IPv6-Status/m-p/373238#M36710

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 7.1.1.33, 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.  

[vikas-arora]

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).

[Datalink]

@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 9.0.0.4.386.40947 Updated 2020/11/12

If you haven't been watching the Small Net Builder forums, the Asus threads are located at:

https://www.snbforums.com/forums/asus-wireless.37/

The ASUSWRT - Official threads are located at:

https://www.snbforums.com/forums/asuswrt-official.51/

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

https://www.snbforums.com/threads/asuswrt-386-rc2-public-beta-with-full-functions-aimesh-2-0.65235/

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:

https://www.snbforums.com/forums/asuswrt-merlin.42/

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. 

[vikas-arora]

Found this thread on snbforums and it seems to capture the problem in a very clear way - seems like there is some issue in dhcp client or it’s configuration on wan interface.

https://www.snbforums.com/threads/wan_connection-isps-dhcp-did-not-function-properly.56226/

I am still within the return period, therefore I have decided to return this router. I don’t want to have to live with a workaround for a problem that doesn’t seem to have any solution in sight. There are a huge number of threads on this problem (from all over the world) and no one has found a solution for this yet.

I also ran my router in AP mode for a couple of days, but then why the heck should I pay so much if I wanted to use it only in AP mode.

[jmitropoulos]

Hi all,

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.