dhcpd 3.0.6-Fedora with LDAP patch not giving offer

Sat Apr 17 02:22:52 UTC 2010

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
>