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.

[help_desk_fkaer]

Yes the thread is two years old and yet Ruckus has not been able to resolve the issue with as many of us opening tickets. I had a ticket open back then that was eventually closed by the engineer because I failed to respond while on vacation. The last I heard from an engineer was that Apple claimed an issue with certain models and OS but only releasing a fix for a subset of that. Seems to me the issue is either in your code as it’s been an issue for this long, or Apple is using the same networking stack in each new OS release.

[andrew_struiksm]

Michael, just an FYI that I have an existing case open with TAC related to this issue. However, it is difficult to work with TAC since the response time is so SLOW and then a case is suddenly closed when I'm out of the office for a few days. I can have the issue occurring at a point in the day but am unable to get a hold of a support engineer to demonstrate the issue. The engineers are helpful when I can speak with them but case progress takes forever.

[eightohtwoeleve]

I have had the same experiences with TAC. It also doesn't help I don't get the email updates/notifications when the ticket has been updated by TAC.

I also believe that we are also seeing the connected but no internet problem on 5.1.2 as well but can't fully validate that. We might be downgrading APs to 5.1.0 with AP auth for RADIUS to see if we have better luck.

[andrew_struiksm]

It appears that the core issue in our case is that the AP is not sending ARP packets to the OSX client. We finally discovered this while running a packet capture on two OSX clients connected to the same WLAN on the same AP. One client would see a constant stream of ARP communication while the other client would not see any ARP traffic except its own. The end result is that if the router (Brocade/Ruckus switch in our case) for that WLAN had a default ARP timeout of 10 minutes then every 10 minutes the OSX client would lose network connectivity for about 2 minutes until the client was able to exchange ARP packets with the gateway and then traffic would flow again. Since TAC still hasn't been able to resolve this, I have increased the ARP timeout on all of our routers to 22 minutes (ip arp-age 22) which seems to be the minimum amount it can be set to so that the OSX clients do not drop offline. OSX seems to generate its own ARP traffic at least once every 21 minutes which then avoids the problem. However, the core issue remains that two identical clients running packet captures see very different ARP communication from the APs. Also, if the client roams to another AP and then back to the original AP the client seems to get all the ARP traffic for a while then it goes away at some point.

[steven_antle]

Hi I'm having the same issue running a brand new vSZ-E 5.2.0.0.699 w/ AP firmware 5.2.0.0.1412. I'm using all R510s and we're seeing Windows 10 and Apple iOS devices "stall". The devices are no longer able to communicate with the network unless their Wi-Fi adapter is disabled and re-enabled. Is there a solution to this other than enabling proxy-ARP/increasing gateway ARP timeout/other magical workaround? It's very frustrating for our users as anyone can imagine.