Alpaca doesn't always detect network changes

[smithjw]

I've found that alpaca doesn't always detect network changes (it's usually good about changing Wi-Fi networks, disconnecting/reconnecting), specifically connecting and disconnecting from VPN clients. Is there anything that could be done to improve its detection around these cases?

In my current environment (and at the last org I had it deployed), the way that I have solved for this is to deploy alpaca with both a LaunchAgent and a LaunchDaemon. The Agent would be responsible for launching alpaca on login and keep it running, while the Daemon would be configured with a WatchPaths to determine when GlobalProtect (current VPN client) wrote to a specific preferences file; this happens on connection and disconnection.

Once the Daemon is triggered, it would wait a couple seconds, then kickstart the Agent as the logged in user to restart alpaca. I'd love if I didn't have to package these additional pieces with alpaca to simplify things. Outside of this, the app does what it says and works great 😄.

[samuong]

Hi James, yes I think there is a way this be improved. The way it works today is that before every outgoing request, Alpaca checks the set of network interfaces, and if this changes then it re-checks the PAC URL. This worked fine initially when there was no VPN to connect to, but the set of network interfaces won't change when a VPN connection is made. I've become a bit too reliant on your LaunchDaemon and never got around to fixing this :)

I'm thinking we could use a similar approach to that taken by the myIpAddress() function as of #123 (released in v2.0.4), which now tries to detect the IP address of the internet-facing network interface. This does change when the VPN connection is made, so it would be a good check to make in addition to the set of network interfaces.

I'll give this a go over the next few days, is this something you could test on your end before it gets released?

[smithjw]

I won't lie, I'm also pretty reliant on the LaunchDaemon and it almost makes things so transparent that I forget it's doing its thing.

But from a technical-complexity point of view, removing the dependency of this LaunchDaemon and a bash script to kickstart the LaunchAgent would be a big win.

I'd still package it with the LaunchAgent, but that would be all :).

Once you've got something to test, let me know!

[samuong]

@smithjw that took a bit longer than I expected but I have an early PR up at #132. If it makes it any easier, you can download an pre-built macOS/arm64 binary from https://github.com/samuong/alpaca/actions/runs/10026602652/artifacts/1722894899 (or for other platforms, check out any of the "Run actions/upload-artifact@v4" steps the appropriate build job in https://github.com/samuong/alpaca/actions/runs/10026602652).

I've made a few assumptions about how your VPN client works, so it's possible that this doesn't fix it for your setup. If you have access to the go toolchain, are you able to check out the branch and run go test -run=TestDumpAddrs -v and let me know what it says? If you're not comfortable sharing network addresses, that's fine - just let me know if it gives different output when you're on/off the VPN? No worries if you can't, but if you can, this would help validate some of my assumptions.

[smithjw]

@samuong I've been using this version without my custom network watcher and things seem to just be working as expected :)