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

[Sour]

Never had issues with my AC86U set to Normal Mode for DHCP query frequency getting the VM IP from the Super Hub 2 in modem mode.

Don't you have to be careful with Continuous Mode though, as it can your device banned by some ISPs.

Judging by ASUS's post its the Aggressive mode that can cause the problem https://www.asus.com/support/FAQ/1043591/

TBH I haven't tried the Normal mode.

I'd previously been fine for years with SH2ac and AC68U. Not sure what triggered the problems.

It has been 4 months since it last happened so it seems to be intermittent.

Also, I'm assuming this has fixed the problem. However, it worked OK for those 4 months without this "fix" so I can't be certain.

 

[ColinTaylor]

@Sour This sounds more like an issue caused by a problem on the Virgin Media side to me. The thing with the Asus' Normal/Aggressive mode is that if there is a temporary problem with VM's DHCP server the Asus will eventually give up trying to connect. Continuous mode does what it says on the tin, it never gives up trying to connect.

Switching the Hub to router mode has a similar effect because it is now the Hub that will be constantly trying to contact VM's DHCP servers. The Asus will be connecting to the DHCP server on the Hub without any problem so the Normal/Aggressive/Continuous setting makes no difference.

I think this is a likely explanation given that this problem happened so infrequently and existed with two different types of Hub and two different types of router. I have also experienced the same sort of behaviour when there is a fault or maintenance in my area.

If you check the Hub's network log when this kind of issue occurs you will probably see messages about "partial service".

 

[Sour]

TBH my immediate assumption was that it was VM that had caused the problems.

It was only seeing the ASUS post that made me doubt that assumption https://www.asus.com/support/FAQ/1043591/

If nothing else I've ended up justifying the purchase of an AC86U with my old AC68U now an AIMesh node which means that all corners of the 3-storey Victorian terrace and garden now get a decent signal. Even my neighbours could use it as a guest when they were changing their ISP. In addition my 20 year old NTL wiring was brought up to date so hopefully good for another 20 years.

 

[Vexira]

Never had issues with my AC86U set to Normal Mode for DHCP query frequency getting the VM IP from the Super Hub 2 in modem mode.

Don't you have to be careful with Continuous Mode though, as it can your device banned by some ISPs.

It's aggressive mode because it spams, continuous doesn't have a time out.

 

[Fathorse2012]

Hello all, I am new to this forum. The reason I joined is that I recently bought ASUS RT-AX56U in June for its VPN client functions.

The AX56U is a replacement to my old TP-LINK router (2) (in NAT mod) in the reading room which is behind another TP-Link router (1) in the living room that connects to the WAN (internet).

The strange thing is, when I connect the AX56U to TP-Link router (1) with the same old LAN cable and power on. AX56U says "the cable is unplugged" for the WAN connection. I hook up the old TP-LINK router (2) and everything back to normal.

I then hooked up the AX56U direction to my ISP (which is DHCP, no logon required). It is successful! So, back to replacing TP-LINK Router (2), it still said "the cable is unplugged". I took the ASUS router back to the seller. They tested it and claim the router is function as normal.

I suspected -- Does this AX56U pick which UTP cable to connect with? However, the cable from TP-LINK router (1) has been laid inside the walls between the living room and reading room. It will be very hard to replace such cable (at least to me).

So, back to hooking up my new AX56U, the seller did suggest me to upgrade the firmware. So, I tried to upgrade the firmware. Wow, guess what? It works!! There is no "cable is unplugged" errors any more.

Old (out of the box) firmware: 3.0.0.4.384_7764-gb0b0c6f
new download firmware: Version 3.0.0.4.384.8986

In the syslog, I did observe there were messages saying "DHCP did not function properly." when the problem occurred. Therefore I am posting this experience here.

I also tried to install ASUS-Merlin RT-AX56U_384.18_0_cferom_pureubi, it shows "the cable is unplugged" again. I fell back to official firmware, it works. (It also works for the latest ASUS firmware, Version 3.0.0.4.384.9424.

I guess ASUS implemented some fix in the new firmware, but they have not propagated to the ASUS-Merlin version yet.

 

[Smokey613]

You might try using a small inexpensive switch between the AX56U and the existing network cable. I have used this solution in the past with great results. Just plug the cable into the switch and then use a new cable from the switch to the 56U.

https://www.amazon.com/dp/B001EVGIYG/?tag=snbforums-20

 

[Fathorse2012]

You might try using a small inexpensive switch between the AX56U and the existing network cable. I have used this solution in the past with great results. Just plug the cable into the switch and then use a new cable from the switch to the 56U.

https://www.amazon.com/dp/B001EVGIYG/?tag=snbforums-20

Remember I had TP-LINK Router (2) and TP-LINK Router (1)? I did try to connect my AX56U to TP-LINK Router (2) and then, TP-LINK Router. It didn't work either. But I never used the TP-LINK Router (2) as a switch though. But it is too late for me to test that setup. I have 'bricked' my TP-LINK Router (2) in the course of flashing it to OpenWRT. (sad).

[Edit] It turns out that I do have a router to spare and I have setup it as a switch between AX56U and TP-Link router (1). Both Asus official firmware and Asus-Merlin RT-AX56U_384.18_0 work! Thank you! But I still wonder how it fixes the problem, is it a cable problem afterall?

[Edit 2] I decided to give it one more test -- turn the intermediate router NAT back on instead of using it as a switch. And it still works. But I am still scratching my head. Is it a firmware or a cable, or a discrepancy in matching the AX56U with a proper router?

 

[Vexira]

Hello all, I am new to this forum. The reason I joined is that I recently bought ASUS RT-AX56U in June for its VPN client functions.

The AX56U is a replacement to my old TP-LINK router (2) (in NAT mod) in the reading room which is behind another TP-Link router (1) in the living room that connects to the WAN (internet).

The strange thing is, when I connect the AX56U to TP-Link router (1) with the same old LAN cable and power on. AX56U says "the cable is unplugged" for the WAN connection. I hook up the old TP-LINK router (2) and everything back to normal.

I then hooked up the AX56U direction to my ISP (which is DHCP, no logon required). It is successful! So, back to replacing TP-LINK Router (2), it still said "the cable is unplugged". I took the ASUS router back to the seller. They tested it and claim the router is function as normal.

I suspected -- Does this AX56U pick which UTP cable to connect with? However, the cable from TP-LINK router (1) has been laid inside the walls between the living room and reading room. It will be very hard to replace such cable (at least to me).

So, back to hooking up my new AX56U, the seller did suggest me to upgrade the firmware. So, I tried to upgrade the firmware. Wow, guess what? It works!! There is no "cable is unplugged" errors any more.

Old (out of the box) firmware: 3.0.0.4.384_7764-gb0b0c6f
new download firmware: Version 3.0.0.4.384.8986

In the syslog, I did observe there were messages saying "DHCP did not function properly." when the problem occurred. Therefore I am posting this experience here.

I also tried to install ASUS-Merlin RT-AX56U_384.18_0_cferom_pureubi, it shows "the cable is unplugged" again. I fell back to official firmware, it works. (It also works for the latest ASUS firmware, Version 3.0.0.4.384.9424.

I guess ASUS implemented some fix in the new firmware, but they have not propagated to the ASUS-Merlin version yet.

Have you tested the new Merlin alpha that should be have contious mode.

 

[Fathorse2012]

Have you tested the new Merlin alpha that should be have contious mode.

I looked up the Pre-beta test builds page and I could only locate RT-AX58U_384.19_alpha1. I gave it a try.
It does have "Continuous mode" and it works.

 

[Caruso Mirko]

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.

thank you so much. In my opinion it is only a bug of firmware 384.18 because the line works regularly. It should be mentioned to the developers of asus merlin.

 

[Oluwatobiloba]

I am having the "WAN_Connection: ISP's DHCP did not function properly." in all modes of DHCP query frequency, Extend the TTL value, and Spoof LAN TTL value. This started happening when I upgraded to 384.18 and occurs every 36 hours or sooner.
I found a quicker way to fix the connection is to change the DHCP query frequency to another setting and the connection is restored within a minute.

 

[spiff72]

Hey all, came across this thread when i searched for "WAN_Connection: ISP's DHCP did not function properly"...

I have an AX58U running Merlin 384.18_0 (I know that .19 is available, but I am going to wait until tonight to upgrade it - see below. I also have another of the same router used as an AiMesh node, but that one is on the stock Asus firmware (3.0.0.4.384_9505-g6537ef5), and is up to date).

My issue is that I get occasional momentary internet dropouts, where PC's on the network will be unable to get to web pages, games will disconnect, etc. I decided to look at the router log to rule out the router as the problem (I expected that the issue was our Spectrum service), and I also noted that during the 2 dropouts today, the lights on the modem seemed to indicate that its connection to the internet was active.

I found the above mentioned error message occurred at the same times as the outages (which both lasted 30 seconds according the messages in the log. The drops were also exactly (minus 1 second) 5 hours apart, so I am going to wait to change anything in the router until another 5 hours pass to see if this timing is consistent (they also happened very close to the top of the hour - 09:59:25 and 14:59:24).

Is the current fix to simply change the DHCP Query Frequency from Agressive to Normal? Or would I be better off reverting the main router to Asus stock firmware? I went back to Merlin mainly because I liked the enhanced parental controls, but if it means I have a stable connection, I am willing to go back to stock until Merlin rolls these changes in. Or is there a chance that Merlin 384.19 includes a fix? The changelog I read didn't seem to mention this at all, but there are mentions of merges:

- UPDATED: Merged GPL 384_9354 for AX models.
- UPDATED: Merged GPL 384_81992 for mainline models.
- UPDATED: Merged SDK + binary blobs 384_9354 for RT-AX58U.
- UPDATED: Merged SDK + binary blobs 384_9107 for RT_AX88U.
- UPDATED: Merged binary blobs + SDK 384_81981 for RT_AC5300.
- UPDATED: Merged binary blobs + SDK 384_81992 for RT-AC86U.
- UPDATED: Merged bwdpi components from 385_20630 firmware
image for RT-AC68U.

 

[spiff72]

Well - quick update...

The router did it again at exactly 1700 here again (2 hours after the last one this time). I went ahead and updated to 384.19, and I see that the "continuous" mode is an option for the DHCP Query Frequency is now available. I have now switched to this option to see if the issue occurs again. I will report back to see if this works.

 

[jorgsmash]

I just had this issue last night and it lasted a solid 2 hours or so. First time I've had this issue. I was thinking my provider (Spectrum) was having issues. The Internet light on my router was red. I was surprised to see this thread here, as I didn't search for the issue I just noticed it on the first page of the forums. So is the current recommended fix to update to 384.19, and switch to the "continuous" mode?

 

[spiff72]

I just had this issue last night and it lasted a solid 2 hours or so. First time I've had this issue. I was thinking my provider (Spectrum) was having issues. The Internet light on my router was red. I was surprised to see this thread here, as I didn't search for the issue I just noticed it on the first page of the forums. So is the current recommended fix to update to 384.19, and switch to the "continuous" mode?

So far so good for me. I had one outage last night after making the changes, but I happened to be in the room, and I saw the modem appeared to reboot itself (maybe it got a firmware update?). So I can't blame that on the router.

 

[spiff72]

Well, I am still having the occasional momentary drops - just had one a moment ago, but I don't think it was the modem restarting this time (but I wasn't in the same room. When I came to look at it, the modem was connected.

I am about ready to try switching back to stock firmware at this point. This is a frustrating problem - esp when gaming and the connection drops.

 

[Lotta Cox]

Check you modem logs. Look for T3 and T4 timeouts.

 

[spiff72]

this is the modem i have:

https://d15yx0mnc9teae.cloudfront.net/sites/default/files/Spectrum%20D3_1%20eMTA%20QIG_manual.pdf

I seem mention of accessing the interface at 192.168.100.1, but that doesn't work for me. Does the computer need to be connected to the modem directly (bypassing router)? My network is set up with router as 192.168.1.1. I will have to try again later, as I am just heading out of the house for a few hours.

 

[Lotta Cox]

this is the modem i have:

https://d15yx0mnc9teae.cloudfront.net/sites/default/files/Spectrum%20D3_1%20eMTA%20QIG_manual.pdf

I seem mention of accessing the interface at 192.168.100.1, but that doesn't work for me. Does the computer need to be connected to the modem directly (bypassing router)? My network is set up with router as 192.168.1.1. I will have to try again later, as I am just heading out of the house for a few hours.

No it does not need to be directly connected to pc. Just same lan. You may be blocked from accessing that page.

 

[spiff72]

No it does not need to be directly connected to pc. Just same lan. You may be blocked from accessing that page.

That wouldn't surprise me with Spectrum - God forbid the customer can actually look at system logs to troubleshoot...