Yet another "Your ISP's DHCP does not function correctly" thread

[sfatula]

Oh, I agree there is some specific oddity somewhere. I don't know if ANY other brand has the issue, I do know one doesn't as I borrowed an unused neighbor router (different brand)for a while and never had the issue. But that's one router, one month. Happens at least once a month so, somewhat "proof". But of course, unless one knows the exact cause, they can never say for sure.

I have used two different ASUS models though and both had the issue. I gave up after enormous amount of time spent and really, my solution works fine and it doesn't bother me much any more.

About to get a different ISP though so who knows what that will bring!

 

[shaun3000]

Do you have Guest Network 1 configured? If so, it is a bug. My guess is you are losing internet when a guest connects to the guest network, or something on the guest network renews its lease (which it will do every 24 hours or so)? GN1 is forwarding LAN DHCP queries to the WAN causing a conflict and blocking the router WAN IP from being able to reach the internet. This seems to only affect ONT customers as the ONTs apparently strip off the VLAN tag from the rogue DHCP packets (otherwise they would not get through and would not be a problem).

If not using guest, your router may simply have died. If your ISP router works, your ONT isn't banned or anything. However with all the troubleshooting you've done, you may just be running into the fact that they limit you to 1 IP lease and it isn't expiring with all the testing you're doing. If your ISP router is the last one that worked, plug that in, make sure it gets an IP, then find the place in their GUI where you can release the WAN lease. Do that, wait a couple seconds til it says it is gone, then unplug the power cord. You now have freed up your lease.

Then before plugging the WAN to the Asus, go into the GUI, do the factory reset with initialize settings checked off. Then put in just a basic config to get into the router, check off "format JFFS", hit apply, then reboot twice, waiting 5 minutes between reboot 1 and 2. You now have a clean factory fresh config.

If your ISP does not require you to use their MAC address, then you should be ok leaving that part off. But if they do, configure that before plugging in the WAN also, and make sure you're using the right format that the Asus wants. Plug in the WAN, and make sure you get a WAN IP now. If not, then there is definitely something wrong.

You mention something about a password, does your ISP use PPPoE? If so make sure that is configured on your Asus. It is possible they have it built into their router but you need to manually put it in yours. Maybe a new requirement? From what I recall, with PPPoE you need to have the settings right before you'll get a WAN IP.

Anyway, if you do get to the point where your Asus WAN gets an IP, you can now re-enter all your configs (manually, not from backup) but use Guest Network 2 or 3, NOT 1. The problem should be resolved for good.

There is always the possibility that your ISP has implemented some new thing to only allow their own hardware to connect (using authentication etc). If none of the above works, you may need to do some research and see if that ISP has instituted any new measures. Unfortunately if nothing here works, I'd say your Asus may be hosed. But you can test by plugging it into the ISP's router (ASUS WAN to ISP LAN) and see if you get a WAN IP (it will be private one like 192.168.x.x). If you do and none of the stuff above works, then well I'm at a loss as to what it is.

Registered to say disabling Guest 1 seems to have resolved this issue for me. I’m on Frontier Fios with a Fox 222 ONT.

 

[Sebastienbo]

Registered to say disabling Guest 1 seems to have resolved this issue for me. I’m on Frontier Fios with a Fox 222 ONT.

I'm from Belgium I experience the same problem no dhcp ip adress from my ISP router called Telenet (coax cable modem).
I noticed that it DOES get an ip adress if I just remove and re-enter the rj45 cable from the modem, that must trigger something that make it work again.

I have the problem since firmware 386 and now I tried upgrading to 388.1 stock firmware, but here again the same problem occurs.

I'm gonna try the guest network trick and give feedback (but that will create another problem, because only "guest wifi 1" allows the guest network to be propagated to the mesh systems

 

[drinkingbird]

I'm from Belgium I experience the same problem no dhcp ip adress from my ISP router called Telenet (coax cable modem).
I noticed that it DOES get an ip adress if I just remove and re-enter the rj45 cable from the modem, that must trigger something that make it work again.

I have the problem since firmware 386 and now I tried upgrading to 388.1 stock firmware, but here again the same problem occurs.

I'm gonna try the guest network trick and give feedback (but that will create another problem, because only "guest wifi 1" allows the guest network to be propagated to the mesh systems

The bug of the guest vlans being sent out the wan seems to have been corrected in one of the 386 releases, at least on my router. Worth a shot though. Did you do a factory reset and reconfigure after upgrading?

 

[abc5]

I'm suffering the same problem as well suddenly when I got home last evening. Asus ax86u with merlin 388.

About summer of 2022 it happened suddenly to my prior, Asus router, an AC class, which... without a fix, I thought it was a router and paid good money for this Asus ax86U, so this is rather annoying to say the least.


My broadband is a local cable provider, and their cable modem has a LAN jack.

if I connect a PC via lan cable to this lan jack on the cable modem, I get internet just fine.

 

[abc5]

what I did today is leave broadband modem powered off for about 20min, then powered it back up . The message from the asus went away and i was able to use the asus. i was then tweaking some things on the asus which lead to a reboot... the message came back after and i was dead in the water again... This leads me to think it's soemthing the boardband provider is did as of friday during the day.

I shut down their modem again and tried in 10min.. too soon. shut their box down again but left for for about 20min... powered it back up, and my asus is back up again... for the past 4hrs... I fear rebooting my asus.

 

[abc5]

Also I use a router based VPN on the asus.. that has stopped being able to authenticate 'suddenly'... feel like my broadband provider made some 'changes'.

not sure if it is related

 

[drinkingbird]

Also I use a router based VPN on the asus.. that has stopped being able to authenticate 'suddenly'... feel like my broadband provider made some 'changes'.

not sure if it is related

The "ISP DHCP" error is a very generic one - simply means they aren't responding to your request or are responding with something other than "here's your IP".

 

[abc5]

The "ISP DHCP" error is a very generic one - simply means they aren't responding to your request or are responding with something other than "here's your IP".

Greetings.. I see.. so it's the limitation of the Asus router's built in messaging alerts phrases.

 

[drinkingbird]

Greetings.. I see.. so it's the limitation of the Asus router's built in messaging alerts phrases.

Yeah, I'm sure you can turn on some debugging, not sure if simply setting the highest log level will do it or if you'd have to SSH in and do some command line stuff. Of course a sniffer on the WAN would be best but that is pretty involved if you're not accustomed to doing it and don't have a switch with mirroring or an old hub laying around.

 

[ceglia]

@drinkingbird i have two Asus GT-AX11000 routers (a main router and one in AP mode connected via ethernet). my internet service is AT&T fiber that comes with a gateway (modem/router). i've been having all of the issues described in this thread: internet connection dropping inexplicably every 18hrs or so. the AT&T gateway is set to passthrough (per AT&T's recommendations) and remains connected to the internet, but the primary Asus GT-AX11000 periodically loses it's connection, and when it does, all devices on my network are without internet until i reboot the two Asus routers.

i've come up with all sorts of ridiculous automated workarounds, which more or less work, but should not be necessary. i don't use scripts. i rely on nightly reboots using the reboot scheduler and a fake dual WAN "Fail Over" setup that keeps me online until the automated reboot.

i do have two guest network 1's set up: one on the 2.4Ghz band and one on the 5Ghz band. i moved them both over to the guest network 2 slot. i'm really hoping this works because this issue has been driving me crazy for months. i'll post back with results in a few days.

 

[drinkingbird]

@drinkingbird i have two Asus GT-AX11000 routers (a main router and one in AP mode connected via ethernet). my internet service is AT&T fiber that comes with a gateway (modem/router). i've been having all of the issues described in this thread: internet connection dropping inexplicably every 18hrs or so. the AT&T gateway is set to passthrough (per AT&T's recommendations) and remains connected to the internet, but the primary Asus GT-AX11000 periodically loses it's connection, and when it does, all devices on my network are without internet until i reboot the two Asus routers.

i've come up with all sorts of ridiculous automated workarounds, which more or less work, but should not be necessary. i don't use scripts. i rely on nightly reboots using the reboot scheduler and a fake dual WAN "Fail Over" setup that keeps me online until the automated reboot.

i do have two guest network 1's set up: one on the 2.4Ghz band and one on the 5Ghz band. i moved them both over to the guest network 2 slot. i'm really hoping this works because this issue has been driving me crazy for months. i'll post back with results in a few days.

Are you running the latest firmware? There were some 386 versions that caused issues with fiber providers by forwarding DHCP requests for the LAN out the WAN. But that only came into play if you were using Guest Wireless 1, not sure if you are or not.

You may need to try tweaking the DHCP query frequency on the Asus. Unfortunately what you've given is not enough to really make much as far as recommendations, probably need to look at the logs around the time of the disconnect and do some other troubleshooting while it is down to determine what the issue is.

 

[ceglia]

Are you running the latest firmware? There were some 386 versions that caused issues with fiber providers by forwarding DHCP requests for the LAN out the WAN.

I'm not running the latest latest firmware because others have reported problems, and I didn't want to upgrade and introduce even more issues. But if your suggestion of switching from Guest Network 1 to 2 doesn't work, I might have to bite the bullet and try upgrading. I'm currently running firmware 3.0.0.4.386_49599 which is the last 386 version available for the GT-AX11000 before it jumps to 388.

But that only came into play if you were using Guest Wireless 1, not sure if you are or not.

I was using Guest Wireless 1 on both the 2.4Ghz band and the 5Ghz band. I have now switched both to Guest Wireless 2, and unfortunately I had yet another disconnection this morning. I ran some diagnostics on the AT&T gateway this morning, and it reported some issues, so I contacted AT&T to learn more. Apparently there is some issue with their equipment before the signal reaches my gateway, so a tech will come out tomorrow to take a look. I feel like this is coincidental though, and not related to the issues my Asus router is having connecting to the gateway. I really hope I'm wrong about that and this is the source of all my problems, but it's been over 6 months that I've been dealing with this, and the issue they're seeing apparently affects my whole neighborhood. I can't imagine it's been like that this long with no one else complaining or AT&T noticing.... but who knows.

You may need to try tweaking the DHCP query frequency on the Asus.

I tried that. I saw an FAQ posted by Asus about using "continuous mode". I've tried "aggressive", "normal", and "continuous". None of them made any difference in my case.

Unfortunately what you've given is not enough to really make much as far as recommendations, probably need to look at the logs around the time of the disconnect and do some other troubleshooting while it is down to determine what the issue is.

Here's a little more info on my setup. My ISP is AT&T fiber and I have an AT&T gateway model no. BGW320-505. The gateway is set to passthrough DHCPS-fixed mode. The gateway's wireless bands are all turned off and so are all the gateway's firewall settings.

I have two GT-AX11000 routers, a primary router that connects to the gateway, and a secondary router in AP mode that is connected to the primary router via ethernet. I run guest networks on both the 2.4Ghz band and the 5Ghz band for my IoT devices. Once a day the connection from the primary router to the AT&T gateway drops, and all my devices lose their connection to the internet. A manual reboot of both GT-AX11000's restores everything to normal, but sometimes this happens when I'm not home or worse when I'm on vacation, which is super annoying.

I've come up with two workarounds that allow me to endure this problem. The first is the Asus reboot scheduler. Both my routers automatically reboot every morning before we wake up. If the connection has dropped prior to this reboot, it is restored. However, if the connection drops, say, at 11am, and I'm not home to manually reboot the routers, I'm left without internet in the house until the following morning.

As such I came up with a second somewhat strange workaround: Dual WAN. I run a second ethernet cable from my primary router to the same AT&T gateway. I don't actually have a second ISP, I'm merely connecting the primary router to the gateway TWICE. I then enable Dual Wan in "Fail Over" mode on the primary router, check "Allow Fail Back" on, and enable Network Monitoring using a DNS query. this surprisingly works -- not perfectly, but well enough to keep me going until the next morning's automatic reboot (or if I'm home, a manual reboot). whenever the primary connection drops, the router switches to the secondary connection automatically and virtually every device is able to stay connected to the internet. The only devices that do not stay connected are WiFi devices that are too far from my second GT-AX11000 router (the one in AP mode). For some reason, the WiFi network on my primary GT-AX11000 router (the one connected directly to the gateway) stops working. Wired connections work, but not WiFi. But since the vast majority of my devices are within WiFi range of the second GT-AX11000 router, everything continues working as it should for the most part. And in any case, the following morning, the scheduled reboot happens, the primary connection is restored automatically, and everything goes back to normal (until the next disconnect ).

here is my log when dual WAN is enabled and the primary connection drops. in this instance, the primary connection dropped at 21:04. you can see that it switches over to the secondary connection (dual WAN) soon after that, and oddly enough uses a 192.168.1.70 WAN IP address (which works).

May 26 21:04:03 wlceventd: wlceventd_proc_event(494): eth8: Deauth_ind CE:34:7C:FE:20:65, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-70
May 26 21:04:04 wlceventd: wlceventd_proc_event(494): eth8: Deauth_ind CE:34:7C:FE:20:65, status: 0, reason: Previous authentication no longer valid (2), rssi:-70
May 26 21:04:06 wlceventd: wlceventd_proc_event(530): eth8: Auth CE:34:7C:FE:20:65, status: Successful (0), rssi:0
May 26 21:04:06 wlceventd: wlceventd_proc_event(559): eth8: Assoc CE:34:7C:FE:20:65, status: Successful (0), rssi:-74
May 26 21:04:10 wlceventd: wlceventd_proc_event(494): eth8: Deauth_ind CE:34:7C:FE:20:65, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-74
May 26 21:04:11 wlceventd: wlceventd_proc_event(494): eth8: Deauth_ind CE:34:7C:FE:20:65, status: 0, reason: Previous authentication no longer valid (2), rssi:-75
May 26 21:04:11 wlceventd: wlceventd_proc_event(530): eth8: Auth CE:34:7C:FE:20:65, status: Successful (0), rssi:0
May 26 21:04:11 wlceventd: wlceventd_proc_event(559): eth8: Assoc CE:34:7C:FE:20:65, status: Successful (0), rssi:-74
May 26 21:04:15 wlceventd: wlceventd_proc_event(494): eth8: Deauth_ind CE:34:7C:FE:20:65, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-74
May 26 21:04:15 wlceventd: wlceventd_proc_event(511): eth8: Disassoc CE:34:7C:FE:20:65, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
May 26 21:04:15 wlceventd: wlceventd_proc_event(511): eth8: Disassoc CE:34:7C:FE:20:65, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
May 26 21:04:49 wlceventd: wlceventd_proc_event(494): eth7: Deauth_ind A4:77:33:F8:99:E6, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:0
May 26 21:04:52 rc_service: wanduck 1240:notify_rc restart_wan_if 0
May 26 21:04:56 rc_service: wanduck 1240:notify_rc restart_wan_line 1
May 26 21:04:57 wan: finish adding multi routes
May 26 21:04:57 miniupnpd[3021]: shutting down MiniUPnPd
May 26 21:04:57 miniupnpd: it is advised to use network interface name instead of 192.168.50.1/255.255.255.0
May 26 21:04:57 miniupnpd[21849]: HTTP listening on port 33988
May 26 21:04:57 ddns: WAN IP is empty.(10)
May 26 21:04:57 miniupnpd[21849]: Listening for NAT-PMP/PCP traffic on port 5351
May 26 21:04:59 kernel: Warning: ct_time_p->intv 0 ct->blog_key[BLOG_PARAM1_DIR_ORIG 0] 0x0 ct->blog_key[BLOG_PARAM1_DIR_REPLY 1] 0x60000046
May 26 21:05:01 kernel: Warning: ct_time_p->intv 0 ct->blog_key[BLOG_PARAM1_DIR_ORIG 0] 0x0 ct->blog_key[BLOG_PARAM1_DIR_REPLY 1] 0x60000046
May 26 21:05:01 kernel: Warning: ct_time_p->intv 0 ct->blog_key[BLOG_PARAM1_DIR_ORIG 0] 0x0 ct->blog_key[BLOG_PARAM1_DIR_REPLY 1] 0x60000046
May 26 21:05:01 WAN(1) Connection: WAN was restored.
May 26 21:05:12 watchdog: start ddns.
May 26 21:05:12 rc_service: watchdog 2150:notify_rc restart_ddns watchdog
May 26 21:05:12 ddns: use Private WAN IP (192.168.1.70).(9)
May 26 21:05:31 wlceventd: wlceventd_proc_event(494): wl0.1: Deauth_ind 08:FB:EA:16:49:05, status: 0, reason: Unspecified reason (1), rssi:0
May 26 21:05:31 wlceventd: wlceventd_proc_event(530): wl0.1: Auth 08:FB:EA:16:49:05, status: Successful (0), rssi:0
May 26 21:05:31 wlceventd: wlceventd_proc_event(559): wl0.1: Assoc 08:FB:EA:16:49:05, status: Successful (0), rssi:-61
May 26 21:05:32 wlceventd: wlceventd_proc_event(530): eth8: Auth CE:34:7C:FE:20:65, status: Successful (0), rssi:0
May 26 21:05:32 wlceventd: wlceventd_proc_event(540): eth8: ReAssoc CE:34:7C:FE:20:65, status: Successful (0), rssi:-71
May 26 21:05:35 wlceventd: wlceventd_proc_event(530): eth7: Auth A4:77:33:F8:99:E6, status: Successful (0), rssi:0
May 26 21:05:35 wlceventd: wlceventd_proc_event(559): eth7: Assoc A4:77:33:F8:99:E6, status: Successful (0), rssi:-63
May 26 21:05:35 wlceventd: wlceventd_proc_event(494): wl0.1: Deauth_ind 08:FB:EA:16:49:05, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-63
May 26 21:05:36 wlceventd: wlceventd_proc_event(494): wl0.1: Deauth_ind 08:FB:EA:16:49:05, status: 0, reason: Previous authentication no longer valid (2), rssi:-63
May 26 21:05:36 wlceventd: wlceventd_proc_event(494): eth8: Deauth_ind CE:34:7C:FE:20:65, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-69
May 26 21:05:37 wlceventd: wlceventd_proc_event(494): eth8: Deauth_ind CE:34:7C:FE:20:65, status: 0, reason: Previous authentication no longer valid (2), rssi:-69

let me know if you need additional info. i'll post back after the AT&T service tech comes tomorrow.

 

[drinkingbird]

let me know if you need additional info. i'll post back after the AT&T service tech comes tomorrow.

If AT&T sees an issue with their equipment, that's about as close to a smoking gun as you can get. Let them fix their issue before you try to troubleshoot any further.