Subject: [dhcwg] 'secs' field

From: Michele Pedrolli <[email-masked]>
Date: Wed, 1 Feb 2006 16:54:44 +0100

The use of 'secs' field in the DHCP header isn't clear for me.

 From RFC 2131:
- secs, filled by the client, seconds elapsed since client began  
address acquisition or renewal process

and:

Field	DHCPOFFER	DHCPACK	DHCPNACK
-------	-------------------	---------------	-----------------
'secs'	0				0			0

So, in a RFC-compliant environment, all messagges coming from a DHCP  
server MUST have 'secs' field set to 0. Is that right?
I don't understand what expression "address acquisition" means.
If a client send a DHCPDISCOVER and receives an OFFER, the following  
DHCPREQUEST must have the secs field set with the number of seconds  
elapsed from the first DHCPDISCOVER?

Analyzing a dhcp trace with Ethereal, I see duplicated DHCPACK  
messages like this:

SRC			DST				TYPE		XID				SECS
-----------------		-----------------------		---------------	------------ 
--------	---------
192.168.10.4	255.255.255.255 	DHCPACK 	0xe7f6b0c 		0
192.168.10.4	255.255.255.255 	DHCPACK 	0xe7f6b0c 		6

What's the meaning of the value 6 in the 2nd DHCPACK ?

Although your previous messagges, I'm trying to find an heuristic for  
recognizing dhcp type messagges. I'll keep you in touch :-)

bye

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Thu, 2 Feb 2006 08:23:30 -0500

Thanks Robert ... That's one of those duh moments. 65535 is definitely
what was intended!

- Bernie 

> -----Original Message-----
> From: Robert Elz [mailto:[email-masked]] 
> Sent: Thursday, February 02, 2006 4:58 AM
> To: Bernie Volz (volz)
> Cc: Michele Pedrolli; [email-masked]
> Subject: Re: [dhcwg] 'secs' field 
> 
>     Date:        Wed, 1 Feb 2006 11:11:10 -0500
>     From:        "Bernie Volz \(volz\)" <[email-masked]>
>     Message-ID:  
> <[email-masked]>
> 
> This is kind of off topic, but should ...
> 
>   | In a long since expired draft on DHCPv4 implementation issues,
> 
> that draft ever get revived, it should probably explain ...
> 
> 
>   |            If the client has been 
>   |            waiting longer than 65536 seconds its value 
> SHOULD be 65536.
>   | 
>   |            The value SHOULD NOT wrap around to zero. 
> 
> how the 16 bit field gets set to 65536 without wrapping 
> around to zero?
> What kind of magic encoding is being used here?   (Or perhaps 
> just a very
> heavy assignment statement that will force the value into a hole just
> slightly too small without damaging it too much?)
> 
> (Or perhaps, change all uses of 65536 into 65535...)
> 
> kre
>