Skip to main content

44 Messages

 • 

710 Points

Fri, Oct 7, 2016 8:07 PM

Answered

OSX Clients Connected to AP, but not passing traffic

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.

Responses

31 Messages

 • 

588 Points

4 years ago

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.

44 Messages

 • 

710 Points

4 years ago

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.

5 Messages

 • 

102 Points

4 years ago

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 

44 Messages

 • 

710 Points

4 years ago

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

5 Messages

 • 

102 Points

4 years ago

Are you using Juniper by any chance? Ruckus also suggest proxy arp/sierra. I can confirm that what we are experiencing is NOT related to any wpa2 corruption.

I highly recommend running a packet capture at the port(s) on your network device that connects to you APs and see if you experience the same traffic patterns as what I described (no return traffic coming back to the APs.).

We do not use 802.1x. Since you have to reconnect your wifi connection manually, there is a possibility you are in fact seeing a gtk/ptk issue (you should be able to easily verify this yourself with packet capture).

44 Messages

 • 

710 Points

4 years ago

No to Juniper. I'll try the packet capture. Thanks

824 Messages

 • 

13.2K Points

4 years ago

hi

i got one customer with ZD1200 on 9.12 and 2*r700 & R300, They have MBP wth sierra with similar issue as you guys mentioned
I have asked them to try the suggestions on this post as it seems to solve following issue:

  • The Mac disconnects from wi-fi when wakes from sleep
  • macOS Sierra drops wi-fi connections or disconnects from wireless at random
  • Wi-Fi connections are unusually slow or have a higher ping than usual after updating to macOS Sierra

http://osxdaily.com/2016/09/22/fix-wi-fi-problems-macos-sierra/

May be this helps..

10 Messages

 • 

172 Points

I have writte sleep wakeup script that can switch on wi-fi after wakeup, and before sleep I put the Wi-Fi card off. My macbook retina with Sierra work now perfectly. I digged into logs deeply and it is completely mac problem when firmware fails to intialize. Mine even failed to shutdown correctly before sleep.

44 Messages

 • 

710 Points

Interesting fixes, but those are a bit more invasive than I would like to do for all of our clients. Ideally, we'll see a true fix from Apple or Ruckus soon.

44 Messages

 • 

710 Points

4 years ago

Interesting fixes, but those are a bit more invasive than I would like to do for all of our clients. Ideally, we'll see a true fix from Apple or Ruckus soon.

5 Messages

 • 

102 Points

4 years ago

Some new information:

Packet capture with Ruckus proved issue out to my firewall (acting as the default gateway for my wireless subnet).  After lots of troubleshooting, we now see this to be related to an arp issue that is only experienced by wireless clients.  It appears that the Ruckus equipment will RANDOMLY interfere with arp request/reply between the client and default gateway, which causes a delay of between ~8-50 seconds of loss of [default gateway]->[client] traffic.  Once an arp entry is put into the default gateway's arp table, traffic is immediately resumed.  I emphasize randomly, because sometimes the arp resolution is done appropriately and no issues are seen.

If you are also experienced by this issue, then you can relieve the problem by increasing the arp entry expiration on your router.  I set mine to 24 hours.  Of course this is a workaround and not a fix...

The challenge now is for me to continue troubleshooting with Juniper support in order to procure evidence showing this is a problem with Ruckus' equipment.

44 Messages

 • 

710 Points

4 years ago

Very interesting! Our ARP entry timeout is 30minutes and is not adjustable :(

10 Messages

 • 

172 Points

4 years ago

Ruckus is interfering if proxy arp option is enabled at particular WLAN setup

44 Messages

 • 

710 Points

4 years ago

It was recommended by Ruckus support to enable proxy arp for 10.11 clients. Once all clients are 10.12 it was recommended to disable it.

5 Messages

 • 

102 Points

4 years ago

I'd take Ruckus' suggestions with a grain of salt in regards to their suggestion on proxy arp unless it is escalated to a (very) senior engineer.  Ruckus has repeatedly told me to try certain fixes that very clearly have no effect or make any technical sense.  We use 10.11 here in my office without proxy arp enabled, and have no issues except for the one that I am troubleshooting.  It is possible that we would need to enable proxy arp as they suggested, but from my understanding this would not apply to us since we are seeing this issue within a single broadcast network (i.e. proxy arp on/off wouldn't help/hurt here).

If I can now reproduce this issue by significantly lowering my arp expiration timeout setting on my router, then I should be able to test out the effect of enabling proxy arp on the WLAN.

129 Messages

 • 

1.6K Points

Have you made any additional determinations about enabling proxy arp?

5 Messages

 • 

102 Points

Unfortunately I have not yet.  I will report when I get a chance to.

2 Messages

 • 

72 Points

4 years ago

I'm experiencing this too. Proxy ARP seems to help, but fundamentally I have a packet capture showing quite clearly that my Juniper gateway (an L3 switch in this case) sent an ARP request to the client, it arrived at the AP (which I'm capturing via a SPAN port), and the AP refused to deliver it to the client. It wasn't until the client did another ARP request to the gateway that things got better. On the same token, I've noticed that Windows clients seem to send gratuitous ARP requests periodically and I suspect this is actually what's helping them avoid this. ARP is pretty fundamental; the AP is deliberately interfering with it in a bad way.

2 Messages

 • 

50 Points

4 years ago

We haven't seen it as much after making a few tweeks with Ruckus support. We're still rocking the proxy arp as well.  We've seen a few of the known bugs that Ruckus is working with Apple to resolve...not sure of a resolution timeframe though.