[prev in list] [next in list] [prev in thread] [next in thread] 

List:       dhcp-hackers
Subject:    Re: dhcprequest function
From:       dhcp.50.CHRIS94561 () spamgourmet ! com
Date:       2004-03-31 21:25:56
Message-ID: LNX4.44040331015454026503-100000 () ravenglass ! net
[Download RAW message or body]

On Wed, 31 Mar 2004, David W. Hankins  - David_Hankins@isc.org wrote:

> On Mon, Mar 29, 2004 at 10:51:28PM -0500, dhcp.50.CHRIS94561@spamgourmet.com wrote:
> > I dunno about pretty clear. Were I implementing this I'd be inclined to
> > ignore the multicast requirement and use the broadcast flag as my
> > barrometer but that's just me.
>
> but as i understand it, this is for the case where a relayed client is
> unicasting a renewal and the dhcpd wants to NAK it.  obviously, if
> the client is directly attached we can (and do) broadcast back to it
> wether it has unicasted the REQUEST or not.

  Actually this is for a client, not being relayed, that is unicasting a
renewal for a formerly valid lease that for whatever reason the server
can no longer honour. Say this example:

The dhcp server config file is restructured to no longer include the
leased address in the range of offered addresses and the lease is cleared
from the lease db. When comes time for the client to renew the dhcprequest
message is simply dropped by the dhcp server. No NAK is sent. The client
is left to timeout and return to the init state.

Why do this? The reason supplied so far for this particular
implementation, by Mr Lemon, is that the rfc seems a little confused on if
we can unicast NAKs directly to client. And since the client does have a
valid ip we cannot broadcast a NAK.

> by the way, is there actually a problem here somewhere you're trying to
> trace down?

Not really, I'm trying to understand how the code works. I read the code,
the comments and the rfc and it didn't pull together. Now I have an answer
but to be honest I dissagree with the decision.

Chris




[prev in list] [next in list] [prev in thread] [next in thread]