RESOLVED: dhcpd sporadically ignoring one of two "copies" of a DHCP request

[Phil Mayers]

On 12/03/14 10:54, Niall O'Reilly wrote:
> At Tue, 11 Mar 2014 19:15:05 +0000,
> Phil Mayers wrote:
>>
>> Digging into the source code I found the cause; apparently we had
>> "ping-check" on (!) and, if you do that, the lease is allocated but
>> not ACKed until the ping has timed out.
>>
>> While that's happening, lease->state is set, and ack_lease() has a
>> short-circuit return (with no logging; sigh) that drops the 2nd reply.
>>
>> If I read the code path right the same thing would happen with delayed ack.
>
>    Nice work, Phil!
>
>    I'm left wondering whether you see this as a bug, or rather just
>    a nuisance either to be tolerated or to be worked around by disabling
>    "ping-check"?

Well, the absence of a log message when it silently drops the 2nd offer 
I consider a buglet ;o)

I guess in theory it would be nice if dhcpd could recognise "duplicate" 
request packets (identical except for giaddr) and avoid doing the 2nd 
lease lookup and just re-use the value, but that would obviously be a 
substantial undertaking.

Thinking a bit more laterally, I've always thought it a shame that 
giaddr serves two purposes - it tells the server which subnet the 
request came into, and it also tells the server which IP to send the 
reply to. In theory they should be separate, and DHCP replies should go 
to e.g. a router management IP, which would inspect the embedded giaddr 
and forward onwards. This would solve a number of problems (e.g. giaddr 
is not routeable because it's a local-scoped RFC1918 block) as well as 
the uRPF double-reply problem.

(In fact that sounds so likely I'm surprised there isn't a DHCP option 
for it - is there?)

But you could also argue that the DHCP relay agent on routers with FHRP 
should be more intelligent and "know" to skip uRPF check for such replies.

So I would go with "nuisance causes by dhcpd lookup logic combined with 
HSRP and uRPF", but it's highly non-obvious behaviour, particularly in 
the absence of that logging message!

Cheers,
Phil