New installation - DHCP issues

[Joe Mrazik]

We recently deployed MR46 AP's and have discovered a bug on two AP's. Multiple devices could not obtain a DHCP address. The AP's were returned and new ones are good. We are still having devices (iPad) that connect and then at some point no longer connect. Cannot obtain DHCP address or the offer is never sent. By changing the mac address, i.e.- turn on private wifi address it presents a new mac address and sometimes it can connect.

Based on our recent experience with completely failed connections I suspect there is still an outstanding issue. Has anyone else experienced this issue ?

[mloraditch]

What is doing DHCP the AP (NAT Mode) or another device? I've only ever seen anything like this with issues with the DHCP server, not in NAT mode.

[Joe Mrazik]

DHCP is coming from a Cisco Catalyst switch which is doing ALL of our dhcp wired and wireless. Sometimes we can get this device to work by moving to another AP. We still have a 2504 WLAN controller and seven 3802 AP's, when we move the device within range of that system it connects flawlessly.

[mloraditch]

Have you done packet captures or logging on the Catalyst to see if the DHCP requests are coming into the catalyst when things are failing and if so how the catalyst is reacting?

I can foresee two problems that would be the ap, either it's not sending the requests onto the LAN or somehow mistagging them OR the offers are coming back and it's not sending them to the client.

Either way that's the nice thing about DHCP it's plaintext and pretty readable in a capture.

Here's an article that explains the steps: https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Using_Packet_Capture_to_Troubleshoot_Client-side_DHCP_Issues

[Joe Mrazik]

Thanks we will be doing that next. We have an open ticket too.

[aleabrahao]

What type of authentication are you using and are you using Meraki's DHCP or an external server?

[Joe Mrazik]

Authentication is WPA Pre shared key. The most basic auth that will support our users easily.

[Ryan_Miles · Accepted solution]

Does it affect all SSIDs or just one of them?

Some general areas I'd look at are the following.

If SSIDs are bridged to a single VLAN don't check the L3 roaming box. That only applies when you have multiple VLANs configured for the SSID. Example, a building with 4 floors and each floor has a unique client VLAN/subnet. L3 roaming could maintain the original IP when devices move between floors.

If you have a single VLAN for the SSID the L3 roaming feature isn't doing anything and could actually lead to issues.

Per best practice I would ensure you have band steering enabled on the SSIDs. You may also look into choosing a smaller channel width for 5GHz (20 or 40 MHz) to allow for more non-overlapping channels.

Check the RRM page AI channel planning section to see if there are any error reports. Sometimes there might be RF jammed or other events occurring.

I would also check the transmit power level of your APs. If many of them are being set to very low/the lowest configured tx power you might have too much AP density & co-channel interference. You can selectively disabled some radios to reduce that issue. You can also use AI-RRM to do this automatically (for the 2.4 GHz radios) . But be aware the free trial of it goes away Aug 1st.

Also, ensure you're running the current stable firmware 31.1.7.1.

And if you don't already have a Support case open I would recommend engaging them. https://documentation.meraki.com/General_Administration/Support/Ways_to_Contact_Meraki_Support

Best of luck and hope you get this resolved.

[Joe Mrazik]

Thanks for the Layer 3 roaming tip. Makes alot of sense.

[Joe Mrazik]

Thanks for all the great input. Discovered we had missed a few vlan settings on distribution switches. Since then, all AP's are reporting normally.

[Joe Mrazik]

Update - one of the MR46's that was working normally started to display the same symptoms.

You see a client with a 0.0.0.0 address, which by itself is not unusual. However after the next refresh cycle the device is no longer visible. It never receives a DHCP address and then usually it is not on the next refresh. Also the number of clients varies wildly from 7 to 38 and then back to 15, or whatever. Totally inaccurate and changes on every refresh. I reopened the ticket and let support capture traces, however they were apparently stumped too. Replacing the AP resolved the issue but I am wondering if anyone else has seen this type of issue.

[Joe Mrazik]

Again, three new MR46's are all doing the same thing. Has been confirmed with a packet capture by Meraki support. "Cisco MerakiCase 13456279: MR 46 not forwarding DHCP to client"

The ISP router does reply with an offer of an IP address, but it is never delivered to the client.

The most frustrating part of this is we have had eight of twenty five MR46's have been RMA'd.

Still no acknowledgment that this is a bug with a specific version of firmware. However I am here to tell you we have been living with this issue since rollout on 7/18/25.

[Joe Mrazik]

Another new AP another issue, same as above. Devices may or may not get an assigned address. Received a new RMA'd AP replacement. Decided to do a burn in test to confirm it is working. Approximately 24 hours after the burn in test began, devices started to display a 0.0.0.0 address.

Some would stay connected and not lose their address yet others would toggle between all zeros and a valid IP address. Contacted Meraki support Cisco MerakiCase 13503579. They confirmed the issue and loaded a beta version of firmware on this single AP. Still in test now. So far it is NOT exhibiting the same issue, however it hasn't been long enough to make sure this doesn't happen again.

[Joe Mrazik]

The beta firmware seems to have corrected this issue. However, it is still loaded with beta firmware. I am expecting a new release at some point.

[Joe Mrazik]

More of the same DHCP issue. Contacted support again, I must be a regular by now. They did not require me to reproduce this issue. In this case it was just a single SSID. Strangely, if I connect to that SSID from another location in the same building (different AP) it works, and then I roam to this unit and it continues to work. If however you happen to be in this space, no DHCP address is received. I will continue to post here until I see some kind of release notes indicating the problem exists and has been fixed.