The error message that appears in the connection logs on the Meraki dashboard portal, “Client made a request to the DHCP server, but it did not respond,” is a rather general one and does not provide much detailed information. However, it does indicate that the DHCP server sent a negative acknowledgment (NACK) to the client in response to the request. you can see the that Meraki logs show the “dhcp_nack”
A little bit about the DHCP Nack and DHCP protocol.
The Dynamic Host Configuration Protocol (DHCP) is used to assign IP addresses and other network configuration parameters to devices on a network. When a DHCP server receives a request from a client for an IP address, it may send a negative acknowledgment (NACK) message back to the client to indicate that it cannot fulfill the request.
DHCP may send a NACK message for several reasons, including:
- IP address conflict: If the DHCP server detects that the requested IP address is already in use by another device on the network, it will send a NACK message to the requesting client to indicate that the address is unavailable.
2. Invalid request: If the DHCP server receives an invalid request, it will send a NACK message to the client to indicate that the request cannot be processed.
3. Timeouts: If the DHCP server does not receive a response from the client within a certain period of time, it may assume that the client is no longer active or has moved to a different network segment. In this case, the server may send a NACK message to the client to indicate that the address lease has been revoked.
Overall, the NACK message is used to inform the client that its request cannot be fulfilled, allowing the client to take appropriate action and make another request.
Although every environment is unique, the initial step would be to capture traffic within the Meraki dashboard portal.
Log into the Meraki Dashboard and navigate to Network-wide – Monitor and packet capture
Ensure that the interface is configured for wired connections and adjust the duration accordingly. It is possible to extend the duration for packet capture, with a maximum limit of 3600 seconds or 100 K packets.
Once the capture stops, open the file with Wireshark to analyze the DHCP communications to the client, if you are lucky you may capture the communications with the bad client and DHCP sending the NACK.
Once you see the NACK in the Wireshark, you can then determine more info on why DHCP is rejecting the client request. could be one of the three reasons mentioned above.
The issue we found was that client was roaming from one subnet to another subnet and the lease was more than a day, the client would request an IP when roaming to the different subnet access points and DHCP would reject it since it shows that you have an IP from the different subnet already
The solution is only valid if you have access points on different subnets and using an external DHCP server and be applied per SSID
Login into the Meraki Dashboard and go to SSID and choose the SSID and choose “edit settings”, go down to “client IP and VLAN” and check the “Layer 3 roaming” box, this will create a tunnel between access points and let the client use the same IP.
You can also do more captures on the DHCP server itself by using WireShark and that will also give you the rejects with more details.