Lease renewal time

Simon Hobson dhcp1 at thehobsons.co.uk
Thu Nov 6 17:34:37 UTC 2014


Mikhail Morfikov <mmorfikov at gmail.com> wrote:

> I have some problems with configuring the isc server on my router. The
> lease time was set to 60s (just for tests), after about 30s the dhcp
> clients try to renew.

That is correct. The default is for a client to attempt renewal at half the lease time. As you've observed, it will try several times (unicasting to the server it got the lease from), at decreasing intervals, and eventually it will fall back to broadcasting for a server.
It will still have network connectivity until the lease expires.


> ==========CLIENT==========
> Nov  6 16:53:45 red-viper dhclient: DHCPREQUEST on wlan2 to 192.168.1.1 port 67
> Nov  6 16:53:50 red-viper dhclient: DHCPREQUEST on wlan2 to 192.168.1.1 port 67
> Nov  6 16:53:55 red-viper dhclient: DHCPREQUEST on wlan2 to 192.168.1.1 port 67
> Nov  6 16:54:09 red-viper dhclient: DHCPREQUEST on wlan2 to 255.255.255.255 port 67
> Nov  6 16:54:16 red-viper dhclient: DHCPDISCOVER on wlan2 to 255.255.255.255 port 67 interval 7
> Nov  6 16:54:16 red-viper dhclient: DHCPREQUEST on wlan2 to 255.255.255.255 port 67
> Nov  6 16:54:16 red-viper dhclient: DHCPOFFER from 192.168.1.1
> Nov  6 16:54:16 red-viper dhclient: DHCPACK from 192.168.1.1
> Nov  6 16:54:16 red-viper dhclient: bound to 192.168.1.50 -- renewal in 25 seconds.
> ==========SERVER==========
> Nov  6 16:53:45 the-mountain dhcpd: DHCPREQUEST for 192.168.1.50 from e8:de:27:1d:4c:a5 via br-lan
> Nov  6 16:53:45 the-mountain dhcpd: DHCPACK on 192.168.1.50 to e8:de:27:1d:4c:a5 via br-lan
> Nov  6 16:53:51 the-mountain dhcpd: DHCPREQUEST for 192.168.1.50 from e8:de:27:1d:4c:a5 via br-lan
> Nov  6 16:53:51 the-mountain dhcpd: DHCPACK on 192.168.1.50 to e8:de:27:1d:4c:a5 via br-lan
> Nov  6 16:53:56 the-mountain dhcpd: DHCPREQUEST for 192.168.1.50 from e8:de:27:1d:4c:a5 via br-lan
> Nov  6 16:53:56 the-mountain dhcpd: DHCPACK on 192.168.1.50 to e8:de:27:1d:4c:a5 via br-lan
> Nov  6 16:54:10 the-mountain dhcpd: DHCPREQUEST for 192.168.1.50 from e8:de:27:1d:4c:a5 via br-lan
> Nov  6 16:54:10 the-mountain dhcpd: DHCPACK on 192.168.1.50 to e8:de:27:1d:4c:a5 via br-lan
> Nov  6 16:54:16 the-mountain dhcpd: DHCPDISCOVER from e8:de:27:1d:4c:a5 via br-lan
> Nov  6 16:54:16 the-mountain dhcpd: DHCPOFFER on 192.168.1.50 to e8:de:27:1d:4c:a5 via br-lan
> Nov  6 16:54:16 the-mountain dhcpd: DHCPREQUEST for 192.168.1.50 (192.168.1.1) from e8:de:27:1d:4c:a5 via br-lan
> Nov  6 16:54:16 the-mountain dhcpd: DHCPACK on 192.168.1.50 to e8:de:27:1d:4c:a5 via br-lan

Something is wrong !
Next step is to fire up a traffic sniffer on each end and see if the Ack packets are getting back to the client or not.
I assume the two devices can communicate via other protocols ? The biggest difference (networking wise) between the renewals (Request-Ack) and the "full monty" (Discover-Offer-Request-Ack, or DORA for short) is that the packet sin the DORA exchange are broadcast while the short renewal uses unicast packets.



More information about the dhcp-users mailing list