New installation - DHCP issues

[Joem1]

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.

[Joem1]

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_Captu...

[Joem1]

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

[alemabrahao]

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

[Joem1]

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.

[Joem1]

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

[Joem1]

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.  

[Joem1]

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. 

[Joem1]

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.