Reply
Member
Posts: 145
Registered: ‎04-14-2016
Kudos: 102
Accepted Solution

DHCP lease time not to RFC 2131 3.3 standard

Recently I set a 0 (zero) lease time in the DHCP duration slot. Typically this means "inifinite" according to RFC's for DHCP timing.

Note: This happened to a windows 7 laptop, arch linux laptop, and an arch linux desktop all current kernel.

Upon attempting to connect to the network a wireless device would first establish a radio connection, negotiate a link rate and then attempt to receive an IP (in laymens). Because of the 0 second lease time, the controller would release an IP and then immediately revoke it causing an infinite cycling of establishing a connection, it dropping, rinse repeat.

This did not appear to affect all devices that were previously authenticated and connected. Mobile devices seem to handle this fine. But my wireless laptop and desktop devices ran into the cycling. For instance my girlfriends work laptop and a secondary laptop we use around the house every now and then.

It appears that instead of the controller understanding zero as infinite, it takes it as the literal time frame, zero seconds.

https://www.ietf.org/rfc/rfc2131.txt

3.3 Interpretation and representation of time values

   A client acquires a lease for a network address for a fixed period of
   time (which may be infinite).  Throughout the protocol, times are to
   be represented in units of seconds.  The time value of 0xffffffff is
   reserved to represent "infinity".

   As clients and servers may not have synchronized clocks, times are
   represented in DHCP messages as relative times, to be interpreted
   with respect to the client's local clock.  Representing relative
   times in units of seconds in an unsigned 32 bit word gives a range of
   relative times from 0 to approximately 100 years, which is sufficient
   for the relative times to be measured using DHCP.

   The algorithm for lease duration interpretation given in the previous
   paragraph assumes that client and server clocks are stable relative
   to each other.  If there is drift between the two clocks, the server
   may consider the lease expired before the client does.  To
   compensate, the server may return a shorter lease duration to the
   client than the server commits to its local database of client
   information.

 

-OnTheGrind

Accepted Solutions
Ubiquiti Employee
Posts: 4,935
Registered: ‎08-08-2016
Kudos: 5235
Solutions: 343

Re: DHCP lease time not to RFC 2131 3.3 standard

It provisions correctly, and ends up with the following dhcpd.conf on USG.

                default-lease-time 0;
                max-lease-time 0;

which then sends the lease time as 0. From tcpdump: 

Lease-Time Option 51, length 4: 0

dhcpd apparently wants a -1 for infinite, though in a quick test it doesn't lease anything at that. Reference:

https://serverfault.com/questions/505300/isc-dhcp-infinite-lease-time

https://bugzilla.redhat.com/show_bug.cgi?id=1132396

 

If you want to hack the dhcpd.conf on USG to test and report back results, welcome what happens there. It looks like EdgeOS should write out 0 lease time differently. 

View solution in original post


All Replies
Senior Member
Posts: 2,943
Registered: ‎08-06-2015
Kudos: 1245
Solutions: 173

Re: DHCP lease time not to RFC 2131 3.3 standard

[ Edited ]

"0" is not an infinite lease time though many seem to think it is Man Sad  A 0-second lease time is in fact 0 seconds.

 

From the RFC text that was quoted this is even confirmed:

 

The time value of 0xffffffff is reserved to represent "infinity".

 

If you are configuring your DCHP through a GUI it should have an option for 'infinite'.  If it does not or if you are configuring your DHCP server via text file you should use the value '-1', which is the decimal representation for the hex value identified above.  Yes the DHCP standard states unsigned 32-bit value, so if your DHCP server does not like '-1' you can use the unsigned value '4294967295' instead.

 

However while it is possible to do so setting an infinite lease time is generally not a good practice.

Ubiquiti Employee
Posts: 4,935
Registered: ‎08-08-2016
Kudos: 5235
Solutions: 343

Re: DHCP lease time not to RFC 2131 3.3 standard

It provisions correctly, and ends up with the following dhcpd.conf on USG.

                default-lease-time 0;
                max-lease-time 0;

which then sends the lease time as 0. From tcpdump: 

Lease-Time Option 51, length 4: 0

dhcpd apparently wants a -1 for infinite, though in a quick test it doesn't lease anything at that. Reference:

https://serverfault.com/questions/505300/isc-dhcp-infinite-lease-time

https://bugzilla.redhat.com/show_bug.cgi?id=1132396

 

If you want to hack the dhcpd.conf on USG to test and report back results, welcome what happens there. It looks like EdgeOS should write out 0 lease time differently. 

Member
Posts: 145
Registered: ‎04-14-2016
Kudos: 102

Re: DHCP lease time not to RFC 2131 3.3 standard


UBNT-cmb wrote:

It provisions correctly, and ends up with the following dhcpd.conf on USG.

                default-lease-time 0;
                max-lease-time 0;

which then sends the lease time as 0. From tcpdump: 

Lease-Time Option 51, length 4: 0

dhcpd apparently wants a -1 for infinite, though in a quick test it doesn't lease anything at that. Reference:

https://serverfault.com/questions/505300/isc-dhcp-infinite-lease-time

https://bugzilla.redhat.com/show_bug.cgi?id=1132396

 

If you want to hack the dhcpd.conf on USG to test and report back results, welcome what happens there. It looks like EdgeOS should write out 0 lease time differently. 



Awesome. Just pointed it out. So now when someone Googles this if they run into it, they'll know.




-OnTheGrind
Reply