What's new

Router would sometime fail to renew a WAN DHCP lease. (fix by theMIROn)

  • 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!

Dirk Osstyn

New Around Here
I am having frequent "WAN Connection: ISP's DHCP did not function properly." messages (several times a day). This stops the internet connectivity for about 30 seconds, but is quite annoying nevertheless.
I noticed a fixe called "Router would sometime fail to renew a WAN DHCP lease. (fix by theMIROn)" in version 380.60 of the Merlin version. But this dates back to 2016 while we are 2018 right now and I still see many threads on this topic...
Anyone having a clue how to fix this?
 
Hi, I am new to this forum but I am happy to see it is very much alive so thanks for the reply.

Currently I am running the latest native firmware: 3.0.0.4.384_20308-gead790e. But I am considering a move to AsuswrtMerlin considering it would support AiMesh and solve the issue. And of course, the extra features are surely an interesting add on for me as well.
I am using an RT-AC88U (and potentially an RT-AC68U on top lateron).
I am connected to the internet behind a cable modem/router, Docsis 3, for which I do not know the brand. The MAC address starts with 5C:35:3B. The internet tells me this would be a "Compal Broadband Networks Inc." router.
It is a router, indeed, and I cannot set up a static IP address in that router. I notice that the lease time of the WAN IP@ is 3600 seconds but this, as well, is a parameter that is not available to users. I could try specifying a fixed IP@ at Asus side as indeed his IP@ does not change too often but not sure if this would work: their DHCP might consider "no requests, so let's cut off access".
I already changed the DHCP query frequency at ASUS side to "Normal" rather than "aggressive", but this didn't seem to help.
Main question is, of course, if the ASUS is reacting properly. My previous router didn't have this logging capability so the problem may not have been visible, but alternatively, my previous router (Linksys E4200) could cope with it in a better way?

Below is the log of yesterday: the problem appeared 3 times (I skipped the log of 11:37 the same day). Around 13:26 I had 2 events in a row, then got silent for the rest of the day.
Feb 4 13:26:28 WAN Connection: ISP's DHCP did not function properly.
Feb 4 13:26:28 DualWAN: skip single wan wan_led_control - WANRED off
Feb 4 13:26:29 nat: apply redirect rules
Feb 4 13:26:33 WAN Connection: Ethernet link up.
Feb 4 13:26:33 rc_service: wanduck 26312:notify_rc restart_wan_if 0
Feb 4 13:26:34 wan: [deconfig] udhcpc done[286]
Feb 4 13:26:36 wan: [wan0_hwaddr] == [10:7B:44:AF:04:58]
Feb 4 13:26:37 wan: [deconfig] udhcpc done[286]
Feb 4 13:26:40 rc_service: udhcpc 3123:notify_rc start_firewall
Feb 4 13:26:40 miniupnpd[29776]: shutting down MiniUPnPd
Feb 4 13:26:41 wan: finish adding multi routes
Feb 4 13:26:41 rc_service: udhcpc 3123:notify_rc stop_upnp
Feb 4 13:26:41 rc_service: waitting "start_firewall" via udhcpc ...
Feb 4 13:26:41 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Feb 4 13:26:41 miniupnpd[3159]: version 1.9 started
Feb 4 13:26:41 miniupnpd[3159]: HTTP listening on port 58446
Feb 4 13:26:41 miniupnpd[3159]: Listening for NAT-PMP/PCP traffic on port 5351
Feb 4 13:26:42 rc_service: udhcpc 3123:notify_rc start_upnp
Feb 4 13:26:42 rc_service: waitting "stop_upnp" via udhcpc ...
Feb 4 13:26:42 miniupnpd[3159]: shutting down MiniUPnPd
Feb 4 13:26:43 start_ddns: update WWW.ASUS.COM dyndns, wan_unit 0
Feb 4 13:26:43 WAN Connection: WAN was restored.
Feb 4 13:26:43 miniupnpd[3164]: version 1.9 started
Feb 4 13:26:43 miniupnpd[3164]: HTTP listening on port 55580
Feb 4 13:26:43 miniupnpd[3164]: Listening for NAT-PMP/PCP traffic on port 5351
Feb 4 13:26:43 ddns update: ez-ipupdate: starting...
Feb 4 13:26:43 ddns update: connected to nwsrv-ns1.asus.com (103.10.4.108) on port 80.
Feb 4 13:26:46 ddns update: Asus update entry:: return: HTTP/1.1 299 |Invalid IP format| 192.168.0.212^M Date: Sun, 04 Feb 2018 12:26:42 GMT^M Server: Apache^M X-Powered-By: PHP/5.6.30^M Content-Length: 0^M Content-Type: text/html; charset=UTF-8^M ^M
Feb 4 13:26:46 ddns update: retval= 1, ddns_return_code (,299)
Feb 4 13:26:46 ddns update: asusddns_update: 1
Feb 4 13:26:59 rc_service: udhcpc 3123:notify_rc start_firewall
Feb 4 13:26:59 miniupnpd[3164]: shutting down MiniUPnPd
Feb 4 13:27:00 dhcp client: bound 192.168.0.212 via 192.168.0.1 during 3600 seconds.
Feb 4 13:27:00 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Feb 4 13:27:00 miniupnpd[3254]: version 1.9 started
Feb 4 13:27:00 miniupnpd[3254]: HTTP listening on port 58566
Feb 4 13:27:00 miniupnpd[3254]: Listening for NAT-PMP/PCP traffic on port 5351
Feb 4 13:27:30 WAN Connection: ISP's DHCP did not function properly.
Feb 4 13:27:30 DualWAN: skip single wan wan_led_control - WANRED off
Feb 4 13:27:30 nat: apply redirect rules
Feb 4 13:27:35 WAN Connection: Ethernet link up.
Feb 4 13:27:35 rc_service: wanduck 26312:notify_rc restart_wan_if 0
Feb 4 13:27:36 wan: [deconfig] udhcpc done[286]
Feb 4 13:27:38 wan: [wan0_hwaddr] == [10:7B:44:AF:04:58]
Feb 4 13:27:38 wan: [deconfig] udhcpc done[286]
Feb 4 13:27:41 rc_service: udhcpc 3308:notify_rc start_firewall
Feb 4 13:27:42 miniupnpd[3254]: shutting down MiniUPnPd
Feb 4 13:27:42 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Feb 4 13:27:42 wan: finish adding multi routes
Feb 4 13:27:42 rc_service: udhcpc 3308:notify_rc stop_upnp
Feb 4 13:27:42 rc_service: waitting "start_firewall" via udhcpc ...
Feb 4 13:27:42 miniupnpd[3343]: version 1.9 started
Feb 4 13:27:42 miniupnpd[3343]: HTTP listening on port 54984
Feb 4 13:27:42 miniupnpd[3343]: Listening for NAT-PMP/PCP traffic on port 5351
Feb 4 13:27:43 WAN Connection: WAN was restored.
Feb 4 13:27:43 rc_service: udhcpc 3308:notify_rc start_upnp
Feb 4 13:27:43 rc_service: waitting "stop_upnp" via udhcpc ...
Feb 4 13:27:43 miniupnpd[3343]: shutting down MiniUPnPd
Feb 4 13:27:44 start_ddns: update WWW.ASUS.COM dyndns, wan_unit 0
Feb 4 13:27:44 ddns update: ez-ipupdate: starting...
Feb 4 13:27:44 miniupnpd[3349]: version 1.9 started
Feb 4 13:27:44 miniupnpd[3349]: HTTP listening on port 46235
Feb 4 13:27:44 miniupnpd[3349]: Listening for NAT-PMP/PCP traffic on port 5351
Feb 4 13:27:45 ddns update: connected to nwsrv-ns1.asus.com (103.10.4.108) on port 80.
Feb 4 13:27:47 ddns update: Asus update entry:: return: HTTP/1.1 299 |Invalid IP format| 192.168.0.212^M Date: Sun, 04 Feb 2018 12:27:44 GMT^M Server: Apache^M X-Powered-By: PHP/5.6.30^M Content-Length: 0^M Content-Type: text/html; charset=UTF-8^M ^M
Feb 4 13:27:47 ddns update: retval= 1, ddns_return_code (,299)
Feb 4 13:27:47 ddns update: asusddns_update: 1
Feb 4 13:28:01 rc_service: udhcpc 3308:notify_rc start_firewall
Feb 4 13:28:01 dhcp client: bound 192.168.0.212 via 192.168.0.1 during 3600 seconds.
Feb 4 13:28:01 miniupnpd[3349]: shutting down MiniUPnPd
Feb 4 13:28:02 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Feb 4 13:28:02 miniupnpd[3440]: version 1.9 started
Feb 4 13:28:02 miniupnpd[3440]: HTTP listening on port 48340
Feb 4 13:28:02 miniupnpd[3440]: Listening for NAT-PMP/PCP traffic on port 5351
 
Feb 4 13:26:33 WAN Connection: Ethernet link up.
Your router is losing communication with the modem. If you haven't already done so, replace your modem to router ethernet cable with a good quality cat5e or cat6 cable.
 
Your router is losing communication with the modem. If you haven't already done so, replace your modem to router ethernet cable with a good quality cat5e or cat6 cable.
Hi. On the cable stuff: this is a Cat6 cable I bought some time ago. I did re-push it into the router yesterday just to be sure (because I have seen a number of such comments as well) and - being afraid being haunted by Murphy I barely dare to say that - it seems that over the past 24hrs the connection is quite stable (no new log entries).
My overall connection seems to be good for surfing, streaming, etc, without issues. What I don't really understand is how come traffic is flowing freely while the connectivity would mainly fail on DHCP renewal? DHCP renewal, to me, seems to be a fairly easy thing with limited data being exhanged.

Well, first have to see if Murphy doesn't kill me for telling that things went well for 24 hrs of course.
 
On the cable stuff
A couple of things learned from the school of hard knocks....
- A new cable is not necessarily a good cable - I've had cables fail out of the package.
- Cables do go bad, possibly due to handling damage or a latent manufacturing defect.
- Sockets can also have problems, a trapped piece of dirt or a bent pin can happen.
- There's no way to absolutely link a bad cable to any any particular operation.

Should the problem re-occur, replace the cable, visually inspect the sockets and clean them out with compressed air.
 
OK guys. And especially @john9527:
About 48 hours ago, I touched the cable, pushing it a bit further into the router, if possible. Ever since, my logging is empty. Completely empty for 48 hours. Couldn't be better, so no haunting by Murphy. So it must have been the cable.
I might consider replacing the RJ45 plug at router side so that it is fixed a bit better but I don't want to make things worse either...

Just for the sake of completeness: @s3n0:
There is no PPPoE needed here, it's a kind of straight line to the internet without authentication needs. I have an always on connection. I can reach my modem from the outside if I wish. This is also why you see the DDNS errors: the double NAT doesn't allow to provide an external IP@ by the router itself. I circumvented this issue by creating a port forwarding in my ISP modem/router. The nice thing is that I can also simply disable this forwarding as a security measure to protect my router from outside access.

:eaves me to thank both of you for your kind and swift feedback. I have become a fan of this forum: it is alive, people respond, etc... Unlike many other forums where people just come to say "I have the same problem"...
The internet is full of remarks about the DHCP issue with ASUS routers. At some point in time people would believe that this is an ASUS specific problem. So (1) let's spread the word about the potential external source of the problem and (2) I have been using the same cable for a number of years with my Linksys E4200 but this system simply doesn't give any clue about what is really going on: you simply don't know you have a problem, except that there are some hick-ups in the communication with the internet from time to time, but these disappear after half a minute. The latter is the main advantage of my new router: at least it gives me some clue that something ain't right, allowing me to look for a solution!
 
As an aside, the Ethernet cable Asus provides with their high-end routers is pretty high quality. It's the one with the metal shielding around the RJ45 connector. It feels quite snug once plugged in, and has a very satisfying click sound to it when you plug it in (better spring effect than cheap plastic-based connectors that tend to get loose with time).

Ideally (if it's long enough), I recommend always using that cable between the modem and the router.
 

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top