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...
