What's new

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

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

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.
 
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).
 
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:
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:
No dice with continuous mode DHCP. Going to have to go back to 384 tonight.
 
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.
 
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.
 
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.
 
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:
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.
 
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
 
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.
 
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.
 
My normal setup. Any suggestions for fios?

1621218687443.png
 
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:
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
 
Anywhere else I can get some good reading on this issue? I can't have this with my job situation constantly happening.
 
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!
 
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
 
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
I'm also running double NAT through an old Verizon router and have no issue. I've used it as a bridge to media convert and that also worked so I suspect your issue is something else though this may be a viable workaround.

Good luck,

Morris
 

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