Asus RT-AC88U merlin 386.1_2 getting drops on Verizon FIOS "WAN_Connection: ISP's DHCP did not function properly."

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

bluepoint

Very Senior Member
After a lot of research on this issue, I think part of the confusion/problem is the "ISP DHCP does not function correctly" is a very generic message and will come up for any number of reasons. Bad WAN cable can cause it, issue with your ISPs hardware or line to your house, etc. So for some people replacing the cable will help, but for ones like me where the issue just started after going to 386, it appears to be code related. I see Asus intentionally added the "continuous" mode option in the WAN DHCP settings to address a problem people were having with short lease times not renewing properly, but I never had that issue before even though I've been on FIOS for years with this router (using 384.x code). I will try the continuous mode (which apparently just makes the router wait longer before giving up on DHCP or something) but other than that my only option will be going back to 384.

Unfortunately this generic error in the log isn't giving enough info to narrow down each person's issue. I guess I could play with the log settings to see if I can get more DHCP messages logged on the WAN, or put a sniffer inline and try to gather more info....
I've been with verizon for at least ten years and it has been 2 hour lease ever since. Then and now with 386 it has never a problem renewing the IP for me.
Have you tried calling verizon with the problem you're having? In the meantime try to use verizon's issued router and see if the problem persist. This is one way to know the root of your problem instead of concentrating with the 386 code.
 

drinkingbird

Regular Contributor
I've been with verizon for at least ten years and it has been 2 hour lease ever since. Then and now with 386 it has never a problem renewing the IP for me.
Have you tried calling verizon with the problem you're having? In the meantime try to use verizon's issued router and see if the problem persist. This is one way to know the root of your problem instead of concentrating with the 386 code.

Verizon won't provide support unless I'm using their router, so I'd have to swap that in just to call them. The issue started right after upgrading from 384.19 to 386.1_2 so the issue is pretty clear in my case. I guess there is some tiny chance they began experiencing DHCP issues right around the same time I upgraded my router but seems unlikely. There are many threads all over the net about this issue with Asus routers and short lease times on various ISPs, and for the most part people seem to be on 385 or 386 code.

It may vary with hardware platform, or maybe your area has more IPs allocated and they aren't given to someone else as quickly as where I am, who knows. I guess I'll know for certain when I revert back to 384 (after trying continuous mode DHCP).
 

bluepoint

Very Senior Member
Verizon won't provide support unless I'm using their router, so I'd have to swap that in just to call them. The issue started right after upgrading from 384.19 to 386.1_2 so the issue is pretty clear in my case. I guess there is some tiny chance they began experiencing DHCP issues right around the same time I upgraded my router but seems unlikely. There are many threads all over the net about this issue with Asus routers and short lease times on various ISPs, and for the most part people seem to be on 385 or 386 code.

It may vary with hardware platform, or maybe your area has more IPs allocated and they aren't given to someone else as quickly as where I am, who knows. I guess I'll know for certain when I revert back to 384 (after trying continuous mode DHCP).Ok, good luck.
Ok, looks like you don't want to try, good luck.
 
Last edited:

bilged

Occasional Visitor
Same problem for me. FIOS ONT > RT-AC68P directly, went from 384.19 to 386.1_2 and did not do a factory reset. WAN dropouts after varying times. To fix it temporarily, I just change DNS providers by toggling "Connect to DNS Server automatically" on/off where I normally have Cloudflare selected. I haven't looked at the logs but a DNS issue seems to be the cause.

Edit: eventually I got the same DHCP error as others requiring an ONT reboot. Switched to the latest Beta firmware as apparently the problem code has been rolled back? Anyway, so far so good.

Edit 2: It was still dropping WAN connections so I've rolled back to 384.19 now. No issues but required a full reset / restore from earlier backup.
 
Last edited:

Morris

Senior Member
Verizon only supports there own equipment and only there official configuration. Like Apple, this provides a much more reliable system and it's less expensive to maintain.
 

drinkingbird

Regular Contributor
Rolled back to 384.19 on Sunday and been stable ever since. Seems to be a WAN DHCP issue with 386 code base (even stock Asus). I suspect that it is not sending the DHCP ACK back to the DHCP server, which is what actually reserves your IP on the server. So the router gets the IP and starts using it but never informs the DHCP server as such. Just an educated guess, I didn't have a chance to put a sniffer on the WAN before reverting back.
 

Praveen Reddy

Occasional Visitor
My 2c...

I have an Asus RT-AC86u and was on 386.1 which was stable for me. Streaming was rock solid. Earlier last week, I upgraded to 386.1.2, where I suffered multiple disconnects. I then rolled back to 386.1 last night and looking at my system log, my last WAN disconnect was before I rolled back to 386.1 .

Knock on wood, it stays that way.
 

drinkingbird

Regular Contributor
I've been back on 384.19 for nearly 2 weeks and no issues. I even re-enabled traffic statistics and aiprotection and my speed is hitting what it was with 386.1.2 - so the speed increase (really reduced CPU usage) I had attributed to the 386 code base was actually probably just needing a good factory reset after several dirty upgrades within the 384 code line.

Looks like I'll be sticking with 384 until 386 is much more stable, barring any major security vulnerabilities or something.
 

panni

Occasional Visitor
Mar 8 01:50:56 lldpd[251]: removal request for address of x.x.x.x (my wan IP) %4, but no knowledge of it

I've had a similar issue with Unitymedia/Vodafone in Germany and a TC4400 cable modem. They send weird DHCP packets, renewal is every two hours.

Do you by any chance have Adaptive QoS enabled?

This fixed it for me: https://github.com/RMerl/asuswrt-me...S-Optimization#known-issues-with-adaptive-qos (I've recently updated the wiki page for newer models)

Edit: I'm using a slightly more general fix, without specifying the gateway, because it seems to change now and again:
Code:
if [ "$(nvram get qos_enable)" = "1" ] && [ "$(nvram get qos_type)" = "1" ]; then
    iptables -t mangle -I PREROUTING 1 -i eth4 -p udp -m udp --sport 67 --dport 68 -j ACCEPT
fi
 
Last edited:

drinkingbird

Regular Contributor
I've had a similar issue with Unitymedia/Vodafone in Germany and a TC4400 cable modem. They send weird DHCP packets, renewal is every two hours.

Do you by any chance have Adaptive QoS enabled?

This fixed it for me: https://github.com/RMerl/asuswrt-me...S-Optimization#known-issues-with-adaptive-qos (I've recently updated the wiki page for newer models)

Edit: I'm using a slightly more general fix, without specifying the gateway, because it seems to change now and again:
Code:
if [ "$(nvram get qos_enable)" = "1" ] && [ "$(nvram get qos_type)" = "1" ]; then
    iptables -t mangle -I PREROUTING 1 -i eth4 -p udp -m udp --sport 67 --dport 68 -j ACCEPT
fi

Nope, no QOS enabled at all.
 

deathbyburk

Occasional Visitor
I just got Fios yesterday and same issue. I thought it was my pi-hole but i guess it is something else. I do run a ddns and forward everything to my pi-hole, if this helps for troubleshooting
 

Morris

Senior Member
I just got Fios yesterday and same issue. I thought it was my pi-hole but i guess it is something else. I do run a ddns and forward everything to my pi-hole, if this helps for troubleshooting
Is you pi-hole between your Asus router and the FIOS ONT? If yes, get it out of there.
 

deathbyburk

Occasional Visitor
no it runs on docker on my nas. i have used this setup for years. it does appear to be something dns related but i can pull out fios and plugin my other provider and it goes away.
 

deathbyburk

Occasional Visitor
My normal setup. Any suggestions for fios?

1621218687443.png
 

ckennylin

Occasional Visitor
Go back to 384.19. If it is stable (and it should be), there's an undiagnosed problem with the 386.x codebase. Also try the most current stock firmware instead of Merlin - from experience, Merlin 384.19 and stock Asus are stable when directly connected to the Fios ONT. This has been an open issue for the last few months, and I'm not about to fix what's not broken.

Double-NATing Merlin 386.x to Verizon's router (nee Quantum Gateway) should also be stable.
 
Last edited:

deathbyburk

Occasional Visitor
same issue on clean 384.19.. have a spare asus i was running for 2 days with no issue. not sure of firmware but it was older and no problems.. gonna try stock next
 

deathbyburk

Occasional Visitor
Anywhere else I can get some good reading on this issue? I can't have this with my job situation constantly happening.
 

ckennylin

Occasional Visitor
Anywhere else I can get some good reading on this issue? I can't have this with my job situation constantly happening.
Actually this thread.

I have Fios at home with a Quantum Gateway. My AC68U hangs off it with Merlin 386.1.2 and all is well. I get about 100/100 which is expected.

I have 4 sites with the following, all directly connected to the on Fios ONT via Ethernet:
#1. AC68U on Stock Asus 386.x, getting about 200/200
#2. AX88U on Stock Asus 386.x, getting about 300/300 (supposedly provisioned at 200/200, but I'm not complaining)
#3. AC68U on Merlin 384.19, getting about 200/200
#4. AC68U on Merlin 384.19, getting about 200/200

Sites #3 and #4 were the ones I encountered the constant dropout when upgraded to Merlin 386.x and they have been stable with 384.19.

On Site #4, I tried a double-NAT with an old Actiontec (Fios) Gateway using the ethernet WAN port to the ONT and hung the AC68U's WAN to the Actiontec's LAN ports. The AC68U was running Merlin 386.x and it was stable. Once I took away the Actiontec and move the AC68U's WAN directly to the ONT, the dropouts came back. When I downgraded to Merlin 384.19, it was stable, so I'm leaving this alone for now.

Your experience may vary of course, once the posters on this thread went back to Merlin 384.19, the thread has been quiet.

Hope this helps!
 

deathbyburk

Occasional Visitor
Guess ill probably pick up a router from them "free anyway" after clean 384.19 it still was not stable. swapped back around midnight to old provider and no issues since
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top