Are there any known issues with Apple MacBooks losing their wifi connection?

daran_rowlands — Thu, 19 Sep 2019 23:36:16 GMT

Re: Are there any known issues with Apple MacBooks losing their wifi connection?

daran_rowlands — Thu, 19 Sep 2019 23:37:11 GMT

sorry first time using this forum... more info below:

particularly when roaming between AP's - have a number of reports of users Macbooks spontaneously showing the wifi exclamation mark icon. Looking at the client association in hivemanager they remain associated throughout the entire day to the centisecond, even when roaming to adjacent APs.

APs are 550's, heat map shows adequate coverage. Can't replicate the issue on a Wintel device.

Re: Are there any known issues with Apple MacBooks losing their wifi connection?

ben_jones — Wed, 25 Sep 2019 15:26:20 GMT

Yes I am getting exactly the same problem. But my Service Delivery team don't seem to be able to pinpoint the problem. : )

Re: Are there any known issues with Apple MacBooks losing their wifi connection?

ashley_finch — Wed, 25 Sep 2019 17:51:16 GMT

iOS devices do seem to have a higher roaming threshold (around -70) so they may be clinging onto another AP for longer than a Windows device. The fact that they remain associated to the APs the entire day doesn't sound like a coverage issue.

When they roam is there any different VLANs in use between the APs? Which authentication method is being used on the SSID? When they have the exclamation mark symbol, do they have an IP address (and is this a correct address?) and can they ping the default gateway?

Probably the best data you can get would be to run a client monitor on some MacBooks and obtain a packet capture from the client and AP if possible.

Re: Are there any known issues with Apple MacBooks losing their wifi connection?

daran_rowlands — Wed, 25 Sep 2019 19:15:17 GMT

Hi Ashley,

thanks for taking the time to reply. to answer your questions:

Yes, we have plenty of coverage. There are five APs spread across a single floor, all on the same VLAN. We have AD-based username/password authentication on the SSID,

Haven't been able to "capture" one of these events live yet so can't answer the questions around IP address etc. We've now set up some logging on the mac's so that any network changes are logged back to our logging server... hopefully,we will get more info.

thanks for your help so far!

Re: Are there any known issues with Apple MacBooks losing their wifi connection?

daran_rowlands — Wed, 25 Sep 2019 23:01:21 GMT

Some further analysis by one of our team shows that this may be related to the wifi remaining connected when Mac is unplugged from monitor (which also supplies power/keyboard connection) and the user moves across the office. The Mac seems to stay associated but has possible issues with reauthentication. following extract from the analysis:

The issue happened before 1:42, but the SSID was not dissociated.

From the machine logs, I believe that closing the lid may have triggered the 802.1X authentication to stop, however the wi-fi itself remained linked.

Wed Sep 25 13:37:33.022 <kernel> IO80211VirtualInterface::controllerWillChangePowerState : Bringing down link

Wed Sep 25 13:37:33.022 <kernel> IO80211VirtualInterface::handleSIOCSIFFLAGS : Source controllerWillChangePowerState calling peerManager->disable

Wed Sep 25 13:37:33.022 <kernel> wl0: wl_update_tcpkeep_seq: Original Seq: 453157913, Ack: 4192625624, Win size: 2048

Wed Sep 25 13:37:33.022 <kernel> wl0: wl_update_tcpkeep_seq: Updated seq/ack/win from UserClient Seq 453158072, Ack 4192625693, Win size 342

Wed Sep 25 13:37:33.022 <kernel> wl0: leaveModulePoweredForOffloads: Wi-Fi will stay on.

Wed Sep 25 13:37:33.022 <kernel> AirPort_Brcm43xx::platformWoWEnable: WWEN[enable], in_fatal_err[0]

Wed Sep 25 13:37:33.022 <kernel> AirPort_Brcm43xx::syncPowerState: WWEN[enabled]

I’m seeing that after this, the 802.1X authentication attempted to connect several times, each time the key which has been cached looks to be correct and is installed

Wed Sep 25 13:38:03.034 <kernel> IO80211Interface::pmksaLookup: Looking up PMKSA for b8:7c:f2:54:1a:25.

Wed Sep 25 13:38:03.034 <kernel> appending pmkid<kernel> en0: roam event, pmksa found.

Wed Sep 25 13:38:03.034 <kernel> updateIE:

Wed Sep 25 13:38:03.034 [00000000] 30 26 01 00 00 0F AC 04 01 00 00 0F AC 04 01 00 00 0F AC 01 00 00 01 00 31 4A DE 95 00 33

Wed Sep 25 13:38:03.034 [0000001E] 09 21 B1 B1 53 08 D6 36 F0 EE

Wed Sep 25 13:38:03.113 <kernel> en0: Received EAPOL packet (length = 135)

Wed Sep 25 13:38:03.113 <kernel> inputEAPOLFrame: 0 extra bytes present in EAPOL frame.

Wed Sep 25 13:38:03.113 <kernel> inputEAPOLFrame: Received message 1 of 4

Wed Sep 25 13:38:03.113 <kernel> FULL RSN IE FOUND:

Wed Sep 25 13:38:03.113 [00000000] 30 14 01 00 00 0F AC 04 01 00 00 0F AC 04 01 00 00 0F AC 01 0C 00

Wed Sep 25 13:38:03.113 <kernel> storeFullRSNIE: getAP_IE_LIST returned 0

However, this section is immediately repeated.

Wed Sep 25 13:38:03.114 <kernel> PMKSA cache match! Using cached PMK

Wed Sep 25 13:38:03.114 <kernel> PMK:

Wed Sep 25 13:38:03.114 [00000000] E4 25 E2 B8 DF BE 9F 17 18 05 CA A6 7F 0E F1 C5 8B 04 0D F3 FD 54 E5 72 8D 84 FA 48 92 B8

Wed Sep 25 13:38:03.114 [0000001E] 58 9F

Wed Sep 25 13:38:03.114 <kernel> TPTK:

Wed Sep 25 13:38:03.114 [00000000] 1B A1 6E 99 5E 1E 7B F2 87 18 E0 32 E8 1B EB 17 FF 0C 7F B3 6B 36 94 06 05 73 4A AF 6F 0A

Wed Sep 25 13:38:03.114 [0000001E] CE 52 84 62 16 8F 04 62 42 BB DB 7C C6 89 73 85 F6 01 00 00 00 00 00 00 00 00 00 00 00 00

Wed Sep 25 13:38:03.114 [0000003C] 00 00 00 00

Wed Sep 25 13:38:03.114 <kernel> KEY MIC:

Wed Sep 25 13:38:03.114 [00000000] 30 96 7A 98 E3 FA 74 80 9D BF 13 A9 56 5D 5A 8F

Wed Sep 25 13:38:03.114 <kernel> process1of4: sending replyPacket 153 bytes

Wed Sep 25 13:38:03.116 <kernel> en0: Received EAPOL packet (length = 169)

Wed Sep 25 13:38:03.116 <kernel> inputEAPOLFrame: 0 extra bytes present in EAPOL frame.

Wed Sep 25 13:38:03.116 <kernel> inputEAPOLFrame: decrypting key data

Wed Sep 25 13:38:03.116 <kernel> inputEAPOLFrame: Received message 3 of 4

Wed Sep 25 13:38:03.116 <kernel> process3of4: Performing IE check.

Wed Sep 25 13:38:03.116 <kernel> process3of4: sending replyPacket ( len = 113 ).

Wed Sep 25 13:38:03.116 <kernel> process3of4: received pairwise GTK

Wed Sep 25 13:38:03.117 <kernel> PTK Install Timer: Installing PTK

Knowledge of authentication is limited but it appears that the PTK that is installed either doesn’t work, or there’s something else going on as the authentication fails over and over until the Wi-Fi is turned off and back on again.

The hunch is that when the usb-c connector is removed (lid of the Mac is closed under normal operation), the 802.1X authenticated connection gets shut down, but the Mac keeps the Wi-Fi radio on and connected to the AP (hence not seeing a dissociation) in the Aerohive log. When the lid is opened again, the Mac attempts to re-authenticate.

Oddly, it looks like authentication is happening, but failing. One possibility is that the AP (or authentication mechanism) gets ‘confused’ as the Wi-Fi hasn’t actually been dissociated.

Potentially, if a machine fully goes to sleep and the WiFi is powered down, then this wouldn’t be an issue.

Can anyone decipher the log to a greater level of detail?

Are there any settings under the SSID Access Security setting in the Hive Manager that need tweaking (see photo of current settings)

Any help appreciated...

topic Re: Are there any known issues with Apple MacBooks losing their wifi connection? in Aerohive Migrated Content

Are there any known issues with Apple MacBooks losing their wifi connection?

Re: Are there any known issues with Apple MacBooks losing their wifi connection?

Re: Are there any known issues with Apple MacBooks losing their wifi connection?

Re: Are there any known issues with Apple MacBooks losing their wifi connection?

Re: Are there any known issues with Apple MacBooks losing their wifi connection?

Re: Are there any known issues with Apple MacBooks losing their wifi connection?