ASUS firmware DHCP "Continuous Mode" potential fix for "ISP's DHCP did not function properly"

[Icemanz]

FYI - creating this thread because I can't find this issue/solution concisely documented anywhere else, please add any info below.

I can see a number Australians on the new NBN (a government run, centrally managed ISP 'platform') are experiencing issues with DHCP and asus routers in particular.

While not isolated to the NBN. There does seem to be issues with ASUS's WAN DHCP implementation that are being exacerbated by the odd DHCP setup of this particular internet serving platform; very short lease times, CGNAT and unusual DHCP behavior I can't capture because tcpdump isn't standard on these things, are possible factors here.

The primary symptom is the log message: "WAN_Connection: ISP's DHCP did not function properly", 'disconnected' or similar message in the WAN section of the GUI then some
some period of connection issues - depending on how long it takes your ISP. This happens anywhere between a couple of times a day to a few times an hour for some people.

There are a few examples reported in this forum as well (and admittedly they have had non DHCP causes):

* https://www.snbforums.com/threads/asus-rt-ax92u-isp-connection-issues.61399/#post-551676
* https://www.snbforums.com/threads/l...3-logical-port-3-link-down.61658/#post-550267
* https://www.snbforums.com/threads/wan_connection-isps-dhcp-did-not-function-properly.56226/

"Jack" from asus australia has made a reference to a new feature in the asus firmware called "Continuous mode" reference wp forum 1 - while I've reached out for more details. His reply says it's an upcoming feature baked in to the 'latest' firmwares - no info as to when. I will test on an rt-ac68u based on the GPL 385_10002 to see if it has it then I may have to jump off merlin for a bit to the latest asuswrt prod firmware.

The new mode is activated via an nvram setting - I'm not prepared to post it immediately as asus reps have chosen not to but I will PM it to Merlin if he doesn't already know about it.

 

[Stephen Harrington]

@Icemanz
Not sure why the reluctance to post the experimental “continuous” dhcp_mode setting ... maybe I missed something but Jack did not specifically ask me to keep it confidential when he sent me the instructions yesterday. I think his concern is more that it’s not available in all models and only in recent firmware versions, as yet undefined, and the “support load” that may bring down on him perhaps?

If it is indeed “secret” then @RMerlin may be well aware of it but unable to talk about it due to his relationship with Asus?

Interested to see your results as a friend of mine has the issue intermittently and it may be a fix for him. What Aust ISP/RSP are you on and what NBN technology?

 

[Icemanz]

TL;DR: Unlikely to see this in merlin firmware until it re-bases on 386.x code unless he chooses to backport the feature in some way.

I've asked merlin and his response was the feature is not in "384_81351 which is used for 384.15" (current at time of writing) and he's only seen it in the newer 386.x code.

This tracks with my experience of trying to turn it on with the latest public firmware of 3.0.0.4.385.20252 for my RT-AC68U - where the nvram flag change didn't actually elicit the desired result.

I've reached back out to Jack to find out if I need some beta asus firmware.

My limited understanding of how the fix is supposed to work is - nvram flag causes the DHCP server to start with different parameters but it might also require a different binary or something else so it might not be trivial to port.

==

Stephen: If asus/jack wanted it public he could have posted it in public threads in several places, instead he's asked people to PM him. So I'm just trying to be polite to them.

My NBN issue:

AussieBroadband - not on CGNAT, is a 100/40 HFC service. Was installed in the last 48 hours. Was seeing the DHCP error anywhere between 5 minutes to 4+ hours. Always getting 1 error in the log when the HFC modem reboots but it also appears later and cuts my internet off until dhcp sorts itself out, sometimes that's 5 minutes, sometimes it's 30+ minutes until I reboot something. Sometimes the HFC modem is rebooting itself.

In any case, the root cause here seems to be some kind of HFC issue the NBN are investigating. Might a faulty modem, might be something else screwing up the frequency in the area(CM's usually reboot when they lose the plot).

 

[momall]

for what its worth, i used to have this issue in earlier builds. I stopped using DNS Privacy under WAN settings and cloud flare as a resolver. The problem went away at that time.

 

[Stephen Harrington]

@Icemanz - thanks, some good info in your last reply, much appreciated.
I'll refrain from posting the instructions for now also then - to err on the polite side and follow your lead.
Issue I'm tracking for a (less technical) friend is much more intermittent, but also Aussie Broadband.
NBN FTTN on a fully bridged VDSL modem (Broadcom chipset) to an RT-AC86U (which he bought on my recommendation).
Sounds like you may have more than one fault going on?

 

[frooty]

Just a heads up, it's not just an Oz ISP problem - I've been battling with this since I changed over to a LTE based internet. At first I thought I had a faulty Huawei B525 LTE router so I changed it for a Huawei B725 but the problem persists. The best results I've had so far was to set the lease time on the B725 (in bridged mode) to 1 week, set the DHCP mode on my Asus to "normal" & set the "Extend TTL value" to Yes - this seems to have stopped the internet dropping problem but the Asus still reports the internet as "disconnected" on occasions - even though it isn't.

Eagerly awaiting the results of your enquiries as this has been driving me nuts lately & I've googled the problem till my eyes were bleeding.....

 

[Vexira]

Half to see that I'm not the only one having this issue, it's been driving me insane, especially when it went out for the good part of a day and all I got was that error, I found a Mac address change can alleviate it sometimes other times I've had to bear with it.

I can't wait till the fix becomes a reality.

 

[Vexira]

I'm hoping that the next firmware update will have it included.

 

[Icemanz]

Update, I still can't test this because I don't have this issue on my Optus HFC connection (sane 2 day DHCP leases) and my ABB NBN HFC connection won't stay stable for 15 minutes straight.

What is the proposed fix?
If you're very savvy - you might be able to run the DHCP daemon on your router with the same options - (dont ask me how):

The different behavior is - something adds "-t1 -T5 -A0" parameters to udhcpc daemon.

From the from the busybox manual translates to:
-t1 - 1 retry - send one packet only
-T5 - increase lease wait time to 5 seconds from the default of 3 seconds
-A0 - wait zero seconds after failure to retry (default is 20)

My CLI only had the options by default on non aggressive mode for:
-O33 -O249
Which from what I can tell means 'request options DHCP 33 and 249' .. which are as follows (and nothing to do with timing)

DHCP Option 33
In DHCP Option 33, the syntax defines a Destination IP and a Next hop. These are represented in concatenated hexadecimal values.

DHCP Option 249
In DHCP Option 249, the syntax defines a. the Subnet mask in CIDR notation, b. a Destination descriptor, c. a Next hop. These are represented in concatenated hexadecimal values.
Which seems to be microsofts unofficial version of option 121

Which version has this?
In regards to how soon asus might release the code for merlin to look at (unless he's got code ahead of the public pages):

I've been provided with test version (for non DSL version of RT-AC68U) - note the 9 not 3 build number - this has the nvram flag you can set to get different DHCP behavior.

RT-AC68U_9.0.0.4_385_20294-g788ee16.trx
(I won't distribute, please contact ASUS direct if for no other reason they can track how many people are keen to have this fixed and if it worked for them, thanks)

Latest source I can see on the page:
Version 3.0.0.4.385.10000
2019/12/11

Latest compiled FW I can see (ahead of the source?)
Version 3.0.0.4.385.20252
2020/02/1336.41 MBytes

And the current merlin release is based on 385.10002 as per his post (might have newer bits, I don't know).

 

[AndreiV]

Saw this the other day :

I fixed this by using these WAN settings:

"DHCP query frequency" -> "Normal"
"Extend the TTL value" -> "Yes"
"Spoof LAN TTL value" -> "Yes"

https://www.snbforums.com/threads/your-isps-dhcp-does-not-function-correctly.43178/

 

[Vexira]

Saw this the other day :



https://www.snbforums.com/threads/your-isps-dhcp-does-not-function-correctly.43178/

Sadly didn't work for me last time I had the issue and tried it.

I'm waiting for this firmware fix to become a reality.

 

[frooty]

Any movement/news on this issue?

 

[Icemanz]

OK, I am not experiencing now my connection is stable. However I now believe my experience receiving this error had nothing to do with DHCP.

Digging further, the error "ISP's DHCP did not function properly" seems to be thrown by this bit of code in wanduck:
https://github.com/RMerl/asuswrt-merlin.ng/blob/master/release/src/router/rc/wanduck.c#L2605

(I'm assuming this is semi current, I may be wrong I am not a C coder, someone who knows the codebase please comment).

And that doesn't read to me like it's done any kind of ACTUAL error checking or error condition handling from the DHCP daemon. Instead it's something like "if I'm in DHCP mode (which is - listen for an IP on the wan port from the ISP - as opposed to ppoe or static IP) and I don't end up in a connected state with an IP, then , after ruling out failure states that I do recognize (like ppp auth failure, wan cable unplugged), etc then ultimately throw a bit of text into the log that says: "ISP's DHCP did not function properly" (see line 2605.

I was getting this because my NTD was freezing - so the short DHCP leases were not able to renew - then rebooting causing the wan port to go up and down rapidly. I note the router throws this error every WAN port flap. It might trigger in legitimate DHCP issues but I think but I cannot see anything in wanduck that says explicitly IF udhcpc throws XYZ error (ie what you'd need to accurately diagnose an invalid DHCP response) then claim DHCP malfunctioned.

Where do you go from here? Push back to ASUS with as much info and specific symptoms as you can. This is likely to have multiple causes.

TL;DR IMHO - it's not actually DHCP, it's the router just not ending up with an address, some DHCP errors may contribute to this.

 

[AndreiV]

Where do you go from here? Push back to ASUS with as much info and specific symptoms as you can. This is likely to have multiple causes.

ASUS should be told and make Merlin aware , he can check it out.

 

[Frankflash]

ASUS should be told and make Merlin aware , he can check it out.

you will have to talk to jack from asus Austraila about it

 

[jackiechun]

you will have to talk to jack from asus Austraila about it

Hopefully I'm tagging the right person, @Jack Yaz

EDIT: whoops wrong person! Thanks @Frankflash, correct person is https://forums.whirlpool.net.au/user/587606

 

[Frankflash]

Hopefully I'm tagging the right person, @Jack Yaz

no Jack Cheng pm him on whirlpool forums under modem / router section under asus

 

[Frankflash]

Hopefully I'm tagging the right person, @Jack Yaz

EDIT: whoops wrong person! Thanks @Frankflash, correct person is https://forums.whirlpool.net.au/user/587606[/QUOTE
try jack_cheng@asus.com

 

[Frankflash]

Hopefully I'm tagging the right person, @Jack Yaz

EDIT: whoops wrong person! Thanks @Frankflash, correct person is https://forums.whirlpool.net.au/user/587606

try jack_cheng@asus.com

 

[Icemanz]

Hey guys, none of this is new information (although it might be to people reading the DHCP error message red-herring).

I'm pretty sure both asus and merlin know the wanduck code is crap. They don't need me to give them my poor interpretation

What I meant by reach out to asus is: If you're experiencing issues with this error message, ask them for support and maybe they'll bother to put some time into fixing the code so it spits out something more informative.