DHCP not working

Question

Level 1

8 points

DHCP not working

I fresh installed Leopard server and although the DHCP service starts up it doesn't seem to work in that it never hands out any IP addresses to any clients. In the log I am seeing errors about a missing 'net_address' field in /etc/bootpd.plist and complaints about it being unable to open /etc/bootptab.

Is anyone seeing similar behaviour with DHCP on a fresh installation, or is DHCP working for you guys?

Message was edited by: Maverick808

MacBook Pro, Mac OS X (10.4.10)

Posted on Oct 31, 2007 3:58 AM

Reply

Answer 1

Nov 2, 2007 7:27 AM in response to Maverick808

Ours works, can you post the logs?

Reply

Answer 2

Maverick808 Author

Level 1

8 points

Nov 2, 2007 7:32 AM in response to Richard Cartledge

Thanks for offering to help. However, I reverted our server to the backup of Tiger I had, and then upgraded to Leopard. When I did this DHCP worked fine. I don't know why it didn't work when I tried a clean install. Anyway, it's working now.

Reply

Answer 3

Nov 3, 2007 6:45 PM in response to Maverick808

I am having the same problem. DHCP is set up and running,
but never replies to DHCP discover requests.

Nov 3 20:42:55 granicus bootpd[25274]: server starting
Nov 3 20:42:55 granicus bootpd[25274]: can't open /etc/bootptab
Nov 3 20:42:55 granicus bootpd[25274]: server name granicus.if.org
Nov 3 20:42:55 granicus bootpd[25274]: interface en0: ip 192.168.13.1 mask 255.255.255.0
Nov 3 20:42:55 granicus bootpd[25274]: interface ppp0: ip 76.250.126.94 mask 255.0.0.0
Nov 3 20:42:55 granicus bootpd[25274]: interface ppp0: ip 76.250.126.82 mask 255.255.255.240
Nov 3 20:42:55 granicus bootpd[25274]: subnets: create failed, Invalid/missing 'net_address' property
Nov 3 20:42:57 granicus bootpd[25274]: DHCP DISCOVER [en0]: 1,0:16:cb:ce:94:40 <arbela>
Nov 3 20:42:57 granicus bootpd[25274]: service time 0.001375 seconds
Nov 3 20:42:59 granicus bootpd[25274]: DHCP DISCOVER [en0]: 1,0:16:cb:ce:94:40 <arbela>
Nov 3 20:42:59 granicus bootpd[25274]: service time 0.000298 seconds

I have a subnet defined on en0 in the Server Admin gui, but that seems to be insufficient.

Reply

Answer 4

AndyGUK

Level 1

0 points

Nov 4, 2007 3:59 AM in response to Nathan Wagner

I have this problem too......

DHCP server responds OK to other Mac (leopard) clients but not to non-apple stuff.

I suspect its a setting in bootpd.plist ....I've tried using the one from my previous tiger setup but that doesn't work on leopard either.

Reply

Answer 5

Maverick808 Author

Level 1

8 points

Nov 4, 2007 4:07 AM in response to AndyGUK

In case it's helpful, here's a copy of my bootpd.plist. My DHCP worked after I upgraded from Tiger, but didn't work with a clean install of Leopard. This is the version that works, handing out IPs to OS X, Windows, and other OSs fine.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>NetBoot</key>
<dict/>
<key>Subnets</key>
<array>
<dict>
<key>allocate</key>
<true/>
<key>dhcp domainname</key>
<string>tanza</string>
<key>dhcp domain_nameserver</key>
<array>
<string>192.168.1.2</string>
<string>192.168.1.1</string>
</array>
<key>dhcp ldapurl</key>
<array>
<string>ldap://denal.tanza/cn=users,dc=denali,dc=tanza</string>
</array>
<key>dhcp_router</key>
<string>192.168.1.1</string>
<key>lease_max</key>
<integer>3600</integer>
<key>lease_min</key>
<integer>3600</integer>
<key>lease timesecs</key>
<string>3600</string>
<key>name</key>
<string>tanza</string>
<key>net_address</key>
<string>192.168.1.0</string>
<key>net_mask</key>
<string>255.255.255.0</string>
<key>net_range</key>
<array>
<string>192.168.1.3</string>
<string>192.168.1.99</string>
</array>
<key>selected portname</key>
<string>en0</string>
<key>uuid</key>
<string>12E40AA1-93F9-407C-9538-4BD5DBA19C2D</string>
</dict>
</array>
<key>dhcp_enabled</key>
<true/>
<key>timeDatabaseUpdated</key>
<string>2007-10-31 20:11:04 +0000</string>
<key>timeServiceStarted</key>
<string>2007-10-31 22:18:54 +0000</string>
</dict>
</plist>

Reply

Answer 6

AndyGUK

Level 1

0 points

Nov 4, 2007 5:51 AM in response to Maverick808

With a little bit of judicious editing I've got it working........

Thanks very much.

Not sure which line in particular fixed it I suspect that the section

<key>net_address</key>
<string>192.168.1.0</string>

is important.....it was missing from both the default file and the one I copied form tiger server....there doesn't appear to be an entry in Server Admin for the network address and the address doesn't seem to get created in bootpd.plist, I'll investigate more but at least its working now.

Thanks again

Message was edited by: AndyGUK

Reply

Answer 7

Maverick808 Author

Level 1

8 points

Nov 4, 2007 5:55 AM in response to AndyGUK

Glad to hear it worked.

I do think this is a pretty massive bug. When I done a clean install the net_address was also missing. I had tried to add it manually but couldn't get it working, and only upgrading from Tiger solved the issue.

Clearly, something is very wrong with Leopard's default DHCP set up/creation.

Reply

Answer 8

Nov 4, 2007 8:53 PM in response to AndyGUK

Adding in the two items you pointed out fixed the problem for
me. After those two changes and then restarting dhcp, the error
went away, and it started answering DHCP requests.
It appears to be at least slightly resistant to being
over-written by the server admin gui as I have made some
other changes and it still works.

Reply

Answer 9

Nov 5, 2007 6:23 PM in response to AndyGUK

My /etc/bootpd.plist already has the
<key>net_address</key>
<string>192.168.1.0</string>
section, but dhcp still has the same symptoms as described earlier in this topic. Here is a readout of my log...

Nov 5 21:17:49 mini bootpd[12737]: server starting
Nov 5 21:17:49 mini bootpd[12737]: can't open /etc/bootptab
Nov 5 21:17:49 mini bootpd[12737]: server name mini.white-com.com
Nov 5 21:17:49 mini bootpd[12737]: interface en0: ip 192.168.1.8 mask 255.255.255.0
Nov 5 21:17:51 mini bootpd[12737]: DHCP DISCOVER [en0]: 1,0:12:5a:76:a:a9 <xbox>
Nov 5 21:17:51 mini bootpd[12737]: service time 0.004101 seconds
Nov 5 21:17:53 mini bootpd[12737]: DHCP DISCOVER [en0]: 1,0:12:5a:76:a:a9 <xbox>
Nov 5 21:17:53 mini bootpd[12737]: service time 0.000719 seconds
Nov 5 21:17:55 mini bootpd[12737]: DHCP DISCOVER [en0]: 1,0:12:5a:76:a:a9 <xbox>
Nov 5 21:17:55 mini bootpd[12737]: service time 0.000706 seconds
Nov 5 21:18:01 mini bootpd[12737]: DHCP DISCOVER [en0]: 1,0:12:5a:76:a:a9 <xbox>
Nov 5 21:18:01 mini bootpd[12737]: service time 0.000710 seconds
Nov 5 21:18:03 mini bootpd[12737]: DHCP DISCOVER [en0]: 1,0:12:5a:76:a:a9 <xbox>
Nov 5 21:18:03 mini bootpd[12737]: service time 0.000757 seconds
Nov 5 21:18:05 mini bootpd[12737]: DHCP DISCOVER [en0]: 1,0:12:5a:76:a:a9 <xbox>
Nov 5 21:18:05 mini bootpd[12737]: service time 0.000704 seconds

Anyone have any suggestions?

~A

Reply

Answer 10

greyman

Level 1

9 points

Nov 6, 2007 8:35 AM in response to Maverick808

I had this same issue when I had defined more than one subnet for the dhcp server. If this is the case then make sure you have a net_address line for the other subnets. (each one has to have one). In my case I have a three legged firewall that I use one class C across both internal interfaces.
interface 1: 192.168.x.0/25 (net_address 192.168.x.0)
interface 2: 192.168.x.128/25 (net_address 192.168.x.128)

Once I did this it started up correctly just need to get my pfSense dhcp-relay to work.

Reply

Answer 11

Nov 8, 2007 2:35 PM in response to whitecom1

For some reason, the default DHCP installation on Leopard sets replythresholdseconds to 10 in /etc/bootpd.plist, so it ignores packets from machines that are sending them in intervals less than that. Try changing it to 0 and stopping and restarting DHCP.

Reply

Answer 12

Nov 12, 2007 3:06 PM in response to Maverick808

my DHCP is also not working. after messing around with it for quite some time last Friday i was finally able to get it to run by rerunning the set-up assistant.

all was fine and good and everyone got an address. great.

monday... everyone has an address still. except 2 people. including myself. and the log is back and filled with the same :

Nov 12 13:59:00 dropbox bootpd[172]: DHCP DISCOVER [en0]: 1,0:19:e3:d4:3c:4f <RonnieMBP>
Nov 12 13:59:00 dropbox bootpd[172]: service time 0.000323 seconds
Nov 12 13:59:01 dropbox bootpd[172]: DHCP REQUEST [en1]: 1,0:19:e3:4:7c:d6 <23>
Nov 12 13:59:01 dropbox bootpd[172]: service time 0.000657 seconds
Nov 12 13:59:01 dropbox bootpd[172]: DHCP REQUEST [en0]: 1,0:19:e3:4:7c:d6 <23>
Nov 12 13:59:01 dropbox bootpd[172]: service time 0.000471 seconds
Nov 12 13:59:01 dropbox bootpd[172]: DHCP REQUEST [en1]: 1,0:19:e3:d4:3c:4f <RonnieMBP>
Nov 12 13:59:01 dropbox bootpd[172]: service time 0.002615 seconds
Nov 12 13:59:01 dropbox bootpd[172]: DHCP REQUEST [en0]: 1,0:19:e3:d4:3c:4f <RonnieMBP>
Nov 12 13:59:01 dropbox bootpd[172]: service time 0.000458 seconds
Nov 12 13:59:02 dropbox bootpd[172]: DHCP REQUEST [en1]: 1,0:19:e3:d4:3c:4f <RonnieMBP>
Nov 12 13:59:02 dropbox bootpd[172]: service time 0.001606 seconds
Nov 12 13:59:02 dropbox bootpd[172]: DHCP REQUEST [en0]: 1,0:19:e3:d4:3c:4f <RonnieMBP>
Nov 12 13:59:02 dropbox bootpd[172]: service time 0.001136 seconds

that i was having last week. NOTHING changed between then and now. this is quite annoying... my 10.4 DHCP worked fine for ages. between this and the Software Update issue i am less likely to rush and update my other 3 Xserves.

i tried the "reply thresholdseconds" set to 0 fix... stopping/starting the DHCP server... but that made no change. still not giving those 2 machines an address.

any other suggestions?

thanks.

Reply

Answer 13

Nov 12, 2007 3:24 PM in response to Bryce Polly

beesleep wrote:
i tried the "reply thresholdseconds" set to 0 fix... stopping/starting the DHCP server... but that made no change. still not giving those 2 machines an address.

any other suggestions?

Hmm, I had a couple of machines that had to be rebooted before my server would serve them DHCP because they previously had DHCP leases from another server (which I had shutdown a few minutes before).

If you're comfortable at the command line, you could turn off DHCP via Server Admin, then become root in a terminal window and run "/usr/libexec/bootpd -v -d" This will startup bootpd in debug mode and you should see some reason given when it decides not to respond to DHCP requests. Once you have enough information, hit control C to stop it, then you can use Server Admin to turn it back on.

Reply

Answer 14

Nov 12, 2007 5:14 PM in response to Dean Huxley

i rebooted my personal machine and it got an address and was fine. then a few other leases expired on other peoples machines... and they never got new addresses.

reboot did not help them.

i now have a self-assigned once again as well. reboot didn't help me this time either.

starting DHCP in debug mode i see no useful information as to why the requests are failing. i see requests come in... and nothing happens. no address given out. or a reason for no address given out.

---------------- Client Request --------------------
op = BOOTREQUEST
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 435380279
secs = 50
ciaddr = 0.0.0.0
yiaddr = 0.0.0.0
siaddr = 0.0.0.0
giaddr = 0.0.0.0
chaddr = 0:a:95:b1:cc:8
sname =
file =
options:
Options count is 7
dhcp messagetype (uint8): DISCOVER 0x1
parameter requestlist (uint8_mult): {0x1, 0x3, 0x6, 0xf, 0x77, 0x5f, 0xfc, 0x2c, 0x2e, 0x2f}
max dhcp_messagesize (uint16): 0x5dc
client_identifier (uint8_mult): {0x1, 0x0, 0xa, 0x95, 0xb1, 0xcc, 0x8}
lease_time (uint32): 0x76a700
host_name (string): Ross-Coen
end (none):
bootpd[605]: service time 0.065885 seconds
destination address 255.255.255.255

then imagine that every 2 seconds or so from the new 3 client machines that can no longer get an address.

this is exceedingly frustrating. "No IT Department Required!" HAHAHAHAHAHAHA.

Reply

Answer 15

jeff_b

Level 1

0 points

Nov 13, 2007 11:19 PM in response to Dean Huxley

Setting replythresholdseconds to 0 fixed the issue for me. I was having trouble on my Xbox 360 and Dish network receiver. Thanks.

Reply