nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Mac airbooks disconnecting

itdept_head_me

I am having massive problems with my R500 units and mac airbooks 10.10.5 / elcapitan
I have had support looknig at this for several weeks and they are of the mind that it is the mac airbooks not the ruckus equipment.

the problem occurs after the computer goes to sleep, it seems to be keeping the WIFI open but not the networking infrastructure to relay the data.

Even more annoying is it only does it with the ruckus, my $20us cisco , asus & TP-link functions without any problems., they seem to force the connection closed, ready for the mac to re-connect after it comes out of sleep.

Find more posts tagged with

Accepted answers

All comments

martin_martin

Hi,

Did you update the mac with the latest updates of El Capitan.
Cause the first versions of El Capitan had driver issues.

Regards
Martin

itdept_head_me

Still won't work.

took a 10.10.5, not working, took it to latest elcapitan, still same result, besides it works perfectly with everything but Ruckus

martin_martin

Hi,

I suggest you to open a case with customer support to have a detailed look at it.

Kind regards
Martin

itdept_head_me

did, due to various reasons it went on for 8 weeks, they came back that they consider it is the airbook computer NOT the ruckus equipment.
which is why I'm here

sid_sok

What is your support case number?
Can you use a second mac book to get some air capture of the various test?
Problem macbook with cisco (what model and code version)
Problem macbook with asus (what model and code version)
Problem macbook with ruckus (what model and code version)

If the problem is after the client wake up, you can set up the APs, to a specific channel, connect the client, close the lid for 30 seconds, open the lid and see if it can pass traffic?

If you have already done this test, are the packet capture in the case?

Sid

itdept_head_me

case ID : 00332321
is wire shark suitable for the captures?

macbook air, it seems to be most of them.
The one interesting case it a mac book pro, with exactly the same wireless chip & firmware revision works without issue as a non working macbook air, all other devices have same chip but different firmware revisions.
Second point of note, after wakeup the ASUS/CISCO have kicked the mac, but it reforms the wireless without prompting.(as long as it does not have access to ruckus)
for the ruckus, the mac comes up with the wireless already formed, but no traffic will pass.
3rd point , if the airbook has the pw for both the ruckus and other wifi, whilst it is sleeping, it seems to get kicked from the asus/cisco, then forms a connection with the ruckus and wakes up with a bad connection.

Same macbook air used for all tests, otherwise it is pointless.
packet captures are in the case notes, engineer had remote access to AP's

I pointed out that this case is holding up purchase of about 50k of wifi equipment for a new location,
if i cannot solve it, i must use cisco.

unknown

I had a similar problem with my clients and my Unleashed AP, not specific to MacBooks, and the problem was the "Force DHCP" option was enabled and was causing issues. My clients could be connected to the WiFi but no traffic could go to the network. I disabled the option and now everything works great.

itdept_head_me

yes.... that is not the issue in this case.

itdept_head_me

so no follow up on this ?

martin_martin

Hi itdept_head me,

Please open a case via the support portal or provide us the case number you had , so the correct follow up can be done, including in-depth check of any available wireshark captures.

Kind regards
Martin

michael_brado

Sid asks if you have a case open, so we can get wireless traces, to really see what is the issue?

itdept_head_me

It's Chinese NY here everything is closed down.
ok opened it....,
It might have been easier to re-open the existing case.

Possibly wireshark is no use, the issue seems to be at a level beyond tcp/ip

unknown

Any resolution?

unknown

Hello again,

My issue is still rumbling on too. Disabling 802.11R does seem to have improved things with the iDevices but not resolved the problem completely. I'm still seen devices falling off the network and not reconnecting.

I have increased the "Inactivity Timeout" as was suggested so I'll see if that makes a difference.

Kind Regards,

Andy.

unknown

See my post here: https://forums.ruckuswireless.com/ruckuswireless/topics/client-disconnetion-ip-0-0-0-0

Most of our WiFi issues were iPhone related. Would not be surprised if it bled over to other Apple products.

unknown

Hello,

I've now had my case resolved.

I wanted to share the conclusion in case it's useful to anyone else.

In the end nothing to do with Ruckus- my issue was down to Apple's keychain.

It seems (possibly from iOS release 10?) that keychain shares WLAN passcodes via iCloud.

So, the issues I was seeing were among devices that shared iCloud accounts. Specifically I had 2 pairs of devices (in each case an iPhone and iPad) which were having connection issues.

Assuming unique Ruckus Pre-shared Keys (PSK), manually updating the WLAN PSK passcode on (for example) the iPad, resulted in that passcode being shared with the iPhone (via iCloud and keychain) which would promptly result in the iPhone failing authentication and disconnecting from the WLAN. The same was true the other way around,iPhone to iPad with the same mechanism.

So, I guess to generalize (and this may be obvious to most people, but certainly missed by me) iOS or MAC devices which share an iCloud account cannot use manually shared PSKs. Keychain will result in the latest PSK being exchanged among all devices which share the iCloud account.

The issue may not exist if Ruckus Profiles are used on Apple devices- but I wasn't able to test or verify that.

In the end I used a dedicated WLAN just for Apple devices.

Turning off Keychain would also work- although perhaps not desirable for most Apple users.

I hope this is useful.

Kind Regards,

Andy.