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

[ckennylin]

If @drinkingbird doesn't mind being a pioneer, can you try reflashing to Asus stock without resetting and see if it is stable? If not, try nuking the reflashed Stock Asus firmware and reconfigure by hand and see if it is stable?

I have a data point of 1 for the first part, reflashing 386.1_2 to Asus Stock without resetting seem more stable with fewer drops.

I did not try the second part since my priority was to get the site up, so I downgraded back to 384.

We need a sanity check - flashing to Asus Stock should have fixed the problem, as my site #1 in prior post was all Asus to the most current firmware and had no problems. Site #2 and experimenting with Site #3 got me in hot water.

 

[drinkingbird]

FIOS WAN IP renewal is not a problem here, it stays with the same IP forever provided you don't reboot twice. If ever you assign the IP statically it will cause trouble cause if your router goes down for even a very short time, someone will grab that IP as it belongs to a dynamic pool.

My FIOS WAN IP changes very frequently even if my router stays up for months. Comcast and others let you keep the same ones for months but Verizon changes it a lot. Its annoying as it causes my VPN to disconnect when it changes (usually late at night though luckily - they probably do this intentionally for that reason).

 

[drinkingbird]

If @drinkingbird doesn't mind being a pioneer, can you try reflashing to Asus stock without resetting and see if it is stable? If not, try nuking the reflashed Stock Asus firmware and reconfigure by hand and see if it is stable?

I have a data point of 1 for the first part, reflashing 386.1_2 to Asus Stock without resetting seem more stable with fewer drops.

I did not try the second part since my priority was to get the site up, so I downgraded back to 384.

We need a sanity check - flashing to Asus Stock should have fixed the problem, as my site #1 in prior post was all Asus to the most current firmware and had no problems. Site #2 and experimenting with Site #3 got me in hot water.

Unfortunately I can't be down that long, but if the issue is with the code base, then flashing to Asus stock would not fix it. I suspect this is probably not a merlin issue, I think it was introduced in the asus 386 code, but obviously can't be sure without nuking, flashing stock, and waiting a couple days.

 

[alex1236hk]

Try flashing back to 384.19 and do a hard reset and re-enter settings by hand. I encountered a similar problem with an AC86U last week and it was resolved by doing this.

You can also solve this by double-NATing to your ONT. There is something with 386.1_x and the WAN port's interaction with the ONT. I had responded to a similar post last week.

I have 3 sites all with Fios and all with AC68U routers connected directly to ONTs. This is what I observed:

Site 1: ASUS Firmware 384 to current 386 updates, no problem.

Site 2: Merlin 384.19 upgraded to 386.1_2, experience WAN dropouts.
Inserted old Actiontec Fios Router in between and double-NAT: no problem
Removed Actiontec router, reflashed to current Stock Asus 386: fewer WAN dropouts
Reflashed to 384.19, hard reset, hand-reconfigured, no problem.

Site 3: Merlin 384.19, no problem.
Flashed to 386.1_2: WAN dropouts.
Flashed to current Asus 386: fewer WAN droupouts
Reflashed to 384.19, hard reset, hand-reconfigured, no problem.

The other poster resolved by inserting a switch in between the router and the ONT. When I tried the same, I got fewer dropouts, but dropouts nevertheless.

Flashing from 386.1_2 back to 384.19 will bork your authentication so you'd need to hard reset anyway.

Left to Try: Flashing from 386.1_2 to Stock Asus 386 and hard-reset / hand-config, but I don't want to touch a live site when it's stable again.

Also not touching Site 1.

Hope this helps and point to a real solution!

I've had WAN dropout issue since 386, I am with AC86U also.
When the internet drops out, the WAN DHCP lease status simply shows "Expired".
Flashing to 41994 does not solve the issue entirely but fewer dropouts.
Router log doesn't show anything.
I was suspecting the issue was related to my ISP, therefore I call them to remotely reset my ONT and everything on their side.
Replacing a new 3M CAT6 patch cord to my ONT. And then I flashed back to 386.1_2 to test out things.
Had been solid since then. Finger cross.
Still no idea if it is ASUS 386 code issue or ISP issue.....

 

[drinkingbird]

I've had WAN dropout issue since 386, I am with AC86U also.
When the internet drops out, the WAN DHCP lease status simply shows "Expired".
Flashing to 41994 does not solve the issue entirely but fewer dropouts.
Router log doesn't show anything.
I was suspecting the issue was related to my ISP, therefore I call them to remotely reset my ONT and everything on their side.
Replacing a new 3M CAT6 patch cord to my ONT. And then I flashed back to 386.1_2 to test out things.
Had been solid since then. Finger cross.
Still no idea if it is ASUS 386 code issue or ISP issue.....

All evidence points to this being a code/router issue not related to ISP. By resetting your ONT you bought yourself a day or two and it will probably drop out again.

 

[alex1236hk]

All evidence points to this being a code/router issue not related to ISP. By resetting your ONT you bought yourself a day or two and it will probably drop out again.

I am running on a 2020 manufactured new AC86U. Should be the code problem?
Resetting ONT is pretty handy for me here, I just call my ISP and they will perform the remote reset instantly and ready to go in 5 mins.
All I have to do is sit there and see the lights on the ONT goes dark and went on again after they rebuild my account profile on their end.
It has been two days now and the connection are solid. Have you tried 386.2 yet?
Any improvement?

 

[drinkingbird]

I am running on a 2020 manufactured new AC86U. Should be the code problem?
Resetting ONT is pretty handy for me here, I just call my ISP and they will perform the remote reset instantly and ready to go in 5 mins.
All I have to do is sit there and see the lights on the ONT goes dark and went on again after they rebuild my account profile on their end.
It has been two days now and the connection are solid. Have you tried 386.2 yet?
Any improvement?

386.1_2 is all I've tried, have not tried the .2 beta yet. I reset my ONT by unplugging the power, that bought me a day. Today I manually released/renewed my WAN IP and so far it is good, but will likely go out tomorrow or maybe the next day. The WAN DHCP is not renewing as it should be with this code. This will become a problem for other users, it's just that FIOS has a 2 hour lease (where many ISPs have 24 hour or even more) so those people may not be noticing it yet, dunno.

 

[alex1236hk]

386.1_2 is all I've tried, have not tried the .2 beta yet. I reset my ONT by unplugging the power, that bought me a day. Today I manually released/renewed my WAN IP and so far it is good, but will likely go out tomorrow or maybe the next day. The WAN DHCP is not renewing as it should be with this code. This will become a problem for other users, it's just that FIOS has a 2 hour lease (where many ISPs have 24 hour or even more) so those people may not be noticing it yet, dunno.

My ISP has 30mins lease time only. Thats why it’s so noticeable for me. Probably should go back to 384.19 if that shirt happens again. WAN DHCP suppose should be a straightforward basic function for a router, no one will expect it will be buggy on 386.

 

[ckennylin]

Unfortunately I can't be down that long, but if the issue is with the code base, then flashing to Asus stock would not fix it. I suspect this is probably not a merlin issue, I think it was introduced in the asus 386 code, but obviously can't be sure without nuking, flashing stock, and waiting a couple days.

My Site #1 has stock Asus firmware from 384 to current 386 with no problems so I am leaning towards the Merlin 386 code base as the root cause.

My reflash from Merlin 386.1_2 back to stock Asus 386 was not scientific as I was in a rush to bring the site back up, so I did not do a hard reset / hand reconfig. It did improve the stability, but still dropped WAN albeit less frequently. I gave up and went back to Merlin 384.19, and found out afterwards on the forum that my experience with 386.1_2 and Fios was not unique.

Fios is apparently aggressive with reallocating IPs - my sites are set to reboot the router around the same time and I notice the new IP addresses at renewal are adjacent or close to being adjacent.

In the WAN DHCP Settings, there are choices for Aggressive (Default), Normal, and Continuous, and I seem to recall that in an older post years ago, "Aggressive" in Merlin is set to be the same as "Normal" because there was not significant difference back then. Maybe we'll see a difference in 386.1_2 if it is set to "Continuous"?

 

[bbunge]

Try a new Ethernet cable between the ONT and router WAN port. I did that last week and it made a world of difference. And I just used CAT5 UTP as that is all I had in bulk.

 

[drinkingbird]

Try a new Ethernet cable between the ONT and router WAN port. I did that last week and it made a world of difference. And I just used CAT5 UTP as that is all I had in bulk.

Probably coincidence, I have a perfectly good cat 6 cable and it is only about 20 feet long and all inside. No issues with that cable for a long time, issue only started a day after the upgrade.

 

[drinkingbird]

My Site #1 has stock Asus firmware from 384 to current 386 with no problems so I am leaning towards the Merlin 386 code base as the root cause.

My reflash from Merlin 386.1_2 back to stock Asus 386 was not scientific as I was in a rush to bring the site back up, so I did not do a hard reset / hand reconfig. It did improve the stability, but still dropped WAN albeit less frequently. I gave up and went back to Merlin 384.19, and found out afterwards on the forum that my experience with 386.1_2 and Fios was not unique.

Fios is apparently aggressive with reallocating IPs - my sites are set to reboot the router around the same time and I notice the new IP addresses at renewal are adjacent or close to being adjacent.

In the WAN DHCP Settings, there are choices for Aggressive (Default), Normal, and Continuous, and I seem to recall that in an older post years ago, "Aggressive" in Merlin is set to be the same as "Normal" because there was not significant difference back then. Maybe we'll see a difference in 386.1_2 if it is set to "Continuous"?

Interesting, my IPs are all over the place, usually from totally different /8 networks. Probably depends on region.

The one strange thing I noticed was rebooting the router did not get a new IP and the problem came back like 5 mins later. But rebooting ONT or turning WAN off and On (which does a release/renew) gets a new IP and it works fine for a couple days.

 

[sbsnb]

My FIOS WAN IP changes very frequently even if my router stays up for months. Comcast and others let you keep the same ones for months but Verizon changes it a lot. Its annoying as it causes my VPN to disconnect when it changes (usually late at night though luckily - they probably do this intentionally for that reason).

Weird. I've had my current IP address since September 15, 2020. The address I had prior ran from June 9, 2019 to September 15, 2020.

 

[drinkingbird]

Dropped out on me in the middle of work today, less than 12 hours after I had done a manual release/renew on the WAN. Guess I have to either go back to 384 or try stock firmware.

 

[alex1236hk]

Try a new Ethernet cable between the ONT and router WAN port. I did that last week and it made a world of difference. And I just used CAT5 UTP as that is all I had in bulk.

huh, that seems works for me, no drop off since replaced my WAN cable then.

 

[ckennylin]

Dropped out on me in the middle of work today, less than 12 hours after I had done a manual release/renew on the WAN. Guess I have to either go back to 384 or try stock firmware.

Just go with 384 and revisit around the Fall.

If you go with stock, do a full reset and hand-reconfigure. I'm sure that will be stable as well. For me, going back to stock saves on the reconfiguration, but it ended up not being stable.

 

[drinkingbird]

Just go with 384 and revisit around the Fall.

If you go with stock, do a full reset and hand-reconfigure. I'm sure that will be stable as well. For me, going back to stock saves on the reconfiguration, but it ended up not being stable.

Well I couldn't deal with the daily internet loss and didn't want to give up the additional throughput that the 386 code base gave (better use of both CPUs). So I took the plunge.

Here is what I did
Hard reset using WPS button
Put into recovery mode and used asus utility to upload latest stock firmware. It is actually a beta version which addresses a couple DNSMasq vulnerabilities and apparently resolves high CPU temp issue also. Version is 9.0.0.4.386_41994
Did a factory reset through the UI including "initialize" which apparently formats JFFS and NVRAM etc
Let it sit for 15 mins after reboot
Rebooted again, and reconfigured everything manually, not from backups.

Maybe overkill but wanted to make sure I was totally back to stock.

We'll see how it goes over the next couple days.

Happy to report I am still getting the improved throughput from the 386 code base. My RT-AC1900 used to max out at around 260 megs with traffic monitor and AIProtection enabled, CPU1 would be at 100%. Now I hit my full 350M speed and CPU1 is at 60% and CPU2 is at 40%.

 

[jackc88]

I experienced similar symptoms with a different ISP, Xfinity. It has been almost a decade that I enjoyed being in FiOS.
Have a look at a recent post to see if is the same problem. The workaround for me was to try running udhcpc w/o the -s switch. That reduced the constant restarts every few hours. I switched over the dhclient and now it has been up for almost five days. I think I have posted enough info to determine if my issue is relevant to yours. Good luck and let me know if I can be of further help.

ISP's DHCP did not function properly - Xfinity | SmallNetBuilder Forums (snbforums.com)

 

[drinkingbird]

Well already disconnected once today after less than 12 hours on stock firmware. Looks to be Asus problem with 386.

 

[drinkingbird]

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