mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 18:18:55 +00:00
daf05b8c79
In order to detect network changes on Windows, we implement the `INetworkEvents` callback interface. This callback notifies us every time the connectivity of a certain network changes. Performing a network reset in connlib on any of these changes hurts the user experience as Firezone is booting because it takes a while for this to settle. Firezone itself is making changes to the network so several of these change events happen _because_ Firezone is starting. The documentation from Microsoft on what possible values the `NameType` attribute can have is pretty thin but I did manage to find the following values on the Internet: - `6`: Wired network - `71`: Wireless network - `243`: Broadband network We assume that the user is connected to the Internet through one of these so we ignore network changes on all other networks. An alternative approach to reducing the number of false-positive change events would be to react to a narrower list of change events. I discarded this approach because it wasn't clear to me, which of the event types [0] would matter to us and when Windows emits them. I think in order to effectively react to those, we'd have to do more fine granular tracking of which state a network is in and e.g. only trigger a reset if we move from "Disconnected" to e.g. "Subnet connectivity". Windows also differentiates between local, subnet and Internet connectivity, yet in my testing, I've never observed the "Internet" connectivity being emitted. Hence, it is deemed more robust to just filter out networks based on their type. Firezone itself is of type 53 and is therefore automatically filtered out as well. The risk here is that we don't react to connectivity changes of a network that a customer is relying on. Unfortunately, I don't think there is a better way to find this out other than shipping this change and waiting for reports. [0]: https://learn.microsoft.com/en-us/windows/win32/api/netlistmgr/ne-netlistmgr-nlm_connectivity#constants --------- Signed-off-by: Thomas Eizinger <thomas@eizinger.io>