Question about leases

[Darren]

David,
I doubt in this situation that there should be 63 hops from customer to 
DHCP server.  I will check with the ISP, however.  Perhaps there is some 
kind of routing loop.  Or maybe they can make some setting on their 
relay agent as pertains to TTL.

David W. Hankins wrote:

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