dhcpd 3.0.6-Fedora with LDAP patch not giving offer

Jason Antman jantman at oit.rutgers.edu
Wed Apr 14 18:52:29 UTC 2010


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:
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: (
    Your (client) IP address: (
    Next server IP address: (
    Relay agent IP address: (
    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

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 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; '
(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.

Jason Antman
Rutgers University

More information about the dhcp-users mailing list