Question about leases

[David W. Hankins]

On Mon, Apr 17, 2006 at 01:24:50PM -0400, Darren wrote:
> I have forwarded the packet captures from the ISP to dhcp-bugs at isc.org

Interesting.

The IP TTL of your OFFERs is 1 in the 'dlinkathouse' trace.  I think the
DLink is receiving the packet, decrementing the TTL, and then finding
that to be zero and discarding it (hopefully without emitting an ICMP
packet since it has no address yet).

The server-side trace is showing a TTL of 64, and since this is a unicast
message to a relay agent, I suspect that's being set by your operating
system.  The only default we use for IP TTL is 16, and that's for
messages we craft by hand (via BPF or similar - for local broadcast).

Unicasts out of dhcpd are always sent using a normal BSD socket, like any
other application, and we don't set any sockopt or fcntl or similar to
my knowledge...so this should be an OS setting.

I think the Linux default IP ttl is 64.  Have a look at:

	sysctl net.ipv4.ip_default_ttl


But do you really have 63 router hops inbetween this DLink and your
DHCP server?  I suspect probably so...your Linksys trace shows a ttl
reaching the servers of 150, and I think they start out with something
in the 200s (to be Windows identical...I can't remember the precise
number).

But...that's quite a lot of hops.

Suggest you attempt to find ways to increase the ttl coming out of the
DHCP servers to see if they arrive at the client end with greater than
1 ttl remaining.  That might fix the problem, but this assumes that
the relay agent uses the TTL supplied by the packet it received (may
not be the case if it regenerates everything UDP and lower).

If it "sometimes works sometimes doesn't" perhaps the difference is
that the router topology changes from something pessimal to something
not quite so pessimal.

It would also explain the chain of DISCOVERs before the 'dlinkathome'
trace started seeing OFFERs...one more hop and you'd start getting ICMP
ttl exceeds.  So the topology changed inbetween so that the packet is
sent on the local wire but is being dropped by the Dlink.

But the rub of all this is that the D-Link is using an IP TTL of 30
when it transmits its DISCOVERs.  If the relay agent is just passing
on the source packet TTLs, then it should not be reaching the DHCP
servers!  Unless they take different paths...


That's my best guess, anyway.

Thanks for sharing the packet traces.  It's really interesting to me
to look at different dhcp client implementations.

And you're right, they're doing just downright silly things with
the 'secs' field.  I can't figure it, it doesn't look like microseconds
or clock ticks or anything (16 seconds is ~4,000 wotsits?).  It also
looks like they choose a random xid and then increment it by one in
client integer byte order.  That's also curious to me.  Not clearly
against documented use, but curious for the purpose of maybe using
the xid for more strenuous duplicate-detection (so you can filter out
two packets from two relays and only answer once).

-- 
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