Reordering WiFi networks

@lockwojo It has been a long time since I used the script I posted to the Re-order WiFi Preferred Networks thread. It used to work reliably, but at the time my environment was 100% Sierra systems. I've changed jobs since then, and no longer use the script so I can't say for sure if it still works. I know it was reported to still work on High Sierra, but haven't heard anything for Mojave or Catalina.

The python script @sdagley linked to above has been working fine for us in Mojave and in brief testing it appears to still work in Catalina as well.

Thanks for your replies @sdagley and @cbrewer Yes the same original script from @sdagley runs without errors and does as I mentioned reorder the lists. The problem is that if a user has connected to say a guest WiFi and even if we reorder so the employee WiFi is top of the list the Mac remembers it last connected to the guest WiFi and will still reconnect to that despite the change in order.

The only definite way so far I have found to get it to switch to the employee one is as per the other type of script which is to delete and rejoin an SSID. Unfortunately as I mentioned the employee one is using WPA2 Enterprise with individual usernames and passwords so that is impossible to script.

I have tried things like marking the guest WiFi entry as either temporarily or permanently disabled (in the plist) and while these also are recognised in the System Preferences display the Mac still connects to the last choice i.e. the guest WiFi.

@lockwojo If you just turn Wi-Fi off and back on again after re-ordering the list does it re-connect to the 1st one, or does it still seek out the Guest network? And what version(s) of macOS are you seeing the persistent Guest Wi-Fi issue on?

@sdagley Turning WiFi off and on even after running your script to reorder the list results in it connecting to the last used WiFi network i.e. the guest one. Even a reboot leaves it connecting to the last used WiFi i.e. Guest.

The Mac I am testing the script on is running Mojave 10.14.6 but we will soon be upgrading to Catalina.

@lockwojo That is definitely not he behavior I'd expect. If you run Console.app on that Mac, and look at wifi.log under /var/log is there any clue as to what SSIDs are being tried?

@sdagley I started off with the Mac connected to the guest network and two saved WiFi networks one of which was the guest and the other the employee network. I ran your script and it did reorder the list.

I then turned WiFi off and then back on. As before it reconnected to the guest WiFi even though after reordering the employee one was top of the list. The relevant section from the wifi.log is below.

Fri Feb 14 16:13:17.716 <kernel> Unexpected payload found for message 4, dataLen 16
Fri Feb 14 16:13:17.716 <kernel> payload Data 04 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 
Fri Feb 14 16:13:17.718 <kernel> AppleBCMWLANCore::getSSIDData(): Get failure: APPLE80211_IOC_SSID: -528342013
Fri Feb 14 16:13:17.744 <kernel> IO80211VirtualInterface::handleSIOCSIFFLAGS : Source handleIoctlGated calling peerManager->disable
Fri Feb 14 16:13:17.745 <kernel> IO80211VirtualInterface::handleSIOCSIFFLAGS : Source handleIoctlGated calling peerManager->disable
Fri Feb 14 16:13:17.748 <airportd[181]> _handleLinkEvent: WiFi is not powered. Resetting state variables.
Fri Feb 14 16:13:17.900 <airportd[181]> _ipv6EventCallback: Unable to update NDP offload settings (Device power is off)
Fri Feb 14 16:13:17.908 <airportd[181]> _processIPv4Changes: Unable to update ARP offload settings (Device power is off)
Fri Feb 14 16:13:34.102 <kernel> IO80211VirtualInterface::handleSIOCSIFFLAGS : Source handleIoctlGated calling peerManager->enable
Fri Feb 14 16:13:34.537 <kernel> Unexpected payload found for message 4, dataLen 16
Fri Feb 14 16:13:34.538 <kernel> payload Data 04 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 
Fri Feb 14 16:13:34.582 <airportd[181]> ERROR: sharingd (598) is not entitled for com.apple.wifi.join_history, will not allow request
Fri Feb 14 16:13:34.582 <airportd[181]> ERROR: rapportd (500) is not entitled for com.apple.wifi.join_history, will not allow request
Fri Feb 14 16:13:34.625 <airportd[181]> ERROR: sharingd (598) is not entitled for com.apple.wifi.join_history, will not allow request
Fri Feb 14 16:13:34.625 <airportd[181]> ERROR: rapportd (500) is not entitled for com.apple.wifi.join_history, will not allow request
Fri Feb 14 16:13:34.640 <airportd[181]> ERROR: sharingd (598) is not entitled for com.apple.wifi.join_history, will not allow request
Fri Feb 14 16:13:34.642 <airportd[181]> ERROR: rapportd (500) is not entitled for com.apple.wifi.join_history, will not allow request
Fri Feb 14 16:13:34.660 <airportd[181]> ERROR: rapportd (500) is not entitled for com.apple.wifi.join_history, will not allow request
Fri Feb 14 16:13:34.661 <airportd[181]> ERROR: sharingd (598) is not entitled for com.apple.wifi.join_history, will not allow request

This covers turning it off and then back on. When turned back on it reconnected to the guest network which was the last active network but is now bottom of the list.

Both networks have credentials saved on the Mac. The guest is a simple WPA2 Personal setup, the employee one is a WPA2 Enterprise setup.

@sdagley I found another command that initially looked promising.

sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport prefs

This lists various settings including 'JoinMode', one of the choices for JoinMode is 'Preferred' which implies being able to set it to use the preferred i.e. first in the list SSID to connect. One can alter this setting as follows.

sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport prefs JoinMode=Preferred

Unfortunately this also does not seem to make any difference. It still reconnects using the last selected SSID i.e. the guest one.

Even unticking 'auto-join' in System Preferences for the guest network is not being obeyed.

Perhaps Mojave 10.14.6 (18G3020) has broken something?

Ok, I built a fresh test computer with both High Sierra and Mojave. It works as desired/expected in that the order of networks is obeyed. I am going to wipe and rebuild this test Mac.

This Mac is a fully built/configured one including being enrolled in to Jamf although there is no setting from Jamf that should affect this.

@sdagley @cbrewer Ok my original test device was a MacBook Pro 15" 2018 model with T2 chip. This one even after a full erase and reinstall of Mojave still persists in ignoring the WiFi order and reconnecting to whatever was the last selected network - if available. Again it ignores options like turning off auto-join on the guest network.

Two other Macs, a Mac mini 2014 and a MacBook Pro 15" 2017 model both also with fresh Mojave 10.14.6 installs behaved properly and did respect the order listed in System Preferences. Neither of these models has a T2 chip.

I did confirm it was nothing to do with FileVault or Jamf. I will see if I can find another T2 Mac or a 2018 MacBook. If this is just newer models I will report it to Apple although these days they are unlikely to fix this sort of bug. :(

@lockwojo Thanks for doing the research on this.

@sdagley Ok good and bad news.

The bad news, the problem only affects Mojave on T2 equipped Macs or at least of the models I have tried the only model that was affected was the MacBook Pro 15" 2018 model when running Mojave. (I currently don't have access to any other T2 equipped models.) A MacBook Pro 15" 2017 which does not have a T2 chip was not affected when running Mojave nor was a Mac mini 2014 which also does not have a T2 chip.

The good news, the same MacBook Pro 15" 2018 model with T2 chip running Catalina works properly!

Sadly the chances of Apple fixing this for Mojave are pretty close to zero although I might still report it.

@sdagley One final thing, I tried initially to create a LaunchDaemon or LaungAgent to trigger running your script at boot but it did not work. It is possible I made a mistake in the launchctl plist but I ended up using https://github.com/chilcote/outset which I use for other stuff and this worked.

My suspicion is that some Python frameworks are not available to launchctl.

How do you automate running it if at all?

@lockwojo I finally looked into this a bit.

I'm seeing that this issue with Mojave T2 Macs isn't related to the wireless order script. I see the same issue when manually changing the wireless network order in System Prefs > Network.

@lockwojo As I recall I had a policy in Jamf Pro to run the policy daily. I also had another script that ran locally on student machines via a LaunchDaemon triggered by a network change that would look to see if the active SSID was the campus SSID, and if not, and the SSID was available, would switch to it.

@cbrewer
Yes it happens both with the script and when done manually via System Preferences. The only thing T2 models will do regardless of options tried is use the last selected network. (If available.) As mentioned this only happens in Mojave.