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 ?

[Joe Mrazik]

As it turns out this is NOT a DHCP issue at all. The MR46 will periodically display random invalid MAC addresses (i.e.- CB:6F:BF:26:BD:A0) The MAC address does not belong to any registered block, CB:2E:DD:6D:6C:47, C2:E1:98:C0:3B:93 etc. After tracing numerous client devices and confirming they were not the source for this, I can only suspect the MR46. It appears to randomly display these bogus addresses. Ultimately devices start losing connectivity until the AP becomes unavailable. There are clients that stay connected and will work for some period of time. I think the MR46 becomes unusable because of the sheer volume of phantom MAC addresses. My most recent high count was 500 connected devices on a single AP. Meraki support finally admitted this is a known issue and was supposedly corrected with firmware 31.1.8. I have returned more than twelve AP's. The units I receive generally work better. It is hard to determine what the exact trigger event is for this issue but it is NOT RESOLVED. I have been dealing with this for more than six months.

[Joe Mrazik]

This issue IS NOT RESOLVED, FIXED or CORRECTED. Feel free to post if you have experienced this issue.

[aneduzhk]

@Joe Mrazik have you opened a support case? If you have not, please do. If you have, please DM me the case number. Thank you!

[Joe Mrazik]

Thanks, so many cases I lost count. Here is the latest 13844403

[Joe Mrazik]

Update, many thanks to AlexanderN. The timing may be a coincidence, but we finally received the escalation we have been trying to obtain for several months. Advanced logging was captured today along with console developer network tracing by Meraki support.

It finally feels like we are being heard.

Hope to have better news on these updates.

[Joe Mrazik]

We still experienced the issue until we looked deeper into Air Marshal. We discovered several HP printers broacasting wifi direct. Disabled all of those. Also we found that smart tv's, which we have all over the floor, are also broadcasting wifi. In one case it was literally broadcasting: (FF:FF:FF:FF:FF:FF). Can't turn off wifi on the tv's. So instead we began to aggressively force containment on all rogue ssid's. Amazing that virtually every vehicle in our parking lot is an AP. At this moment there are over 300 rogue ssid's detected. Since then the AP's are not showing the phantom mac address with the associated 0.0.0.0 address. It has been a week since implementing the rigorous containment, but it seems to be the root cause.

[Joe Mrazik · Accepted solution]

Finally determined the root cause of this long standing issue.  As it turns out the issue is related to a specific channel (149) in the 5Ghz band.  Every time this issue manifested the AP was using that channel.  It must be due to our specific environment and still possible that Apple TV's are on that channel causing the entire issue.  We have not been able to confirm that.  Hopefully this guides someone to realize that it isn't always networking. 

[Abdulaziz Loonat]

Perform packet capture on the endpoint, the access points and switches, from this you can determine what is in the actual DHCP packet

Can you see the DORA process

Discover - client finds DHCP server

Offer - DHCP server says here is a IP address for you

Request - Endpoint says OK I will take this IP you have given me

Acknowledge - DHCP server says OK you got this IP address