I sent a message to the leaf-devel list a few days back about this issue, but didn't get any replies. Any developer willing to recompile dhclient with this TTL hack (one line of code)?
I tried compiling ISC's dhcp-2.0pl5 on a RedHat 5.2 box today - compiled okay and executed okay on my LRP box, but I get "send_packet" errors when trying to send DHCPDISCOVERS to eth0. The stock dhclient-2.0pl5 in the Dachstein 1.0.2 image doesn't give these errors, so its driving me mad. :-( Since its driving me crazy, I was hoping someone who actually knew what they're doing (not me) could recompile. I know there must be others out there who have encountered this issue. ------- Forwarded message follows ------- From: Ethan Galstad <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: DHCP Client TTL Problem - AT&T Broadband Date sent: Sat, 22 Jun 2002 19:08:40 -0500 There is a problem with the ISC's DHCP client (including all LRP version) with the TTL being hardcoded to 16. This started giving me (and others) problems last Monday when AT&T broadband "upgraded" their systems in the St. Paul/Minneapolis area. Turns out that now the DHCP server is (no joke) 18 hops away from me. Since the DHCP client sets the DHCPDISCOVER packet TTL to 16, the message never gets to the server. The "fix" is to hack the ISCP DHCP source code and use a larger value (i.e. 128) in the TTL field. AFAIK, the Microsoft DHCP client uses a value of 128 in the TTL field. The message below was sent by Paul Dokas where he outlines how to do this. Can someone make an updated dhclient package with this change incorporated? FWIW, I'm running the Dachstein 1.0.2 distribution. My home network is useless without it. :-( PS: I found a newsgroup message outlining the same problem and fix, so I know there are others out there who are having similar problems. Here's the Google URL: http://groups.google.com/groups?selm=c91381b2.0206210920.269f9e1b%40po stin g.google.com ------- Forwarded message follows ------- [snip] Found the problem. The ISC DHCP client sets the TTL on the DHCP request to 16, which is apparently too low for AT&T's network. This would explain why it works for some people and not other on an apparently random basis. I edited line 159 of common/packet.c in the ISC DHCP source code. It used to be: ip.ip_ttl = 16; and I changed it to be: ip.ip_ttl = 128; And, now I get a lease almost immediately after running dhclient. So, I guess that AT&T's DHCP servers are just fine (I don't need to set any strange options in dhclient.conf). The "problem" is that the Internet, or at least AT&T's broadband network, has grown larger than what the source code assumes to be a *big* network. I'll send in a bug report to ISC first thing in the morning. Paul ------- End of forwarded message ------- Ethan Galstad, Nagios Developer --- Email: [EMAIL PROTECTED] Website: http://www.nagios.org ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
