Posted: Wed Sep 12, 2018 20:51 Post subject: WRT54GL WAN DHCP lease time reaching 0
Since the forum timed me out and my original post was discarded, it will be a bit shorter this time, sorry
With an earlier build (r36527-min) I experienced daily disconnects from the Internet. Connectinon was not re-eastablished until router reset (or later - automatic recovery by pinging Google's DNS). Then I upgraded to the latest published version (r36698-std) and the problem disappeared - my connection is stable for almost a week now.
What is bugging me is that on the Status screen I can see the WAN DHCP lease time reaching 0 continously. If I press renew (or execute "kill -USR1 $(head -n 1 /var/run/udhcpc.pid)") the timer jumps up to an hour, just to renew once or twice and to reach zero again.
I set "iptables -I INPUT -p udp --dport 68 -j logaccept" in the Firewall script already.
Router is connected to a modem-router (with all functions disabled, working as a modem only; no GUI, WRT54GL gets WAN IP) with no DMZ hosts set. Syslog shows nothing other than periodic NTP updates.
To recap: I have no disconnects anymore, only the WAN DHCP lease time is reaching 0 all the times.
Should I be worried? Is there a way to make sure that this is a GUI bug only, and I should not expect the disconnects to start all over again?
Joined: 23 Jul 2017 Posts: 725 Location: Brisbane, Australia
Posted: Thu Sep 13, 2018 3:52 Post subject:
I don't know if this is your problem, but apparently DHCP respons s from some ISPs are blocked by the DD-WRT firewall, and can be fixed by adding a firewall rule. Check the wiki at
and look for this heading
Firewall blocks DHCP renewal responses
Yes, I saw this topic and the rule is already set. I'm not a Linux / iptables expert, but I read that if you change ACCEPT with logaccept it will also log a message when the rule was hit. I have nothing in the logs, except for time synchronization.
Now only one question remains. Why the timer is reaching 0 and why my internet doesn't disconnect when it does?
Maybe I'm missing something (no DD routers around atm), but isn't that how a DHCP timeout works? It counts down to 0, renews the lease, and resets the timer? Why is your timer set to just 1hr? _________________ #NAT/SFE/CTF: limited speed w/ DD#Repeater issues#DD-WRT info: FAQ, Builds, Types, Modes, Changes, Demo#
x64 OPNsense 19.7.7|FT2019.3: EA6900v1.1@1GHz, F7D8302|DD 41596: WNDR4500v2, WNDR4000@533, R6300v1,
E2500, E1500@353, WRT54*@250: GLv1.1 nsg, GSv6 µ, RT-N66U@663|OEM: WGR614v10@400 -> WNR1000v3 mod
As far as I am aware DHCP renewal requests should start when the lease time reaches the half. If I get 12 hours from the ISP's DHCP server, renegotiating should start when the lease reaches 6 hours. The timer is not set on the client side (router) but it is "assigned" by the DHCP server.
Just for curiosity I set a logaccept rule to see the OUTGOING UDP packets from port 67.
@ jxm and everyone else wondering:
I strongly believe that the DHCP blocking was fixed sometime. I am running build r36698 and it seems I have duplicated INPUT rules for bootpc:
root@DD-WRT:~# iptables --list INPUT --verbose
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
846 278K logaccept udp -- any any anywhere anywhere udp dpt:bootpc
6517 766K ACCEPT 0 -- any any anywhere anywhere state RELATED,ESTABLISHED
0 0 ACCEPT udp -- vlan1 any anywhere anywhere udp spt:bootps dpt:bootpc
0 0 DROP udp -- vlan1 any anywhere anywhere udp dpt:route
0 0 DROP udp -- br0 any anywhere anywhere udp dpt:route
0 0 ACCEPT udp -- any any anywhere anywhere udp dpt:route
16 836 DROP icmp -- vlan1 any anywhere anywhere
0 0 DROP igmp -- any any anywhere anywhere
4 232 ACCEPT 0 -- lo any anywhere anywhere state NEW
4182 321K ACCEPT 0 -- br0 any anywhere anywhere state NEW
6825 730K DROP 0 -- any any anywhere anywhere
P.s.: I'm not a Linux/IPTABLES/DD-WRT expert, but I think those two bold lines effectively mean the same.
Joined: 08 May 2018 Posts: 2626 Location: Texas, USA
Posted: Wed Sep 26, 2018 10:50 Post subject:
I can't remember off the top of my head if this device is VLAN 0 / VLAN1 or VLAN 1 / VLAN2. If the latter, VLAN2 is your WAN interface, VLAN1 is your LAN interface (technically, it is br0 in DD-WRT, but). Anyhow, the WAN lease is set by the ISP / ISP modem hardware, LAN is set within DD-WRT itself. I didn't particularly see this problem on the K3X builds, and haven't tested this on K2.6 builds as I was testing other E4200v1 / K2.6 build issues earlier.
WRT54GL is a VLAN0/1 model, so the default firewall configuration is indeed letting the DHCP packets in.
Since my Internet went crazy again I could do some tests. My ISP initially gives a 1 hour lease, after that a 24 hour one. I kept a close eye on the timer, as soon as it reached 30 minutes the lease time jumped up to 24 hours. Even Syslog showed the outgoing packet:
@Per Yngve Berg
It does; by reacing 0 I mean absolute zero: 0 days, 0:00:00.
In the mean time I could capture a clue. Upon reaching 50% of the lease time I can see DHCP broadcasts flying in, but no DHCP response leaving the router! I'll disable the incoming packet logging to leave some room for more entries (syslog can only go back ~2 hours with them...) but I'm getting more confident that there's no point reporting the issue to the ISP as the cause will be my device.
P.s.: in the beginning I thought that reaching 0 lease time causes no Internet disconnect - it does, once my lease is being forced to time out! Leaving the device to stay on 0:00:00 will eventually cause the Internet to drop; only manual renew, router/modem restart or watchdog trigger can bring it back up.
As a dirty workaround I lowered the watchdog interval to 1 minute but I really would like to see this solved!
Okay, so I let the router to run for more than necessary and there are no automatic outgoing renew requests from my device. The funny thing is that if I manually press "Renew" the lease time jumped up from 4h to 14 hours and I could see the outgoing packet in syslog.
This point I am certain that DD-WRT is NOT renewing the WAN DHCP lease automatically. This is confirmed by the amount of scripts online to check an IP and kill/restart udhcpd.
Is this normal behavior? Are only WRT54GLs affected? Or it's a problem with my device? Can anyone hit me with an URL where I can send a bug report? I really could use some adept support
Long time, long silence. Seems the issue seems to be... "unique".
I managed to keep my internet connection up for a month by logging in twice per day and forcing to renew the WAN DHCP lease but it is getting a pain in the back. I'd like to write an application to do that for me.
A simple GET request to Status_Internet.asp will show me the remaining lease time but I have big troubles with virtually pressing the renew button. I tried a POST request to apply.cgi (with change_action=gozilla_cgi and submit_type=renew parameters) but it only leads me to a bad request or immediate disconnect. And it's not a redirect
Can anyone point me to the direction in how can I press the "Renew" button on the Status / WAN page with HTTP requests only?
So after inserting all the necessary fields (submit_button, change_action, action, submit_typ) and HTTP headers to my request I finally get the same status page as response. Turns out apply.cgi will simply disconnect if necessary parameters are missing.
There's only one catch: apply.cgi does not seem to perform the action itself. If I kill -USR1 "$(pidof "udhcpc")" via SSH and collect the status page with my script after, I can see the lease time changing, but I can not FORCE dhcp_renew to be executed via a HTTP request... will do some more digging. It will go kind of slow because of the one day lease time from my ISP