Client made a request to the DHCP server, but it did not respond

[MartynB]

Hi,

I've researched this issue and so far haven't found a similar case, so I've signed up to ask for some advice

I have an MR36 running 27.7.1 connected to an MS250-48LP running in test as a PoC for a network wide roll out

I have a Guest SSID distibuting it's own DHCP, and a Production SSID configured to use the local LAN DHCP server.

In the production SSID, I'm getting the DHCP error in the subject, however, clients are getting a valid IP address from the server, with the correct gateway etc, and a lease visible in the DHCP lease list on the Windows server. However the client claims there is no internet access

The MS250 is currently configured to block rogue DHCP servers but specifically allow the DHCP server in question, it's worth noting that client devices connected to the switch via copper are getting addresses and connecting out without issue, there is no L3 configured on this network

Any suggestions of where to look would be a great help, thanks in advance

[Bettencourt]

If you run a packet capture on the wired interface of the AP on which the client is connected, do you see the full DORA exchange as a client tries to associate with the network?

It's been a while since my windows days, I assume it should only populate the lease table after the Ack back from the endpoint?

On the client itself, do you see the entire IP assignment configured as expected, IP, mask, gateway, VLAN? 

Does the communication only not work if going towards the internet?

Are you able to ping the gateway?
Could you have some L3 block, possibly a missing return route upstream of the MS?

Are the wired clients on the same VLAN as the wireless clients?

[Bettencourt]

Ughhhhh.. meant after the ACK is sent by the server, not the client.

[PhilipDAth]

I would start up upgrading to the stable firmware version.  You might be fighting issues that no longer exist.

You are a major version out of date.

[BlakeRichardson]

Is your client device set to pick DNS using DHCP as well or is it manually assigned?  If you try manually setting DNS severs does the error go away? 

[MartynB]

Thanks for the suggestions guys, I'm out of office this week until Friday, so will pick up with your ideas and report back then

[DavidBuckner]

Have you checked the L3 rule under Wireless ->> Firewall and Traffic shaping? I have seen that rule block traffic going to the servers on the LAN.  Change that deny to allow and see if that fixes it.

[MartynB]

Hi Guys, I've managed to put some time aside for this, and to answer some of the questions above, there is no Layer 3 happening on this network currently everything is on default VLAN 1, the Local LAN rule is set to allow, the client gets a valid address but can't ping the gateway, let alone the internet, and there are numerous other AP's with the same config on the same firmware functioning in other businesses under the same corporate ownership. The following packet capture shows the DHCP exchange from the server at x.x.x.2:

--- Start Of Stream ---
reading from file /tmp/click_pcap_dump, link-type EN10MB (Ethernet), snapshot length 9600
14:06:47.108066 IP x.x.x.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 307
14:06:48.607392 ARP, Request who-has x.x.x.87 tell x.x.x.2, length 46
14:06:50.094866 IP x.x.x.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 313
14:06:50.121799 ARP, Request who-has x.x.x.2 tell x.x.x.222, length 46
14:06:50.122399 ARP, Reply x.x.x.2 is-at xx:xx:xx:xx:xx:xx, length 46
14:06:50.923239 ARP, Request who-has x.x.x.196 tell x.x.x.2, length 46
14:06:58.177514 IP x.x.x.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 307
14:06:58.180722 IP x.x.x.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 307
14:06:58.181458 IP x.x.x.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 307
14:07:01.092245 ARP, Request who-has x.x.x.218 tell x.x.x.2, length 46
14:07:02.023750 ARP, Request who-has x.x.x.205 tell x.x.x.2, length 46
14:07:02.625115 ARP, Request who-has x.x.x.2 tell x.x.x.187, length 46
14:07:02.641458 ARP, Request who-has x.x.x.208 tell x.x.x.2, length 46
14:07:02.643704 ARP, Request who-has x.x.x.187 tell x.x.x.2, length 46
14:07:02.908839 IP x.x.x.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 307
14:07:06.860131 IP x.x.x.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 313
14:07:06.886681 IP x.x.x.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 307
14:07:08.944501 IP x.x.x.2.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 307
14:07:09.637136 ARP, Request who-has x.x.x.98 tell x.x.x.2, length 46
14:07:12.352409 ARP, Request who-has x.x.x.125 tell x.x.x.2, length 46
14:07:12.364550 ARP, Request who-has x.x.x.128 tell x.x.x.2, length 46
14:07:15.237527 ARP, Request who-has x.x.x.2 (xx:xx:xx:xx:xx:xx) tell x.x.x.222, length 46
14:07:15.238167 ARP, Reply x.x.x.2 is-at xx:xx:xx:xx:xx:xx, length 46
--- End Of Stream ---

Any thoughts!? Thanks in advance....

[Mark_B7]

Hi Martyn,

Did you manage to fix this?  We have a similar issue...

Thanks

Mark

[MartynB]

Sadly not, no! Still hoping someone discovers this and knows the solution! Comforting to know I'm not alone however!

[AxL1971]

I have a similair issue where a MS-410 acting as a DHCP server does not fullfill a DHCP request, running Wireshark on both client and switch I can see the DHCP Discover but never the Offer coming thru from the switch

I have been spoken to Meraki support and they recommend by rebooting the switch and see if this resolves the issue. Not ideal as I would much prefer to get a root cause of this issue.

[Mark_B7]

I'm not convinced that this is a DHCP server issue, as we are seeing this on Corporate and Guest SSIDs both of which use different DHCP servers - Corporate a Windows server and Guest DHCP is running on a Firewall.

[MartynB]

In for a penny...... I just rebooted my switch, as it isn't technically in a production environment yet, so almost no impact on anyone beyond myself...... Rebooting the switch obviously caused a reboot of the AP and I'm still seeing the same issue on the SSID distributing DHCP from the Domain Server, the Laptop does have a valid address, I've released it, reserved it and then renewed to force the server to issue a new address, but nada, can't ping the gateway or anything else. The other SSID works fine using the AP's own DHCP service, devices can browse out through that without issue

[Mark_B7]

Anyone using this...?

Cisco Meraki Wireless Health API Integration - Splash Access Cisco Meraki

[MartynB]

I have access to a "Health" page, under Wireless>Monitor that offers a lot of information regarding indivdual client experience, is this something different?

[Mark_B7]

Yes splash portal is an add-on.

Thanks

Mark

[Phil6]

Hi,

If the wireless config was the issue then you would see it on dashbaord when looking at the client page. Assuming that your setup is correct, and considering that the SSID works elsewhere in the business, I would look at the DHCP/ Radius Servers, do we have the users from the affected site in the correct groups and also where they authenticate, what happens after they authenticate ?, ipconfig /all from affected user and can we ping the DNS from affected user and or switch

Also test by setting up the SSID not to use any authentication and have a user connect and test ( Access Control>Network Access>open no encryption )

But before everything, please make sure you firmware is up to date on both MR's and MS's

Hope this read will not be a waste of time lol

Regards

Phil 

[Shamwedge]

I'm getting this same error for multiple clients.

This appears to only be happening on SSID's where client IP assignment is configured to Local LAN. I'm wondering if this is simply a software bug caused by having bridge mode enabled. 

Outside of the error message, cleints do connect without issues.

[Mark_B7]

We have just changed from L3 roaming to L2 Bridge mode and we are seeing this in both modes.  We did have 2 DHCP servers configured, we have recently removed the second one and the errors have reduced but not gone away completely. 

[MartynB]

Hi Guys, I've been away from the office a lot recently, however I set the AP's to update to the latest firmware on Monday and have just got back in to the office for testing today.....

Switches and AP's all now running the latest firmware, when I said the same setup was running in the other businesses we support, I was referring to the firmware version at the time, and the SSID configuration, the SSID I'm having an issue with isn't functioning elsewhere in the organisation, it is however identically configured to others that are functioning as they should

There is no Layer 3 config on this network, nor is there any Radius, the SSID is set up to use a PSK in Bridge Mode with a single Windows 2008R2 DC serving DHCP. I have tried your suggestion and mirrored this setup in a test SSID with open access (no PSK) and have the same issue;

Client made a request to the DHCP server, but it did not respond.request_ip='x.x.x.219' request_server='x.x.x.2' details='no_dhcp_response' radio='1' vap='2' channel='108' rssi='50'

However, the client has a valid IP address, DNS server entries and gateway ip as well as the correct DNS Suffix, yet can't ping any of the above

How do I go about raising a ticket with support?

[RobHuijser]

Hi Guys, I do not see any solution in this thread, also Meraki support is not knowing this issue.

packet trace must give some answers to all our questions but it happens not often and not always.

We are running an enterprise solution with 2 forwarded DHCP servers in our datacenter using radius authentication, no firewall rules and only seeing the issue on one specific SSID. Never had the issue before for the last 3 years. Both DHCP/DNS servers are up and running and are the most important servers in our environment, so 100% up

Is there an article with the solution?

[WaseemD]

Hi guys,
We have been suffering with this issue for more than ten months; we have three separate environments in various locations, each running the Meraki solution, all connected to the same radius server via LAN, and each using a different brand of DHCP server and routers.
This problem only affects one place for prolonged time, and it happened only once on another location but only for 1 day.
This issue affects users in a complete random manner, no specific details nor device type/NIC make was detected.
we have 1500+ user in the environment with more than 15 different devices, NIC and drivers.

Following a thorough study and checks, we have discovered the following:

• According to pcaps from clients and (AP's wireless); discover requests are sent, however they are never shown on the switch nor (AP Wired) captures..
  Before the discover packets can reach the (AP Wired) pcaps, they are lost.
• The DHCP server's packet captures indicate that the client has not sent any packets, but any successful connection does indicate a full DHCP DORA.
• 4 or more clients may successfully connect to and finish the DORA on the same AP where a client fails to do so.
• We attempted to restart all of the devices in production,, also we upgraded the Meraki APs and switches to the most recent firmware release but without success.

The workaround we have thus far involved is moving the problematic machine to another AP (Roam), trying to connect again and it succeed, then returning to the same location while still being connected, even when reconnecting will be successful.

The device connects and complete the DORA when roamed.

Please let us know if this was useful and if anyone had a solution for this problem.

Support from Meraki was of no assistance at all.

A big thank you!

Regards,
Waseem

- 

[AshP]

Hey folks,

This might help only small % of cases but the same error:

Client made a request to the DHCP server, but it did not respond.

type='NO DHCP response' associated='true' radio='0' vap='0'

The MX was removed, there was a modem swap and techs suspected new modem (GW Mode) being an issue. Rebooting did not resolve the issue, firmware wasn't upgraded but upon checking this was naturally related to VLAN Tagging. Everything works fine on simply disabling that, in these type of change scenarios.

_________

Check from:

Configuration overview

SSIDs

VLAN tag

This column refers to VLANs set in Bridge or L3 roaming. For info about VLANs used for VPN, see the VPN column below.

Then Go to:

Access control

Scroll down to: Client IP and VLAN

Disable VLAN tagging

(VLAN tagging is used to direct traffic to specific VLANs. To use VLAN tagging, all Meraki APs functioning as gateways in this network must be connected to switches that support IEEE 802.1Q.

The gateways must be connected to switch ports that are configured to accept 802.1Q tagged Ethernet frames (such ports are sometimes called "trunk ports").

If you are unsure, don't enable this feature.)

Hope this helps someone at least. 🙂