(Supersedes #1944)
* Fixes https://github.com/firezone/product/issues/649
* Passes `dns_fallback_strategy` over FFI (these are hardcoded for now)
* Incorporates @conectado 's #1944 and cleans up a few places `fd` was
still passed
Draft for now until I can test it more tomorrow
---------
Co-authored-by: conectado <gabrielalejandro7@gmail.com>
* Refactor sharedPreferences to only save the AccountId
* Update TeamId -> AccountId to match naming elsewhere
* Update JWT -> Token to avoid confusion; this token is **not** a valid
JWT and should be treated as an opaque token
* Update FFI `connect` to accept an optional file descriptor (int32) as
a first argument. This seemed to be the most straightforward way to pass
it to the tunnel stack. Retrieving it via callback is another option,
but retrieving return vars with the `jni` was more complex. We could
have used a similar approach that we did in the Apple client
(enumerating all fd's in the `new()` function until we found ours) but
this approach is [explicitly
documented/recommended](https://developer.android.com/reference/android/net/VpnService.Builder#establish())
by the Android docs so I figured it's not likely to break.
Additionally, there was a thread safety bug in the recent JNI callback
implementation that consistently crashed the VM with `JNI DETECTED ERROR
IN APPLICATION: use of invalid jobject...`. The fix was to use
`GlobalRef` which has the explicit purpose of outliving the `JNIEnv`
lifetime so that no `static` lifetimes need to be used.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Pratik Velani <pratikvelani@gmail.com>
Co-authored-by: Gabi <gabrielalejandro7@gmail.com>
This PR fixes issues with the iOS client connecting to the portal and
setting up the tunnel.
- portal IPv6 unique-local prefix typo
- Use `rustls-webpki-roots` instead of `rustls-native-roots` for tokio
tungstenite since the latter [only supports macOS, Linux, and
Windows](https://github.com/rustls/rustls-native-certs) while the former
seems to work on all platforms(?)
- Remove Multipath TCP entitlement for iOS since it's not relevant for
us.
@conectado After this is merged, we _almost_ have a working tunnel on
iOS. I believe the error we're hitting now is the 4-byte address family
header that we need to add and strip from each packet written to / read
from the tunnel. See below log for sample output when attempting to
connect to the `HTTPbin` resource:
```
dev.firezone.firezone.network-extension packet-tunnel debug 16:10:13.401705-0700 FirezoneNetworkExtensioniOS Adapter state changed to: tunnelReady
dev.firezone.firezone.network-extension packet-tunnel debug 16:10:13.401731-0700 FirezoneNetworkExtensioniOS Beginning path monitoring
com.apple.network path default 16:10:13.402211-0700 FirezoneNetworkExtensioniOS nw_path_evaluator_start [1ACDE975-615B-4557-BF7C-678F3594452E <NULL> generic, multipath service: 1, attribution: developer]
path: satisfied (Path is satisfied), interface: en0[802.11], scoped, ipv4, ipv6, dns
com.apple.network path info 16:10:13.402235-0700 FirezoneNetworkExtensioniOS nw_path_evaluator_call_update_handler [1ACDE975-615B-4557-BF7C-678F3594452E] scheduling update
com.apple.network path info 16:10:13.402261-0700 FirezoneNetworkExtensioniOS nw_path_evaluator_call_update_handler_block_invoke [1ACDE975-615B-4557-BF7C-678F3594452E] delivering update
com.apple.network debug 16:10:13.402286-0700 FirezoneNetworkExtensioniOS nw_path_copy_interface_with_generation Cache miss for interface for index 3 (generation 4574)
com.apple.network debug 16:10:13.402312-0700 FirezoneNetworkExtensioniOS nw_path_copy_interface_with_generation Cache miss for interface for index 31 (generation 141)
dev.firezone.firezone.network-extension packet-tunnel debug 16:10:13.402363-0700 FirezoneNetworkExtensioniOS Suppressing calls to disableSomeRoamingForBrokenMobileSemantics() and bumpSockets()
dev.firezone.firezone connlib debug 16:10:14.368105-0700 FirezoneNetworkExtensioniOS Reading from iface 76 bytes
dev.firezone.firezone connlib debug 16:10:15.369018-0700 FirezoneNetworkExtensioniOS Reading from iface 76 bytes
dev.firezone.firezone connlib debug 16:10:16.095618-0700 FirezoneNetworkExtensioniOS Reading from iface 76 bytes
dev.firezone.firezone connlib debug 16:10:16.370908-0700 FirezoneNetworkExtensioniOS Reading from iface 76 bytes
dev.firezone.firezone connlib debug 16:10:17.372035-0700 FirezoneNetworkExtensioniOS Reading from iface 76 bytes
dev.firezone.firezone connlib debug 16:10:18.373423-0700 FirezoneNetworkExtensioniOS Reading from iface 76 bytes
dev.firezone.firezone connlib debug 16:10:20.402863-0700 FirezoneNetworkExtensioniOS Reading from iface 76 bytes
dev.firezone.firezone connlib debug 16:10:24.381581-0700 FirezoneNetworkExtensioniOS Reading from iface 76 bytes
dev.firezone.firezone connlib debug 16:10:32.374566-0700 FirezoneNetworkExtensioniOS Reading from iface 76 bytes
dev.firezone.firezone connlib debug 16:10:38.137437-0700 FirezoneNetworkExtensioniOS Text("{\"ref\":null,\"topic\":\"phoenix\",\"event\":\"phx_reply\",\"payload\":{\"status\":\"ok\",\"response\":{}}}")
dev.firezone.firezone connlib debug 16:10:38.137757-0700 FirezoneNetworkExtensioniOS Phoenix status message
dev.firezone.firezone connlib debug 16:10:48.376339-0700 FirezoneNetworkExtensioniOS Reading from iface 76 bytes
dev.firezone.firezone connlib debug 16:11:08.148369-0700 FirezoneNetworkExtensioniOS Text("{\"ref\":null,\"topic\":\"phoenix\",\"event\":\"phx_reply\",\"payload\":{\"status\":\"ok\",\"response\":{}}}")
dev.firezone.firezone connlib debug 16:11:08.148654-0700 FirezoneNetworkExtensioniOS Phoenix status message
```
This is a result of our discussion with @conectado, this PR will add a
new message type which will allow reusing existing connections to the
gateway to access a new resource. We will also change the LB strategy to
be aware of the current device connection so that we will not pick a
different one if we have a connected gateway that can serve a new
resource.
---------
Co-authored-by: conectado <gabrielalejandro7@gmail.com>
The biggest internal change is that all the methods on `Callbacks` (on
the Rust side!) return a `Result` now, so errors from the bridge or even
the client callbacks will be handled.
@roop there's nothing for you to review here, but note:
- the `bool` return values you've asked about in the past are gone now
- the route string for `onAddRoute`/`onRemoveRoute` no longer has the
extra quotes (it's no longer JSON)
---------
Signed-off-by: Francesca Lovebloom <franlovebloom@gmail.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
As per discussion from the client sync,
- this removes `TunnelAddresses` in favor of simply passing the IPv4 and
IPv6 addresses as two separate strings.
- this changes `onDisconnect`'s semantics to be called _after_
disconnect instead of before.
Additionally, as per earlier discussion, errors are now passed as
strings. These errors already weren't intended to be actionable on the
client side, so the ability to handle them programmatically is
unnecessary. When internationalization is added down the road, we'll
likely replace these with error codes for looking up localized strings;
until then, this design improves diagnostics and reduces complexity.
Closes#1796Closes#1822
Addresses one of the issues raised in firezone/product#634
Previously, we were joining a `Vec` of serialized JSON objects into a
comma-separated string, which isn't valid JSON. Now the entire thing is
simply serialized, `Vec` and all.
Additionally, I've moved serialization to happen just before the FFI
boundary, which removes some indirection from connlib and will avoid a
deserialization step when writing non-FFI clients.
Resolvesfirezone/product#619
This additionally removes `ErrorType`:
- `on_error` is now exclusively used for recoverable errors, and no
longer has an `error_type` parameter.
- `on_disconnect` now has an optional `error` parameter, which specifies
the fatal error that caused the disconnect if relevant.
With this PR the full control-plane message flow is working.
Meaning that if you do:
```
docker compose up -d
docker compose exec -it client "ping 172.20.0.2" # will fix this IP later
```
Messages start flowing to gateway. The gateway still not correctly
forwards the messages to the resource since masquerading is still not
working, although I suspect there might be an additional problem. Will
fix this in my next PR along with a README on how to test this whole
flow.
This PR also fixes how we sent the stamp secret to the gateway from the
relay, but I still see some warnings in the webrtc that I'm sure that
are due to a mismatch between how webrtc-rs and the relay handle
messages (The most important being `bind() failed: unexpected response
type`), I will take a look at that and a way to test that the flow works
when:
1. hole-punching is available
2. through relay when it's not
Since the flow right now works without hole-punching or relay since the
gateway is in the same network in the docker compose.
Resolvesfirezone/product#607
Setting the env var `CONNLIB_MOCK` when building through either
`build-rust.sh` or `gradle` will activate the `mock` feature.
- Instead of having two, very similar jobs, we run our fmt, clippy and
tests steps across all crates and operating systems.
- We remove the dependency of the android and apple builds on the tests
and thus get faster feedback.
- We force clippy to fail on any warning. This one is super important
IMO. Warnings in Rust are very useful and ignoring them can lead to bugs
(think "unused Result" etc).
Resolves#1714.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Francesca Lovebloom <franlovebloom@gmail.com>
This makes it possible to build the Apple/Android FFI bridges and
integrate them with their respective client apps.
---------
Signed-off-by: Francesca Lovebloom <franlovebloom@gmail.com>
Co-authored-by: Roopesh Chander <roop@roopc.net>
This brindgs connlib from its own separated repo to firezone's monorepo.
On top of bringing connlib we also add and unify the Dockerfile for all
rust binaries and add a docker-compose that can run a headless client, a
relay and a gateway which eventually will test the whole flow between a
client and a resource. For this to work we also incorporated some elixir
scripts to generate portal tokens for those components.
