How to make dhcpd send NAKs instead of silently ignoring DHCPREQUESTS?

[Andre Albsmeier]

On Mon, 02-Apr-2012 at 19:47:16 +0200, Simon Hobson wrote:
> Andre Albsmeier wrote:
> 
> >But now an unknown client does a DHCPREQUEST of, let's say,
> >192.168.24.55 (an address where no host definitions exists).
> >In this case the server remains silent and ignores the request
> >as it is also documented in dhcpd.conf(5). But I want to NAK
> >this address and force the client to do a DHCPDISCOVER (so
> >it gets one from the range 192.168.24.200 to 192.168.24.254
> >above in turn).
> >
> >I added
> >
> >pool {
> >   range 192.168.24.1 192.168.24.199;
> >   deny  unknown-clients;
> >}
> >
> >which works w.r.t. to the DHCPREQUEST mentioned above but now
> >when host2 wants to renew its (static) address I get this in
> >the logfile:
> >
> >Apr  2 16:51:18 <daemon.err> server dhcpd: Dynamic and static leases 
> >present for 192.168.24.23.
> >Apr  2 16:51:18 <daemon.err> server dhcpd: Remove host declaration 
> >host2.domain.org or remove 192.16
> >8.24.23
> >Apr  2 16:51:18 <daemon.err> server dhcpd: from the dynamic address 
> >pool for 192.168.24.0/24
> >
> >since 192.168.24.23 lies within the (now existing) pool ranging
> >from 192.168.24.1 to 192.168.24.199.
> 
> Firstly, is it a problem ? The client will either give up and revert 

Yes, see below ;-)

> to doing Discovers, or it will fail to connect to the network. As 
> long as it doesn't try and use an address it's not been leased, then 

This is exactly what it is doing: This is what happened:

I have a client (WinXP Professional) which has been used in our
net before and had been abandoned a few months ago. But now the
need to use it again reappeared and so we decided to connect it.
Instead of DHCPDISCOVERing and getting one of the IPs from the
dynamic range it started to DHCPREQUEST the 192.168.24.55 and
the server remained silent.

It turned out that the client thought that it had a valid IP of
192.168.24.55 and that the lease would end on 2012-09-10(!). I
have no idea how this happened (my static leases last a few
hours).

> that isn't your problem as the administrator of the DHCP server. 

Well, I am administrator of the whole net with all (not only
DHCP) servers and clients ;-).

In our case things were simply: I manually released the address
and DHCPDISCOVERed the new correct one and things were well.

But I also want to find a way so that the DHCP server automatically
NAKs those request.

> Unless the client is broken, it will only take a few extra seconds to 
> get a network address - once it's realised it isn't getting an answer 
> to it's requests.
> If it fails to revert to Discovers then it's broken and not your 
> responsibility as the DHCP admin. If you are responsible for the 
> client then take it up with the vendor.
> 
> As to the rest, well you cannot include an address used in a 
> fixed-address statement in any pool. The error message you quote was 
> added in response to the numerous threads from people who expected 
> the same operation as a Windows server and then complained that their 
> "static assignments" were being leased out to other clients. There 
> isn't a way to force NACKs of such addresses without triggering this 
> error message - though I suppose you could comment that bit out in 
> the code and recompile.

I fear this is the way I have to go ;-(.

> 
> 
> There is potentially another way to do things.
> The ISC server now supports reserved leases - these are "normal" 
> leases but even if expired will never be re-allocated to other 
> clients. If you create reserved leases for your fixed address clients 
> instead of using host statements then the addresses cannot be given 
> to anything else and will result in a NACK in the circumstances you 
> describe. You can either just extend your main range, or add small 
> ranges to just include the addresses in question.

But from what I have seen I have to hack the dhcpd.leases file
for this. (BTW, I found this possibility before but found it
quite ugly so I decided to ask on the list ;-)).

In my personal opinion (I am no DHCP expert, just a user with the
above observations) I think that if a server is authoritative one
should be able to NAK unknown client's DHCPREQUESTs for addresses
not in dynamic ranges.

Thanks,

	-Andre