We now get a warning when switching over enums from system
frameworks even when we handle all public cases because
there can be future cases that aren't handled.
When such a future case is introduced, we'll get a warning.
I worry that LSMinimumSystemVersion in the extension's plist might be
problematic, since that same plist runs on macOS and iOS. We _might_
need to bifurcate.
- Build using common network extension code
- Add run scripts
- Set Info.plist to common network extension's Info.plist
- Move entitlements to common network extension folder
- Remove Xcode-generated macOS network extension code
- Set Swift-Obj-C bridging header
The DNS resolver prior had useless comments, awful nesting, converted
bytes into strings and back into bytes, and generally made no sense.
That's been rewritten now.
But more fundumentally, this commit made the DNS resolver actually
accomplish its objective, by passing AI_ALL to it. It turns out, though,
that the Go library isn't actually using GAI in the way we need for
parsing IP addresses, so we actually need to do another round, this time
with hints flag as zero, so that we get the DNS64 address.
Additionally, since we're now binding sockets to interfaces, we can
entirely remove the excludedRoutes logic.
The solution implemented in commit b8c331c causes the tunnel to
remain in 'Activating' state, without the ability to cancel that.
So, in this commit, instead of retrying DNS silently on
Activated-On-Demand tunnels, we fail the startTunnel() silently.
To summarize, if activate-on-demand is on:
- If started from the WireGuard app, show error using lastErrorFile
mechanism, suggesting a way to turn off Activate On Demand
- If not started from WireGuard app, don't call displayMessage()
(don't show error to user) and silently fail starting the tunnel
This combination causes iOS to keep trying to bring up the tunnel,
leading to a lot of displayMessage() alerts.
In this fix, if we get a DNS resolution error in an Activate On Demand
enabled tunnel, we silently retry 9 times (with a 4-second delay before
each retry) and then show the displayMessage() alert.
Roopesh Chander
Jason A. Donenfeld
Eric Kuck