PDA

View Full Version : bootpd[201]: NAK sent <no hostname>




Umbre
Jul 29, 2008, 09:36 AM
Hi there,

I'm new to Leopard server (10.5.4) and i'm trying to set up a dhcp service in my network. I followed the doc and many clients are getting an IP, while others get such messages (seen in the history tab of admin server) :

bootpd[201]: dhcp host 1,0:22:24:40:2f:4 sends SELECT with wrong IP address 10.224.229.155, should be 10.224.229.111
bootpd[201]: NAK sent <no hostname> 10.224.229.111 pktsize 300

These IP addresses were inside the sub nets I defined, so I dont see why it says it's a wrong address. I searched the web for explanation about such messages and only fount out that NAK was a non acknowledgement of service by the server.

What I tried to do is to stop and relaunch the service hoping the ip attribution would proceed correctly but I noticed that most clients got this answer to their DHCP request :

ACK sent <no hostname> 10.224.229.94 pktsize 300
or later
OFFER sent <no hostname> 10.224.229.92 pktsize 300

while these clients provided a name along their mac address.

Any idea or help would be appreciated.



corbywan
Jul 29, 2008, 10:33 AM
Is it possible these clients have been manually/statically assigned an IP address on the local machine?

Umbre
Jul 29, 2008, 11:07 AM
The clients are set to get a dhcp lease, locally and nothing is set in the static mapping list in admin server.

corbywan
Jul 29, 2008, 01:22 PM
Do the boxes have another interface you might try, wired or wireless?

Umbre
Jul 30, 2008, 06:24 AM
The boxes ? Do you mean the clients ? They were all getting a fine dhcp attribution under 10.4 Server. They are wired.

corbywan
Jul 30, 2008, 10:56 AM
I'm sorry. I might be totally missing the boat. Not the first time. I thought that this message meant that the clients we not actually getting IP addresses and not working on the network. Are they actually working and this is just a quirky message in the log you are trying to track down?

mrfrosty
Jul 30, 2008, 11:30 AM
It almost reads like the clients are trying to "renew" addresses they already have and the server is NACKING them. Could it be something along those lines.

theyellowdart
Jul 30, 2008, 11:48 AM
It almost reads like the clients are trying to "renew" addresses they already have and the server is NACKING them. Could it be something along those lines.

I was thinking almost the same thing. From it being a possible lease time issue, to even another DHCP server out there jacking everything up.

wrldwzrd89
Jul 30, 2008, 11:53 AM
I was thinking almost the same thing. From it being a possible lease time issue, to even another DHCP server out there jacking everything up.
Something tells me that you have 2 DHCP servers on the same network, which is bound to cause problems. The way I can tell is by looking at the first post in this thread:
ACK sent <no hostname> 10.224.229.94 pktsize 300
or later
OFFER sent <no hostname> 10.224.229.92 pktsize 300
Notice that the two IP addresses are slightly different? This is a sign that they are on the same subnet - for example, one of those two is the Mac OS X Server box, while the other one is a router somewhere.

I've bolded the interesting part of the IP addresses in question for emphasis.

Umbre
Jul 30, 2008, 12:44 PM
In the case of two dhcp servers running, is there a way to verify it ? As far as I now there should not be two.

theyellowdart
Jul 30, 2008, 12:47 PM
In the case of two dhcp servers running, is there a way to verify it ? As far as I now there should not be two.

Disable your current DHCP server (if you can... but you would only need to do it for a short amount of time) and renew (or restart) the IP address on a computer, if it gets an address even after the DHCP is off, there is a second one out there. If it times out and gives itself a self assigned IP, there isn't.

Umbre
Jul 30, 2008, 01:36 PM
LOL it looks like you were right, clients seems to get immediatly an ip that start with 169.254.XXX.XXX.

In theory I should be able to see that other dhcp server with ARD right ?

wrldwzrd89
Jul 30, 2008, 01:36 PM
LOL it looks like you were right, clients seems to get immediatly an ip that start with 169.254.XXX.XXX.

In theory I should be able to see that other dhcp server with ARD right ?
Not if it's a router.

Umbre
Jul 30, 2008, 01:44 PM
It's the router I think, because clients do not get an internet access, only IPs and they are in another subnet (255.255.0.0).

Now the question is, how can I prevent the router from interfering with my dhcp server ?

In that network it was working fine with 10.4 server, but the config was made by someone else.

theyellowdart
Jul 30, 2008, 02:19 PM
LOL it looks like you were right, clients seems to get immediatly an ip that start with 169.254.XXX.XXX.

In theory I should be able to see that other dhcp server with ARD right ?

Nope, 169.254.xxx.xxx IPs are self assigned addresses, not something a DHCP server would normally give (and for it to give it, you (or another network admin) would need to configure it to use 169 addresses). So it's very very unlikely that you have a second DHCP server running.

Umbre
Aug 1, 2008, 04:22 AM
Nope, 169.254.xxx.xxx IPs are self assigned addresses, not something a DHCP server would normally give (and for it to give it, you (or another network admin) would need to configure it to use 169 addresses). So it's very very unlikely that you have a second DHCP server running.

OK fine, so there's no other dhcp distribution.

Now the initial question still remains (see first post). I'm inclined to think as someone mentionned that the dhcp server is trying to renew ips that were already given and is naking them. How to correct this ?

I'm as well bothered with the <no hostname> part in the messages. What could this mean ? There's an internal dns running on the same server.

corbywan
Aug 1, 2008, 08:41 AM
Is there a way to clear the DHCP distribution cache? Maybe that will clear it up.

Umbre
Aug 1, 2008, 11:43 AM
alright just to follow up, the problem solved itself by luck. I restarted, stopped and relaunched the dhcp service, swapped some HD modules, re-installed another server running kerberos (OD master) and suddently it worked.

I am unable to say which of these actions had an influence to solve the problem, but maybe one of them cleared the dhcp distribution cache as you mentionned.

I'd like to thank the people who took time to answer me.

Greetings,