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
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
More information about the dhcp-users
mailing list