On 24/10/2018 14:41, to...@tuxteam.de wrote: > On Wed, Oct 24, 2018 at 02:35:37PM +0200, tony wrote: > > [...] > >> Ew, this time it worked. I wonder why deleting the leases file was >> better than clearing it out? > > Some things you gotta delete *twice*. > > (Sigh. I guess everyone here knows _that_ feeling... :) > > Glad you found it > -- t >
I submitted my problem to the isc-dhcp mail list, but while waiting for their reply, I deleted the leases file. They came back with some useful advice, which I wish I had taken. I admitted to them what I had done. I think it would be useful ro repeat their caution: ------------------------------------------------------------------- For the benefit of others finding this thread ... In general it is a very bad idea deleting the leases file. In your case, not a problem as you have a small network and still at the testing stage. But in general, with an active network, you have blown away the record of all the "promises" the server has made to clients. There will be clients with active leases, but the server will have no record of them. At the very best, this can result in churn when clients come back (eg a device that's been switched off is turned on) and their address has been leased to another device - so they get a new address. But what is likely to happen is new clients come along and get offered an address that's already in use - what happens then depends on a number of factors. If the device already using the address responds to pings, then the server may detect it with it's "ping before offer" function. The address will then be marked as abandoned - and not used again unless you completely run out of free addresses. This results in increased address churn "forever" as part of your pool is never used unless you clean it up (or they get recovered if you run out of addresses which shouldn't happen in a well provisioned network). If the device doesn't respond to a ping, then the server will offer the address to the client. The client *should* detect that it's already in use and reject the offer - but the server will not stop offering the address to clients, resulting in a lot of "offer-reject" exchanges. If the client is poorly implemented and just accepts the address then you now have two devices using the same address and neither will work properly/at all. Users may or may not (depending on the implementation) get a warning about the duplicate address. ------------------------------------------------------------------- Ouch! The correct solution (according to the experts) is: ------------------------------------------------------------------- The client is obviously retaining state of the address it once had, and is requesting that address. As the address is available for teh client, it is given it. Some ways to fix it : Remove the address from the range(s) allowed in the server config. Next time the client requests the address, it will be refused (DHCP-Nack message), the client will then be given it's fixed address. Split out the address to separate range (in a separate pool) and add "deny booting" to the range. As above, on the next renew the client will be refused. Add "deny known clients" to the range. The host statement makes the laptop a known client, and so the deny known clients statement will mean that the client is not allowed an address from the range. So as above, next time the client sends a request, it will be refused. Note that this would affect other hosts with a host statement. Similar to above, define a class that matches the client and add "deny members of <name of class>" to the range. Stop the server and edit the leases file. Find the last lease entry for the host and edit it - change the hardware and/or Client-ID fields so that the lease now belongs to a different client. Then start the server again. Next time the client sends a request, it will be denied as the server now thinks that the address belongs to a different client. The lease will eventually time out and go into the pot to be re-used. It won't be reused until every address in the range(s) has already been used at least once - "never used before" addresses are used before any previously used address is re-used for a different client. ------------------------------------------------------------------- Cheers, tony