Possible DHCP bug with sending ping after ACK

David W. Hankins David_Hankins at isc.org
Wed Dec 3 20:41:30 UTC 2008

On Tue, Dec 02, 2008 at 03:13:21PM -0800, Shaun Louie wrote:
> The solution to this problem might be finding out why the OFFER doesn't 
> wait for the ping timeout.  This might be an easy fix for someone that's 
> more familiar with the code than I am.

4.0 uses 3's old timing system, which was granular to 1s.  The DHCPv6
spec suggests (but never mandates) granularity to 0.01s I think, so in
4.1 we moved to track microseconds.

Load your wireshark capture, and switch the 'Time' format from
'seconds since the capture started' to 'seconds since epoch.'

Now note that the DHCPDISCOVER came in at blah.8 seconds, and the
OFFER was sent at blah.0 + 1.0 seconds.  This is because of the timer
granularity; the server is using a default 1-s ICMP echo timeout, but
you will actually only get a random number between 0 and 1 second,
non inclusive, depending on when the client's DISCOVER was received
and (this is the important part) processed.

I can't speculate on why the ICMP echo is being sent 0.3 seconds after
the DHCPDISCOVER.  I'm not aware of any queues internal to dhcpd that
could possibly account for that, I think we write that packet
immediately without any blocking, and it's impossible for me to
speculate what, outside of dhcpd, could be at work.

The easy solution would be to upgrade to 4.1.0.

Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-workers/attachments/20081203/b38419f1/attachment.bin>

More information about the dhcp-workers mailing list