18

I have a remote client machine that is sending out DHCPDISCOVER's. The server is responding with a DHCPOFFER, but there is no DHCPACK.

This repeats about every 30 seconds from the same host. Is there something I can do remotely or do I need to get someone to reboot it? It's in a data centre so I may have to travel there to do it!

Thanks for the suggestions. I've had all the machines rebooted, but I still have issues. I think there is an issue with my configuration. Does this look correct?

#
# /etc/dhcpd.conf for primary DHCP server
#

authoritative;
ddns-update-style none;
deny duplicates;
default-lease-time 600;
max-lease-time 3600;

# Our fixed hosts
host host2  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.202; }
host host3  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.203; }
host host4  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.204; }
host host5  { hardware ethernet xx:xx:xx:xx:xx:xx; fixed-address x.x.x.205; }

subnet x.x.x.128 netmask 255.255.255.128 {
  option subnet-mask 255.255.255.128;
  option broadcast-address x.x.x.255;
  option routers x.x.x.129;
  option domain-name-servers 8.8.8.8, 8.8.4.4;

  # Testing pool.
  pool {
    max-lease-time 300; # 5 minutes
    range x.x.x.250 x.x.x.254;
    deny known-clients;
  }

  # Our hosts - I didn't have this pool declaration before, do I need it if I want
  # the hosts to be running dhcp but always get the same address?
  pool {
    max-lease-time 1800;
    range x.x.x.200 x.x.x.220;
    deny unknown-clients;
  }
}
hookenz
  • 14,132
  • 22
  • 86
  • 142
  • DHCPRequest should come before the DHCPAck. Are you seeing that? Try running a packet capture on the server and look for the DHCPDiscover, DHCPOffer, DHCPRequest and DHCPAck to and from the server. Is the client on the same LAN segment as the server? If not, is the router separating the two configured as a DHCP relay? – joeqwerty Jan 26 '13 at 18:27
  • It turned out the problem was due to a misconfiguration. I had a static range overlapping a dynamic range. – hookenz May 13 '15 at 20:16

6 Answers6

16

It goes:

CLIENT -> DHCPDISCOVER
SERVER -> DHCPOFFER
CLIENT -> DHCPREQUEST
SERVER -> DHCPACK

You you are missing the DHCPREQUEST before the DHCPACK in your description.

If the client is on a different subnet than the DHCP server the DHCPOFFER is sent unicast to the DHCP-relay on port 67 UDP. The DHCP-relay agent broadcasts the DHCPOFFER to the subnet on UDP port 68.

I'd investigate connectivity issues related to the DHCPOFFER. Track it and see if it finds its way back to the client and if it does, why is the client not DHCPREQUEST:ing the address.

A common dhcp relay agent is the "ip helper-address" option in cisco switches under a specific interface.

artifex
  • 1,634
  • 1
  • 17
  • 22
12

Supposing your DHCP-server and DHCP-client are both connected to the same ethernet segment, and supposing such ethernet segment spans several L2-switches interconnected with various "trunk" (802.1q) links, I've run into similar issues when there was a mismatch between the configuration of at least one trunk link.

In detail, the never-ending cycle of DHCP-DISCOVER / DHCP-OFFER (as seen from the DHCP-server side), let me think that the DHCP-client is NOT receiving the DHCP-OFFER and, hence, stick reissuing the DHCP-DISCOVER message. Such DHCP-DISCOVER (as seen from the DHCP-client side) is correctly received from the DHCP-SERVER.

Considering the following scenario: enter image description here the wrong/mismatched setup of the two trunk ports means that:

  • VLAN X traffic sent by SW A to SW B along the trunk (or from the DHCP-Server to the DHCP-client), is UNTAGGED;
  • VLAN X traffic sent by SW B to SW A along the trunk (or from the DHCP-Client to the DHCP-server), is TAGGED.
  • due to the native VLAN setup of the trunk port of SW B, the DHCP-Client will not receive packets from DHCP-Server.

This is very easy to troubleshoot, if you "control" the DHCP-Client host. In such a case, supposing eth0 is the network interface used by the DHCP-client host, a simple:

tcpdump -n -i eth0 ether-host <dhcp-server-mac-address>

will show if the client receive the DHCP-OFFER from the DHCP-SERVER, or not.

Things are more difficult to troubleshoot if you can not control the client-side.

P.S.: Obviously problems above, as well as other related arguments, can be easily avoided used proper technologies (like GVRP, VTP or other not-strictly-manual-config-approach) but... this is out of the scope of this answer

Damiano Verzulli
  • 3,948
  • 1
  • 20
  • 30
  • It would appear that this can also happen as a result of a software bug in the DHCP server, when the server-side interface is bridged across different VLANs. – DustWolf Jun 24 '17 at 22:15
6

Had the same issue. Not seeing any DHCPACKs. Problem here was:

disk full

dhcpd could not write to /var/lib/dhcp/dhcpd.leases.

1977er
  • 69
  • 1
  • 2
  • Many thanks. I was seeing discover, offer, request, request, request and no ack and this was the cause. There was nothing in /var/log/syslog either, for the same reason. It's about time I learned to check this first when I see strange behaviour that starts suddenly. – Rob Fisher Apr 03 '15 at 00:00
3

I've seen this a few times and so far I've seen only two reasons:

  • The IP address the DHCP server gave is already in use by another device. Usually you'd see a DHCPNAK though.
  • Your firewall is accepting the traffic to the dhcp server, but not the traffic back

Fortunately both should be easy to test. Ping the IP address and check relevant firewalls.

Dennis Kaarsemaker
  • 18,793
  • 2
  • 43
  • 69
  • Thanks. I pinged the address offered but no response. I then set up a host entry for it forcing it to offer a different address but this didn't seem to help. Will check the firewall. – hookenz Jan 26 '13 at 19:21
0

I've been learning about firewalls using virtual box and I had a similar issue not getting the DHCPACK on the server and it turned out that was using the wrong virtual box network settings for the test green (internal) network for a ubuntu firewall vm and a test ubuntu client vm. If you use the NAT network rather than vb internal network the client vm gets its ip from vb rather than the DHCP server vm. The logs show the server getting the request from the client but the client gets its ip from vb instead so you never get an ACK sent back to the server.

Mark Simmons
  • 1
  • 1
0

For me it was a simple of case of forgetting to turn off the DHCP server (via Internet Sharing) on the client. As soon as I turned that off, the DHCP lease was accepted:

Apr 16 03:54:18 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:54:18 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:54:26 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:54:26 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:34 dnsmasq-dhcp[5952]: DHCPDISCOVER(eth0) 40:6c:8f:59:24:8e
Apr 16 03:55:34 dnsmasq-dhcp[5952]: DHCPOFFER(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:35 dnsmasq-dhcp[5952]: DHCPREQUEST(eth0) 10.0.0.4 40:6c:8f:59:24:8e
Apr 16 03:55:35 dnsmasq-dhcp[5952]: DHCPACK(eth0) 10.0.0.4 40:6c:8f:59:24:8e Heaths-MBP
Heath Raftery
  • 101
  • 1