where to get the lease file

Mihai Buha mihai.buha at nivis.com
Fri Nov 24 08:15:40 UTC 2006


 

> -----Original Message-----
> From: Denis Vlasenko [mailto:vda.linux at googlemail.com] 
> Sent: Friday, November 24, 2006 1:39 AM
> To: busybox at busybox.net
> Subject: Re: where to get the lease file
> 
> If you will try to preserve IP addresses, your users will grow so
> accustomized to that that they will scream murder everytime their
> IP address changes. And it will change, sometimes.
> After that point you can switch to static addresses as well.

Static addresses are impractical on a sufficiently large network because
users change their computers and/or change their network cards. When
that happens, you have to go to that workstation and manually configure
it. Or let the user do it and then respond to the "network not working"
call. If using dhcp with static assignment in dhcpd.conf, it's a bit
easier: the user must come to you holding the new MAC address in his
teeth and wait for you to reconfigure the server.

> I think that if you (the admin) have DHCP-controlled network,
> you have to communicate very clearly to your users that IP
> addresses are not going to survive over reboots, period.
> Anyone who expects that will be disappointed.

A dhcp lease says very clearly that the IP will survive until the end of
the lease, which the server admin has configured. You are proposing to
violate the protocol :)

> OTOH, if client machine is NOT rebooted, sanely set up DHCP network
> will keep client's address the same, for all the reasons you mention.

Wrong. Old network cards are replaced, and so old leases remain unused.
After a while, all the free IP addresses are exhausted and the dhcp
server will recycle old leases.

> > dynamic DNS and existing TCP sessions that will have to be broken.
> 
> Existing TCP sessions do not survive reboots anyway.

...assuming the dhcp server is hosted on the network gateway :)

> > > DHCP server should try hard to not assign IP address 
> which is already taken.
> > > It can be done by sending ARP probes before you hand out new IP
> > > to new client. Lease file is not needed for that.
> > 
> > That just doesn't work on a large network. Note that I 
> don't know which
> > server was being used on that instance, but it was based on 
> probes for
> > taken addresses.
> > 
> > And also for those cenarios like two clients asking for the 
> same IP to a
> > just started server (it's conceivable, but extremely unlikely).
> 
> If udhcpd can hand out same IP to two machines, it's a bug regardless
> of existence of lease file or lack thereof.

It's a four-step handshake:
1) client sends broadcast DISCOVER packet: "I am MAC. What is my IP?".
More than once, if no server answers. This is why windows 9x stops for a
few seconds during boot if not statically configured and if unable to
reach a dhcp server. (Baaad windows, baaaad!)
2) server sends unicast OFFER packet: "MAC, I am SERVER, you can have
this IP, if you want"
3) client sends unicast REQUEST packet: "I am MAC. SERVER, please lend
me IP"
4) server sends unicast ACK packet: "MAC, I am SERVER, you may use IP
until TIME" and also updates the lease file. 
After that, the client won't attempt any communication with the server
until TIME. Then, it will repeat from step 3.
Presumably, the server cannot process two ACK packets at once and also
checks the lease file in this step. There also is a unicast NAK packet
which causes the client to restart from step 1.

This is what I observed in a real network. The theory is probably in RFC
2131.

> 
> > It's just good practice. But also unavailable on some 
> embedded systems.
> > I was just trying to explain the practice, not mandating it.
> 
> Well, I also just letting people know how _I_ see it.
> I surely can be wrong too.
> --
> vda
Mihai


This e-mail (including any attachments to it) is confidential, proprietary, legally privileged, subject to copyright and is sent for the personal attention of the intended recipient only. If you have received this e-mail in error, please reply to advise us immediately, delete it and destroy any printed copies of it. You are notified that reading, disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. No employee is authorized to conclude any binding agreement on behalf of NIVIS LLC with another party by e-mail without express written confirmation by an officer of the company. Although we have taken reasonable precautions to ensure no viruses are present in this e-mail, we cannot accept responsibility for any loss or damage arising from the viruses in this e-mail or attachments.



More information about the busybox mailing list