I have a few macros in mind, not sure if they're too complicated...
One macro would be an if/then based on whether the computer is currently connected to a VPN. (I mainly use ExpressVPN, in case that's helpful. It sits in my menu bar.)
Another macro would be an if/then based on whether the wireless networking is using one of a few different DNS servers. (Or, alternatively and perhaps easier, whether it's using DHCP.)
The final macro would be an if/then based on whether the computer is connected to one of a few different wireless networks, checking by name.
Macros can only be triggered by a very specific set of events and statuses.
Once a macro is triggered, we have nearly unlimited flexibility in terms of If/Then logic using various conditions. The Script condition quite powerfully allows the use of Shell, AppleScript, and more.
With that in mind:
I don't believe you can trigger a macro using VPN connection status. However, one option would be to create macros that enable/disable the VPN and then proceed with your other actions. I can't vouch for it, but a quick search supplied a CLI utility called expresso that may do the job. You could also see if ExpressVPN has an AppleScript dictionary.
I don't believe you can trigger a macro using DNS/DHCP status. However, you may be able to determine DNS servers or DHCP status via Shell script for use in a conditional.
Luckily, you can trigger a macro when connecting/disconnecting to a wireless network.
If you run into any issues once you get rolling on any of these, post your macros so we can take a look.
Thanks, @avtraino. I'm sorry if my original post suggested otherwise, but I'm not looking to trigger macros based on any of the items I mentioned. Rather, I'm looking to use them as conditions for "if/then" actions. (The triggers themselves would be manual, i.e. hotkeys.) Any suggestions on how this could be done? To give a few examples...
• "If ExpressVPN has a live VPN connection, then do [Option A], otherwise do [Option B]."
• "If computer's network is using one of the following DNS servers – [DNS server address #1], [DNS server address #2], [DNS server address #3] – then do [Option A], otherwise do [Option B]."
BTW, I see there is a %WirelessNetwork% token, which is useful for the third item I mentioned.
Here is a macro to get you started with both of those examples. The DNS bit should be ready to go, but the VPN bit will require you to determine what the possible values of "state" are and build actions out accordingly. I don't have ExpressVPN, so I wasn't able to get any further.
In case this helps your first point, I have a "VPN status" subroutine which uses the output of this Bash script (which calls the macOS scutil command) to determine whether the tunnel is up/down/borked.
if scutil --nc status Work | head -1 | egrep -q ^Connected; then if scutil --nc status Work | grep Router | grep -v -q ': ::'; then echo up; else echo suspended; fi; else echo down; fi
Note that I've named my VPN as "Work" - you'll need to check the output of scutil --nc list to find the name of yours (it should appear in double quotes).
Further options are available with scutil --nc help
I tried the method I linked to earlier in the example macro I posted, and it seems to be working fine (returning Cloudflare IP addresses for me) -- dig whoami.akamai.net +short
We're at the whim of Akamai, but I'm sure there are other services.
I looked into scutil for this and it doesn't seem to be guaranteed that every VPN service shows up as an interface (ExpressVPN might -- in that case, problem solved!).
I use Windscribe, and by default it doesn't appear in scutil or in Network Preferences. I wasn't able to figure out if/how macOS knows on a network level that Windscribe has a tunnel open.
(I don't need this functionality, but if anyone knows more and wants to share, I'd love to learn!)
Thanks so much @avtraino, and also @peternlewis and @coordinated. I've played around with this. The DNS servers in my Mac OS network settings are the ones recommended by Cloudflare...
However, the shell script @avtraino shared is returning the address 172.70.253.120. Any idea why this is happening? Maybe there's something I'm misunderstanding?
I played around with this script, and it seems ExpressVPN returns one of two states: "ready" when not connected to a VPN and "connected" when connected to a VPN. So easy enough, and seems to work!
Thanks for the heads up on this, @peternlewis! Just curious, is it just a matter of time before this token is working again? Or is it down for the count?
Apple changed Sonoma such that getting the wifi name requires Location permission.
Apple did not change Sonoma such that requesting the wifi name prompts for Location permission.
Apple has provided no way to manually add Location permission.
Keyboard Maestro does not use the Location system, so it has no way to poke the system to ask for location permissions, and there is no apparent way to do this manually. Apple's response so far has just been “well, add a call to ask for location then”, which is not exactly ideal, and defeats my efforts in ensuring older versions of Keyboard Maestro work properly on modern systems (for example, Keyboard Maestro 4.x still runs on Ventura, I haven't tested it on Sonoma, but it probably runs fine there too).
Coincidentally, I have already added a new action for Keyboard Maestro 11 to get the location, and so a solution (once I release that) will be to simply run that action once, it will request permission, and then the wifi facilities should work. And indeed, at that point you should be able to revert back to any previous version of Keyboard Maestro and the wifi facilities should continue to work there as well.
So I hope that Apple will fix this issue (either by allowing manually adding an application or by prompting for permission when the wireless API is used), but honestly I don't really expect them to. If they don't, then version 11 will have a solution, and it should be out in the not too distant future.
Ah, I misunderstood your intention (again...sorry about that).
1.1.1.1 is the user-facing IP address for their service. Your requests, however, pass through one of their nameservers close to you (geographically). whoami.akamai.net is returning the IP address of the nameserver it receives the request from.
This should return the values you see in macOS Network Preferences:
Thanks for the explanation, Peter! Sorry to hear Apple has been a bit of a pain on this, but good to hear that a fix is forthcoming one way or another.
