Have FIOS WAN DHCP issues been resolved in 386.4?

[drinkingbird]

When I tried 386.2 my FIOS would lose its WAN IP frequently with the log "your ISPs DHCP does not function properly". I tried all the workarounds like aggressive mode etc but could not get it to resolve. So I've been on 384.19 ever since. It works great but I do have the occasional GUI lockup or 100% CPU, plus would like some of the improved features in the new code base.

I have an RT-AC1900 (same as RT-AC68U). Wondering if anyone else with Verizon FIOS (or another provider with very short lease times) that had the issue before is running ok on the newest version? Don't want to go through a hard reset and reconfigure if it isn't resolved.

Thanks

***EDIT - THERE IS A WORKAROUND - SEE MY POSTS LATER IN THIS THREAD (and kudos to @CoyoteDen for finding the problem). Long story short, if you are using FIOS (Verizon at least, possibly Frontier, ATT, others) and using Guest Network 1, disable GN1, reboot, and configure your GN on Guest Network 2 or 3 instead. GN1 has a bug where it is sending LAN DHCP queries to the WAN causing conflict and your WAN IP to get blocked.

Note if you haven't already, you should upgrade to 386.5 and then do a factory reset with "initialize" checked off (take screen shots or copy/paste any settings or scripts you need to keep). After that is done, configure just enough to get into the router, then select "format jffs", click apply, reboot, wait 5 mins, and reboot again. Then manually re-enter all your configs, do not restore a backup. This is to ensure you have a fully clean install with no gremlins left over from earlier versions. Even earlier versions of 386 had issues with Guest Network 2 and 3 NOT being isolated from the main network, so you want to make sure you're on the latest version with clean configs. There is a more involved "nuclear reset" procedure but I think the above is sufficient to get you all cleaned up.

Once done, test your guest network to ensure it is isolated from the LAN. On my RT-AC1900 (same as 68U) it is fine using the above procedure, but every router/firmware treats things a bit differently.

Note if you are using AIMESH and extending your guest network to other nodes, then the solution is a bit more complex. You need to stay on GN1 but set up a script to remove the WAN port from the special AIMESH VLANs. I've linked a post later in this thread with details on that.

 

[bbunge]

You should be OK with an upgrade. But I would go to the 386.5 alpha 1 for the AC68U as it has some fixes that were problems in 386.4.

 

[Huib]

Have been on FiOS for quite a number of years and all of them with Merlin. Never had any issues with these settings:

But not every market is the same, and don't know if that also means different hardware on their side.

 

[L&LD]

Of course, you'll need to do a full reset to factory defaults (and NOT use a saved backup file afterward to secure and configure the router) when going from 384.19 to any version of 386.xx.

Some may have simpler setups where moving to such a large upgrade doesn't cause issues. Yours obviously does.

Nobody 'wants to' do the proper clean install. But sometimes, it's just obvious that is what is needed if you want to run current firmware on your router.

What most people don't understand about a full reset is that from the time you take your network down, to the time you have done a clean install/reset with the recommended defaults, is only 10 to 20 minutes away. This is not a hardship for the expected benefits.

 

[drinkingbird]

Of course, you'll need to do a full reset to factory defaults (and NOT use a saved backup file afterward to secure and configure the router) when going from 384.19 to any version of 386.xx.

Some may have simpler setups where moving to such a large upgrade doesn't cause issues. Yours obviously does.

Nobody 'wants to' do the proper clean install. But sometimes, it's just obvious that is what is needed if you want to run current firmware on your router.

What most people don't understand about a full reset is that from the time you take your network down, to the time you have done a clean install/reset with the recommended defaults, is only 10 to 20 minutes away. This is not a hardship for the expected benefits.

I did a full nuclear reset when going to 386.2 and manually re-entered everything, no config backup. Did the same when reverting back to 384.19. Fios DHCP lease time in my area is 2 hours and that seemed to be what was causing problems with the 386 versions. I guess I'll just have to try it and see now that 386.5 is out. My setup isn't complex, it seemed that the Asus DHCP was not "ACK' ing the DHCP lease so after a while the IP was given to someone else and I lost internet and would have to reboot every hour or two to get a new IP.

 

[drinkingbird]

Have been on FiOS for quite a number of years and all of them with Merlin. Never had any issues with these settings:
View attachment 39572
But not every market is the same, and don't know if that also means different hardware on their side.

Yeah those settings have worked for me for years too but when going to 386 I was having WAN DHCP issues.

 

[bluepoint]

My setup isn't complex, it seemed that the Asus DHCP was not "ACK' ing the DHCP lease so after a while the IP was given to someone else and I lost internet and would have to reboot every hour or two to get a new IP.

Seems like you are expecting a static IP. FIOS residential service is dynamic DHCP meaning your IP can change anytime. Are you forcing to use a certain IP? If not, it will renew or re-acquire a new IP.

 

[TIm Fitz]

I have had nothing but problems with WAN disconnects on any 386 version. Spent hours on it and could not resolve it even with 386.5 on my AC68U. Went back to 384.19 and have not had an issue. Been about 2 weeks without a blip. Somethings up with these new versions with regards to the WAN ports.

 

[Morris]

Stable on FIOS with DHCP query frequency set to Continuous

Morris

 

[drinkingbird]

Seems like you are expecting a static IP. FIOS residential service is dynamic DHCP meaning your IP can change anytime. Are you forcing to use a certain IP? If not, it will renew or re-acquire a new IP.

Definitely not expecting a static IP. If you attempt to set a static with any ISP it won't work at all, they've had measures in place for that for many years. I'm very familiar with what DHCP is and how it works.

The issue is not that the IP is changing, it is that internet is totally blocked about once per day with all the 386 versions. I still have an IP, the router is counting down the lease time, but cannot even ping the next hop from the router. My best guess without doing a lot of sniffer work and trial and error is that the router is not properly acknowledging the new IP or is missing some part of the renewal process, and after a day FIOS determines that you are no longer using the IP (or thinks you are trying to use a static) and blocks it.

 

[drinkingbird]

Stable on FIOS with DHCP query frequency set to Continuous

Morris

Have tried all 3 settings, unfortunately they all behave about the same. Every 1 day or so internet is totally blocked, have to disable and re-enable WAN to restore (at which point I get a new IP).

Went back to 384.19 again and back to being stable for several days. Apparently this is going to be the final firmware version for my setup.

 

[drinkingbird]

I have had nothing but problems with WAN disconnects on any 386 version. Spent hours on it and could not resolve it even with 386.5 on my AC68U. Went back to 384.19 and have not had an issue. Been about 2 weeks without a blip. Somethings up with these new versions with regards to the WAN ports.

Yup same experience here. I gave 386.5 a chance (and 386.2 previously with same results) - did a full nuclear reset and manually re-entered configs, even left my router and ONT completely disconnected overnight and started fresh in the morning, in case there were somehow old DHCP leases associated with my router or something. But same thing. About once per day the internet gets blocked. Router thinks it has an IP and is counting down the lease, but can't ping FIOS gateway or get to anything.

I did notice that if you wait a couple hours, the router renews the lease, gets a new IP, and everything starts working again. So maybe it is not "accepting" when FIOS gives out a new IP, or maybe it is just not renewing correctly and eventually FIOS blocks it.

With 384.19 my IP does not change daily (can keep it for weeks) so definitely something to do with DHCP on the 386 versions is making FIOS think that it has to try and force a new IP. At which point the router reports "removal request for x.x.x.x but no knowledge of it". That seems to be when the issue happens.

I'm sure with lots of trial and error and/or hooking a sniffer up to the WAN port I could narrow it down but not that motivated to keep messing with it.

Regardless, I've settled on the fact that 384.19 is the final firmware for me. Didn't see anything in 386.5 that was of much use. The only things 384.19 has issues with is occasionally you can't access the GUI without rebooting it, and/or one CPU will go to 100% and get stuck there. Doesn't happen that often, and I guess I can schedule a reboot for every morning or something. Client list is a bit flaky too.

 

[L&LD]

I would think that security is the reason you upgrade from ancient firmware from?

News - Trend Micro: Cyclops Blink Sets Sights on Asus Routers | SmallNetBuilder Forums (snbforums.com)

 

[TIm Fitz]

I also have an AC68U that started having WAN issues after upgrading to any 386 version. I went back to 384 and everything was fine. I have Optimum for the ISP.

What I did was change the cable modem, the cable between the router and modem and disconnected the router from everything before doing a hard reset from the admin tab. I plugged my laptop in so it was the only device connected while doing the reset. I am now at 386.5 and have not had that problem in about 2 weeks (fingers crossed).

I did still have problems with guest networking where any of the 3 guest networks would always be in the main subnet regardless of the access Intranet Setting. Nothing I did would block guests from seeing the main network which I just cannot have. Installed YazFi and now they work properly.

 

[drinkingbird]

I also have an AC68U that started having WAN issues after upgrading to any 386 version. I went back to 384 and everything was fine. I have Optimum for the ISP.

What I did was change the cable modem, the cable between the router and modem and disconnected the router from everything before doing a hard reset from the admin tab. I plugged my laptop in so it was the only device connected while doing the reset. I am now at 386.5 and have not had that problem in about 2 weeks (fingers crossed).

I did still have problems with guest networking where any of the 3 guest networks would always be in the main subnet regardless of the access Intranet Setting. Nothing I did would block guests from seeing the main network which I just cannot have. Installed YazFi and now they work properly.

Yeah my cable is a short run of cat 6 and I have no modem, and given that it works fine on the older version it seems unlikely to be anything other than the router/firmware. I also unplugged everything except one wired PC during the full reset process.

Oddly I noticed that the guest networks on 386 get their own 192.168 subnets with 1 day lease time and you can't modify any of that. I only have one guest network but strange that yours behaves differently. Mine is an AC1900 but it's basically the same thing as the 68U.

 

[drinkingbird]

I would think that security is the reason you upgrade from ancient firmware from?

News - Trend Micro: Cyclops Blink Sets Sights on Asus Routers | SmallNetBuilder Forums (snbforums.com)

384 isn't exactly ancient. But regardless, I can't have my internet dropping randomly once a day (or more), I work from home. So I don't have a choice unless I want to buy a new router. I have WAN admin disabled, strong password, and just recently defaulted all the settings as part of all this, so according to that advisory, should be good.

 

[L&LD]

Affected products

RT-AC1900P, RT-AC1900P firmware under 3.0.0.4.386.xxxx

Firmware 384.19_0 is from August of 2020, so yes, it is ancient. And more importantly, insecure.

You may have followed the suggestions (you saw the trees), but you missed the forest: you need to be on 386.xxxx with those suggestions to be 'safer'.

The most secure course of action, when you have the free time, is to upgrade to the 386.5.1 firmware as above and perform a full reset to factory defaults afterward. Do not use a saved backup config file to secure the router and connect to your ISP. Do not 'blindly' put in settings that worked on that old firmware 'once upon a time'. Do not insert (or leave inserted) a USB that you've used for amtm (or other) scripts (at least while you're testing the new firmware on your router/network). Do a proper clean install and that will almost 100% guarantee you a stable network. After all, not too many others have reported having issues if they followed the suggestions above.

 

[drinkingbird]

Firmware 384.19_0 is from August of 2020, so yes, it is ancient. And more importantly, insecure.

You may have followed the suggestions (you saw the trees), but you missed the forest: you need to be on 386.xxxx with those suggestions to be 'safer'.

The most secure course of action, when you have the free time, is to upgrade to the 386.5.1 firmware as above and perform a full reset to factory defaults afterward. Do not use a saved backup config file to secure the router and connect to your ISP. Do not 'blindly' put in settings that worked on that old firmware 'once upon a time'. Do not insert (or leave inserted) a USB that you've used for amtm (or other) scripts (at least while you're testing the new firmware on your router/network). Do a proper clean install and that will almost 100% guarantee you a stable network. After all, not too many others have reported having issues if they followed the suggestions above.

I didn't miss the forest. As I said, it simply is not an option for me.

As already mentioned numerous times in the thread and in replying to your posts (before implying I'm an idiot, read the thread), I've done all that you mention, with both 386.2 a while back and 386.5 this past week. It is nowhere near 100% guarantee of a stable network. I've been a network engineer for over 20 years, I know when something is wrong, this isn't user error.

Factory reset using WPS button
Configure just enough to get in, factory reset from GUI with "Initialize Settings"
Configure just enough to get in, Upgrade firmware
Configure just enough to get in, factory reset with "Initialize Settings"
Apply basic config, enough to get in, check "format jffs", hit apply, and reboot 3 times, 5 minutes apart.
Re-configure all other settings manually (my configuration is very basic, some static LAN DHCP assignments and I use a different subnet than default, plus one guest network).
I have no USB, no amtm, no scripts, no VPN, no AIMESH, no IPV6, no custom firewall, etc.

Many others have reported the issue over the past year or so (ever since 386 came out), it only seems to impact those with very short WAN lease times i.e. 2 hours or less, especially those on FIOS/Frontier. Search here and other forums for "Your ISP DNS does not function properly" as that is the error that is often shown when internet is lost. A log entry stating "request to remove x.x.x.x (WAN ip) but no knowledge of it" is logged when the problem occurs as well. Others within this thread are reporting the same issue as well.

So yes, I'd love to be on the new version with better security and new code base, it simply isn't an option for me until they realize there is a problem and find/fix it. It is an issue in the Asus codebase as it does it with the stock firmware also (at least it did on 386.2).

 

[drinkingbird]

Firmware 384.19_0 is from August of 2020, so yes, it is ancient. And more importantly, insecure.

You may have followed the suggestions (you saw the trees), but you missed the forest: you need to be on 386.xxxx with those suggestions to be 'safer'.

The most secure course of action, when you have the free time, is to upgrade to the 386.5.1 firmware as above and perform a full reset to factory defaults afterward. Do not use a saved backup config file to secure the router and connect to your ISP. Do not 'blindly' put in settings that worked on that old firmware 'once upon a time'. Do not insert (or leave inserted) a USB that you've used for amtm (or other) scripts (at least while you're testing the new firmware on your router/network). Do a proper clean install and that will almost 100% guarantee you a stable network. After all, not too many others have reported having issues if they followed the suggestions above.

OK it looks like someone else already figured out the issue quite a while ago and it still hasn't been fixed. This thread didn't come up on my latest searches but was in the "similar threads" below, go figure.

Apparently if I want to be on the new codebase I'll need to disable guest networks or apply the custom config script.

Release - Asuswrt-Merlin 386.2_6 is now available

Had to downgrade. Clean install and did 2 full resets and clean setups, but something is wrong with DHCP and manual IP’s being assigned incorrectly.

www.snbforums.com

Clearly DHCP should not be leaking between LAN/Guest/WAN. Makes perfect sense that if FIOS is seeing you try to grab more than 1 public IP, or sending renewal requests for private IPs, they would block you. I guess those with longer lease times simply aren't doing it enough for their ISP to block them, or their ISP just ignores these requests, who knows.

 

[drinkingbird]

When I have time I'm going to give 386 another shot. Will try Guest Network 2 first, see if the bugs have been fixed to make that really not able to see the LAN. If not will try removing the WAN port from the special VLANs that it creates for AIMESH on Guest Network 1. Will report back results.

My guess is that cable modems (pseudo L3 devices) are probably ignoring the packets tagged with these special VLANs, thus not an issue there. FIOS ONT must be stripping off the VLAN tags and forwarding the DHCP requests along untagged. So either the guest is getting a public IP which is confusing the router (two entries in the ARP table for the same IP, the most recent entry takes priority) and thus traffic is blackholing, or FIOS is seeing two IPs or two MACs associated to the ONT and blocking all traffic.

My guess is that the guest is getting a public IP, that's why the WAN IP changes every time this issue happens (when usually it is somewhat "sticky").

Oddly in the past FIOS was very strict, it would not give you an IP if your MAC had changed unless you either released the old lease manually or waited 2+ hours. In this case it appears to be responding even though a lease already exists for a different MAC off the ONT. Maybe they've redesigned things due to all the people calling in when they got a new router and couldn't get online.