My ISP (actually, campus network) provides DHCP lease of 3600 seconds (1 hour), and I want to keep my router 7*24-hour online. I noticed that OpenWrt will run udhcpc every 30 minutes to extend(correction: I meant renew the lease) the DHCP lease. But this attempt sometimes just fail.
It seems that dhclient and udhcpc have quite different performance. I have tested it in Ubuntu 16.04.
When I have no IP address (released previous DHCP lease by dhclient -r), and call dhclient or udhcpc -i eth1, both of these two commands have the same performance: standard discover-offer-request-ack process.
But if I already have a DHCP lease and want to renew it, dhclient quickly produces request and ack, while udhdpc will send several (randomly from 2 to 6) discovers and just looks like the DHCP server is not responding. The OpenWrt udhcpc also performs like this.
So, how to fix the udhcpc problem on OpenWrt, or can I replace it with dhclient?
You cannot extend the DHCP lease of a client. You campus' network administrator must do that for you. Another option is to use a static IP address on the interface.
You can only extended DHCP leases if you are issuing the IP addresses.
I meant renew the lease. And in the system log I can find
Sat Jan 5 00:21:35 2019 daemon.notice netifd: wan (870): udhcpc: sending renew to ***.***.***.***
Sat Jan 5 00:21:36 2019 daemon.notice netifd: wan (870): udhcpc: lease of ***.***.***.*** obtained, lease time 3600
every 30 minutes. The problem is that this fails sometimes and the IPv4 interface goes down.
Why is that ? As long as the lease is valid and spec compliant, there is nothing for administrator to do. This seems like an implementation bug at the client side. When dhclient runs correctly, it runs and renews the lease automatically. dhclient runs as a process for that though. I don't know how udhcpc does it.
Edit: Client in this case is the openwrt router. The server is the ISP.
The campus router, which is the ISP in their case runs the server. dhclient gets a lease which it puts in the lease file. The lease file has the expiration time. dhclient monitors this lease and renews it on expiration. So why do you need to increase the limit ? Renewals are a function of the lease time, not some cron job.
In the original post, he said that the client runs at some frequency (30 mins or so). I don't know if that is how it is implemented, but that's not how the client is supposed to run. It has to monitor the lease and renew on expiration.
You do understand you want to increase the lease issued from your campus, correct?
@buckaroo, my apologies, I mistook you for the OP.
I'll await their response regarding an understanding of the source of the DHCP lease on WAN (i.e. the campus' device).
Correct. That is how OpenWrt works. So we need to wait for the OP to see if they're running something that's not default OpenWrt on their router.
Works here:
Fri Jan 4 15:37:25 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 15:44:55 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 15:52:25 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 15:59:55 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 16:07:25 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 16:14:55 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 16:22:25 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 16:29:55 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 16:37:25 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 16:44:55 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 16:52:26 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 16:59:56 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Apologies for confusion of extend and renew. I know that unless the administrator of campus net does some change, I will always receive 3600-second lease.
The renew of lease every 30 minutes is implemented by OpenWrt itself right? I don't think I'm running anything else that may trigger this 30-minute renew, not a cron or anything similar.
But this renew just fails occasionally. My router receive no reply from the DHCP server, then the IP address becomes 0.0.0.0 and the interface goes down. Notice that this happens when I still have 30 minutes of lease. It seems that there is no reason for this failure because my network environment is simple.
I noticed that on Ubuntu, dhclient has much better performance in renewing a DHCP lease compared with udhcpc - faster and 100% chance of success. So is there some problem with udhcpc, or I need to do some extra configuration?
You'll have to get more logs or other details for the failure scenario. If you are able to reproduce the failure with udhcpc on ubuntu, it may be easier for debugging and logging. You can do a tcpdump/wireshark capture around the time of the failure to analyze further. You can get dhclient through opkg. Look at isc-dhcp-client-ipv4 and other similar packages. So that may be worth a shot too.
To be honest, I just noticed that my lease on WAN is 900 seconds...I noticed that half-way through that time period (450 seconds), there is a log.
Fri Jan 4 16:29:55 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 16:37:25 2019 daemon.notice netifd: wan (1511): udhcpc: sending renew to xxx.xxx.xxx.xxx
Fri Jan 4 16:37:25 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 16:44:55 2019 daemon.notice netifd: wan (1511): udhcpc: sending renew to xxx.xxx.xxx.xxx
Fri Jan 4 16:44:55 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 16:52:26 2019 daemon.notice netifd: wan (1511): udhcpc: sending renew to xxx.xxx.xxx.xxx
Fri Jan 4 16:52:26 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 16:59:56 2019 daemon.notice netifd: wan (1511): udhcpc: sending renew to xxx.xxx.xxx.xxx
Fri Jan 4 16:59:56 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 17:07:26 2019 daemon.notice netifd: wan (1511): udhcpc: sending renew to xxx.xxx.xxx.xxx
Fri Jan 4 17:07:26 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
Fri Jan 4 17:14:56 2019 daemon.notice netifd: wan (1511): udhcpc: sending renew to xxx.xxx.xxx.xxx
Fri Jan 4 17:14:56 2019 daemon.notice netifd: wan (1511): udhcpc: lease of xxx.xxx.xxx.xxx obtained, lease time 900
In both RENEWING and REBINDING states, if the client receives no
response to its DHCPREQUEST message, the client SHOULD wait one-half
of the remaining time until T2 (in RENEWING state) and one-half of
the remaining lease time (in REBINDING state), down to a minimum of
60 seconds, before retransmitting the DHCPREQUEST message.
Per the DHCP standard, RFC 2131, a DHCP client does not wait for its lease to expire, because it risks getting a new address assigned to it. Instead, when a DHCP client reaches the halfway point of its lease period, it attempts to extend its lease so that it retains the same IP address. Thus, the lease duration is like a sliding window.
Yes, T1 and T2, along with the lease duration guide the client into when it will start to try to renew the lease.
As there seems to be a problem with one client being able to reliably get leases and another having problems, a capture of the exchanges with tcpdump or wireshark could be very enlightening.
Without knowing the topology, there are cases when the initial lease is given out by one IP (relay), yet it gets renewed by another, perhaps even on a different net (server). Watching the exchange and failure mode would reveal is there is something "interesting" about how they are being handled.