OSX Clients Connected to AP, but not passing traffic

[jason_davis_793]

Anyone else experiencing issues with OSX clients connecting to APs, then randomly not being able to pass traffic/browse the internet?

We're seeing this primarily with OSX 10.11 clients. We have ZD1200s and R710s running 9.13.1

Ruckus support's latest fix was enabling Proxy ARP or upgrading to Sierra. But we just experienced the same issue with a Sierra device.

[bas_sanders]

Hi Jason,
We have seen issues with Apple devices on multiple releases, but mostly when the latency between AP and ZD are high (500+ms). And yes, we know that is beyond limits, but the odd thing is that it only happens with apple devices. Any other device will work fine.

Our setup is traveling with the F1 and our ZD is located in NL. Any race in Asia/AUS or the america's causes latencies up to 750ms.

So far ruckus was never able to pinpoint the problem in our case.

[jason_davis_793]

Interesting...I'm concerned that Ruckus is not able to resolve this issue given how long they have been continuing and we'll be forced to switch to a new vendor.

[joseph_lobianco]

Hi jason,

We are having a similar issue.  Running ZD1200 and 3 R710s in a full El Capitan (10.11)/Yosemite environment (some Linux clients).

Symptom: A wifi connected client will experience connectivity loss to the default gateway (and of course the public internet as well) for roughly ~10 seconds; all applications/connections will automatically re-connect where applicable after this time.  This does not involve a drop in connection to the wifi.  At first, Ruckus tried to state that this was a GTK/PTK corruption issue involved with WPA2, which can only rectified by upgrading to Sierra (as you see, it has not solved your issue).  Confirmed loss to default gateway by seeing ICMP drop.

After pushing back, we ended up putting a packet capture on the ports that each AP is connected to, and what I found was that at some point in time all return traffic fails to respond to the client's requests, which continue trying to retransmit un-ack'd packets; the requests fail to even reach the AP, proving the issue is on my network at first glance.

What is interesting is that this only occurs for wifi clients, not ethernet.  Furthermore, our network is ridiculously simple in terms of design/configuration, so I truly believe there may still be an issue on Ruckus's end.

My current plan of action is to continue to isolate where the return traffic is not returning, and then work with my network vendor.

Please let me know if our symptom is similar to yours.

Edit:  Also, what is the frequency of your issue?  For us, it is anywhere from affecting multiple clients a day multiple times a day to no issues (or at least, no clients reporting issues to me) for a week or more.

Edit: We do not experience any major latency issues (500+ ms) prior to the drop 

[jason_davis_793]

That's very similar behavior to what we're seeing. Although we have to turn off/on the wireless adapter to get traffic going again (but we have 802.1x authentication). In terms of frequency, it's hit or miss for us...a couple times a day maybe. Though our users probably work around it, rather than send in tickets. We also do not have major latency issues.

Edit: Ruckus support also called out a GTK corruption issue and stated Proxy ARP/OSX Sierra would resolve the GTK issue