It sounds like that hypothesis may be at least plausible.
I doubt it. If your modem implements bridge mode as described above, the Asus probably never actually communicates with the ISPs DHCP server.
If your modem implements bridge mode this way, I would suspect that the modem's DHCP functionality isn't ready when the Asus restarts the WAN. However, if that's the case setting your DHCP to 'continuous' should theoretically fix the problem.
Isn't continuous the fastest polling frequency? Wouldn't 'normal' be better because it gives more time between polling so more time to recover? I have seen lots of users indicate 'continuous' fixes problems along these lines. It has polling frequency 12Hz I believe. Does it just not stop and keep polling until it gets new address? Whereas 'normal' or 'aggressive' gives up after 3 attempts?
forums.whirlpool.net.au
That's my understanding. I think continuous just keeps asking for an address until it gets one. I think Asus flubbed the documentation as I sincerely doubt it performs a DHCP request 12 times per second.
Yes, sorry (I have an obsessive personality). But I think a lot of progress has been made now. And hopefully this thread will be useful for the many out there who experience this kind of issue (and there appear to be many, from searching on this forum).
forums.whirlpool.net.au
Aug 16 04:38:31 custom_script: Running /jffs/scripts/dhcpc-event (args: deconfig)2021-08-19 02:03:58 System Notice
WAN connection INTERNET_R_UMTS1:IPv4 disconnected
2021-08-19 02:03:59 System Notice
WAN connection INTERNET_R_UMTS1:IPv4 connected| default | 10.0.0.1 | 0.0.0.0 | UG | 0 | 0 | 0 | WAN |
| 10.0.0.0 | * | 255.0.0.0 | U | 0 | 0 | 0 | WAN |
| 10.0.0.1 | * | 255.255.255.255 | UH | 0 | 0 | 0 | WAN |
| 192.168.1.0 | * | 255.255.255.0 | U | 0 | 0 | 0 | LAN |
| 239.0.0.0 | * | 255.0.0.0 | U | 0 | 0 | 0 | LAN |
traceroute to 192.168.8.1 (192.168.8.1), 30 hops max, 38 byte packets
1 10.34.87.157 (10.34.87.157) 2240.702 msAug 16 04:38:31 custom_script: Running /jffs/scripts/dhcpc-event (args: deconfig)I hate to resurrect a thread from August, but I just noticed something.
Probably that for legal reason, Microsoft clients in China are pointed to a server located in China, while the rest of the world is pointed to some non-Chinese CDN provider like Akamai.
#!/bin/bash
renew_wan_lease=0
ip monitor link dev eth0 | while read event; do
logger "maintain-wan-lease detected eth0 event: "$event
case $event in
*'NO-CARRIER'* )
if [ $renew_wan_lease -eq 0 ]; then
logger "maintain-wan-lease detected eth0 state change to: 'NO-CARRIER', so forcing udhcpc to release wan lease."
killall -SIGUSR2 udhcpc
renew_wan_lease=1
fi
;;
*'LOWER_UP'* )
if [ $renew_wan_lease -eq 1 ]; then
logger "maintain-wan-lease detected eth0 state change from: 'NO-CARRIER' to: 'LOWER_UP', so forcing udhcpc to renew wan lease."
killall -SIGUSR1 udhcpc
renew_wan_lease=0
fi
;;
esac
doneIf the firmware`s own WAN monitoring is really broken, then it needs to be fixed upstream, not hacked with a workaround script that may bring its own set of issues.
TNX Eric Perhaps you could assist with this. A word from RMerlin is worth 1000 complaints from end users.
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!
