dhcpd 3.0.6-Fedora with LDAP patch not giving offer
Jason Antman
jantman at oit.rutgers.edu
Sat Apr 17 14:32:17 UTC 2010
Matt,
I'm aware that it's a bit old, but aside from these particular clients,
it's been running quite well for a few years, is considered stable by
us, etc. The dhcpd.conf is about five lines long - LDAP server, bind DN,
password, port, etc. *all* configuration is in LDAP.
I'm relatively sure I've found the problem, though I won't know for
certain until I get back in the office on Tuesday. It appears that the
Etherboot client (as used by Xen) never updates the value of the 'secs'
field in the DHCPDISCOVER. i.e. even on a 7th DISCOVER packet, the
'secs' field is set to 0. We used to have a less elegant failover DHCP
server setup, which relied on the servers using 'min-secs' in the subnet
declarations. I've written a small Perl script to inject manually
crafted DHCP packets onto the wire, crafted one identical to the
captured packets from the problem host, and sure enough, any value of
"secs" >=2 fixes the problem.
Hopefully that is, in fact, the problem (and it's a bug with Etherboot,
no fault of dhcpd).
Thanks for the tips, I'll keep you posted,
Jason
PS - No, I haven't tried to run a config without the LDAP patch... we
serve DHCP for about 300 subnets and ~3,000 static clients (another ~5k
dynamic clients). I'm not moving all of that from LDAP to a dhcpd.conf....
Matt Causey wrote:
> Folks 'round here will tell you that is a very old version of dhcpd.
> But I don't know of any specific reasons not to use it in production.
> Upgrading might not be a bad troubleshooting step though.
>
> Option 60 is just a client option telling the server some information
> about the dhcp client. I'd be surprised if that was causing you
> problems - unless you have a vendor class excluding Etherboot-5.4.
> :-)
>
> For me, it's hard to just look at a dhcpdiscover and know what the
> problem is. Would you be able to post your dhcpd.conf (I actually
> don't know which parts are stored in LDAP and which in the config
> file...)? Can you give an idea of the network topology between the
> client and server? Are there any dhcp relay agents involved (such as
> Cisco ip helper)? Finally, I wouldn't mind taking a look at a pcap
> file with a few of the dhcpdiscover messages from the problematic
> client(s).
>
> Also - have you run this config successfully without the ldap patch
> added and configured?
>
> --
> Matt
>
>
> On Wed, Apr 14, 2010 at 11:52 AM, Jason Antman <jantman at oit.rutgers.edu> wrote:
>
>> Hello,
>>
>> I'm running dhcpd 3.0.6-Fedora with Brian Masney's LDAP patch. We have a
>> few clients which are sending a discover, the LDAP search is finding the
>> entry, the LDAP patch is printing out it's debugging "sending the
>> following options:" message, and then no offer. I've been doing packet
>> captures and log analysis until my eyes glaze over, and I can't seem to
>> find any common factor (changed the host's LDAP entry to a different
>> subnet, switched interfaces on the host, etc.) other than these specific
>> hosts' DISCOVER packet looks a bit different. dhcpd is logging the
>> discover received, the LDAP logging is correct, but there's no OFFER
>> (either on the wire *or* in the dhcpd logs). There are no "no free
>> leases" messages, or anything else that would explain why dhcpd isn't
>> sending the offer.
>>
>> Are there any known situations where, due to options in (or omitted
>> from) the discover packet, dhcpd would silently not send an offer?
>>
>> The client is a Xen VM, running Etherboot 5.4.
>>
>> The discover packets that I'm seeing look as follows:
>> =======BEGIN WIRESHARK SNIPPET=======
>> User Datagram Protocol, Src Port: bootps (67), Dst Port: bootps (67)
>> Source port: bootps (67)
>> Destination port: bootps (67)
>> Length: 556
>> Checksum: 0x84d8 [validation disabled]
>> [Good Checksum: False]
>> [Bad Checksum: False]
>> Bootstrap Protocol
>> Message type: Boot Request (1)
>> Hardware type: Ethernet
>> Hardware address length: 6
>> Hops: 1
>> Transaction ID: 0x3e19e7a0
>> Seconds elapsed: 0
>> Bootp flags: 0x0000 (Unicast)
>> 0... .... .... .... = Broadcast flag: Unicast
>> .000 0000 0000 0000 = Reserved flags: 0x0000
>> Client IP address: 0.0.0.0 (0.0.0.0)
>> Your (client) IP address: 0.0.0.0 (0.0.0.0)
>> Next server IP address: 0.0.0.0 (0.0.0.0)
>> Relay agent IP address: 172.16.58.65 (172.16.58.65)
>> Client MAC address: Xensourc_0c:cf:08 (00:16:3e:0c:cf:08)
>> Client hardware address padding: 00000000000000000000
>> Server host name not given
>> Boot file name not given
>> Magic cookie: (OK)
>> Option: (t=53,l=1) DHCP Message Type = DHCP Discover
>> Option: (53) DHCP Message Type
>> Length: 1
>> Value: 01
>> Option: (t=57,l=2) Maximum DHCP Message Size = 1500
>> Option: (57) Maximum DHCP Message Size
>> Length: 2
>> Value: 05DC
>> Option: (t=60,l=13) Vendor class identifier = "Etherboot-5.4"
>> Option: (60) Vendor class identifier
>> Length: 13
>> Value: 4574686572626F6F742D352E34
>> Option: (t=55,l=4) Parameter Request List
>> Option: (55) Parameter Request List
>> Length: 4
>> Value: 01030C2B
>> 1 = Subnet Mask
>> 3 = Router
>> 12 = Host Name
>> 43 = Vendor-Specific Information
>> Option: (t=150,l=11) TFTP server address
>> Option: (150) TFTP server address
>> Length: 11
>> Value: AF050110EC8139B1020300
>> End Option
>> Padding
>> =======END WIRESHARK SNIPPET=========
>>
>> The two things that jump out at me are option 57 and option 60, which
>> none of the other clients specify. I'm also a bit perplexed by the short
>> list in option 55.
>>
>> The log messages I'm seeing (with Masney's LDAP patch) are an exact
>> repitition (minus timestamp changes) of:
>>
>> Apr 12 10:20:28 servername dhcpd: DHCPDISCOVER from 00:16:3e:0c:cf:08
>> via 172.16.25.97: 0 secs < 2
>> Apr 12 10:20:36 servername dhcpd: Searching for
>> (&(objectClass=dhcpHost)(dhcpHWAddress=ethernet 00:16:3e:0c:cf:08)) in
>> LDAP tree cn=DHCP Service Config,ou=Host Config,o=foo,c=US
>> Apr 12 10:20:36 servername dhcpd: Sending the following options:
>> 'fixed-address 172.16.25.117; '
>> (and then that's it)
>>
>> Any suggestions? Are the any known reasons why dhcpd would receive the
>> discover and not send an offer, without logging anything?
>>
>> I'm sorry if this has been covered before... I couldn't find anything in
>> the archives and am starting to beat my head against the wall.
>>
>> Thanks,
>> Jason Antman
>> Rutgers University
>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
More information about the dhcp-users
mailing list