Clients connect to SSID, but no data is sent after association

[wifisyfy]

Hello, 

I've observed this mainly on iOS 11.x devices and some Android devices running Oreo.   This has been ongoing for months.  The "fix" is to reboot the AP, or any sort of change to the AP that will reset the radio (such as modifying channel-width or client load balancing and such).  

I'm using the MR42 platform.

I've run several pcaps when the issue occurs, and what I see is associate probes, probe responses, authentication completes and association is successful.  The following is a series of client RTS and AP CTS packets.  But that's it.  No data.  The client just keeps asking over and over "Ready to Send" and the BSSID will respond with "Clear to Send" but the client never sends data.

Because I'm running NAT mode with Meraki DHCP, a DHCP address is never obtained because absolutely no data is ever sent, even though the client is associated.

I've been going back and forth with 3 different Meraki support engineers on this.

A couple things I've noticed:

I have 2 old iOS 9.3.5 devices that don't have this problem at all.   Only updated 11.x devices.

When I run into an AP that is acting up, I will walk around to a different AP and it will  associate and work fine.

As mentioned before, any sort of reboot or state change or radio reset on the AP will temporarily fix the problem.

So...anybody run into this?

[PhilipDAth]

Running 25.11?

[wifisyfy]

Yes, 25.11.  With the first go-round with Meraki support they said upgrading to 25.11 should address the issue.  It did not.

[wifisyfy]

I'm considering the possibility that my capture device is perhaps not capturing the data for some reason, but is capturing "control packets" such as association probes,  RTS/CTS and null functions.  

Could this be the case?   My capture device is an older MacBook Air.   I can only capture on 20MHz or 40MHz channel-width.   Would this make a different if my client device was running at 80MHz?   

[oakparktech]

Reviving this oldish thread.

I'm having this issue as well.

Meraki support hasn't been able to tell me anything.

I've called on CDW to help me out with this issue.

Anyone else seeing this kind of issue?  Any resolution?

[PhilipDAth]

I've never seen the issue across any of my clients. So it must be pretty rare.

I'm wondering if there might be some kind of security issue happening - such as another (non-Meraki) AP using the same SSID - so you think you are attaching to the MR42 but you are not.

[oakparktech]

There are no other APs.  Also in the client view, I can see the device connected to the AP.

I had a couple of people look at the situation, and it seems the DNS/DHCP servers are acting as they should, but the ACK responses are not getting back to the client.  So the client doesn't get an IP or resolve dns queries.  What's even odder is that this was only happening on one vlan, the rest were fine, even on the same AP.

I'm going to have Cisco take a look at our core switches, which does the vlan routing.

[wifisyfy]

Hello, 

OP here.  So I never did get a resolution from Meraki.  I spent hours on the phone with Meraki support and took countless pcaps.

I eventually had to give up because I don't have a device that can capture in monitor-mode and supports 802.11ac on 20/40/80Ghz bands.  I have had a hard time tracking anything down that can do this, short of a new model Macbook Pro...but seriously there has to be something other than a Macbook that can adequately run 802.11ac monitor-mode?

Another thing that was frustrating was an apparent bug that Meraki has in their own AP capture mechanism, where capturing on the AP doesn't show 2-way traffic.  I forget the specifics but at the time i was like "seriously guys?"

So, the only fix I have when this issue crops up is to still reboot the AP, or fiddle with a setting that resets the radio.

If anybody has a suggestion for a rig I can setup remotely to capture 802.11ac monitor-mode, that would be really great.