perl-list at network1.net
Wed Aug 9 16:25:18 UTC 2006
Once again, thank you very much - that clears everything right up :)
David W. Hankins wrote:
> On Wed, Aug 09, 2006 at 04:25:02PM +0100, Simon Hobson wrote:
>> At 10:43 -0400 9/8/06, Darren wrote:
>>> Does anyone know what the server does with the lease (if exist) when it
>>> receives this message (all IPs have been changed to protect the
>>> guilty). Further, does anyone know why a client would send such a message?:
>>> Jul 12 21:09:52 dhcp-1 dhcpd: DHCPDECLINE of 192.168.0.139 from
>>> 00:11:11:7b:83:da (BRENDA1) via 192.168.0.129: not found
>> It's client specific, but typically it means that the client is
>> unhappy in some way with what it's been offered and wants a different
> It's not client specific. Or rather, it shouldn't be.
> Quoth rfc2131...
> section 3.1:
> DHCPDECLINE - Client to server indicating network address is already
> in use.
> point, the client is configured. If the client detects that the
> address is already in use (e.g., through the use of ARP), the
> client MUST send a DHCPDECLINE message to the server and restarts
> the configuration process. The client SHOULD wait a minimum of ten
> seconds before restarting the configuration process to avoid
> excessive network traffic in case of looping.
> 4.3.3 DHCPDECLINE message
> If the server receives a DHCPDECLINE message, the client has
> discovered through some other means that the suggested network
> address is already in use. The server MUST mark the network address
> as not available and SHOULD notify the local system administrator of
> a possible configuration problem.
> ISC DHCP moves leases that were DECLINEd into the ABANDONED
> ABANDONED leases are never allocated for use - except as a last
> resort (there are no FREE leases remaining).
> DHCP failover pairs version 3.0.3 and prior will never allocate
> ABANDONED leases under any circumstances.
> As of 3.0.4 and future, ABANDONED leases are treated like
> last-resort "FREE" leases (eg only the primary may use them,
> and it only does so as a last resort).
> On the subject of best practices...
> Systems administrators SHOULD look for abandoned leases, and
> investigate if they are in active use by a rogue client on the
> network (using any logs or diagnostics available).
> Once such 'bread crumbs' have been exhausted (or the luser has
> successfully been LARTed), the address SHOULD be reset (returning
> it to the FREE state).
> Unfortunately that last bit either means using OMAPI or editing
> the dhcpd.leases file manually.
More information about the dhcp-users