Currently, a failure during DNS resolution results in the client hanging
during the connection setup. Instead, we fall back to an empty list
which results in an empty DNS query result for the client.
That in turn will make most application consider the DNS request failed.
As far as I know, we don't currently retry these DNS requests, meaning a
user would have to sign-in and out again to fix this state.
Whilst not ideal, I think this is a better behaviour and what we
currently have where the initial connection just hangs.
Currently, we need to wait for the timeout of the current candidate pair
during `reconnect` before we nominate a new one. To speed this up, we
can preemptively invalidate candidates we have previously discovered via
our `Allocation`s, i.e. relay candidates and srflx candidates.
This is done to fix a bug where the file descriptor is unregistered from
the reactor after the new `Tun` struct is created if the old one is
dropped after.
You know what I want, when I'm waiting 15-60 minutes on a CI job?
I want a stringly-typed language
I want the compiler to do
as
little
work
as
possible
If there even _is_ a compile step. Cause I love waiting and squinting at
underscores.
Running as sudo / root causes a lot of problems for GUI programs, so
we're unwinding that. In this case we can go back to using Tauri's "open
URL" function, which is great.
Closes#4103
Refs #3713
Affects #3972 - I was finally able to debug it because it came up
constantly during this PR
Refs #3713
```[tasklist]
### Before merging
- [ ] Is 'firezone-client-tunnel' okay for the binary name?
- [ ] Using a library and building it as two binaries is correct, right? `cargo run -p firezone-client-tunnel` takes 1 second. `cargo run -p firezone-gui-client --bin firezone-client-tunnel` takes 1m42s because it builds all the GUI deps.
```
Fixes#4042
The serial number of the device is blocked behind a permission. There's
a couple ways we can go about this:
-----
### (1) Ask the user to (optionally) grant the permission
When we show the grant VPN permission activity, we also mention the
optional READ_PRIVILEGED_PHONE_STATE permission. Here, the user can
decide to grant it or not, and if they decide not to, they can grant it
in the future in the app settings. When the permission is not granted,
the `deviceName` falls back to the `Build.MODEL`
### (2) Force the user to grant the permission
We keep asking them to grant the permission in the splash view.
`deviceName` is always the serial number of the device.
### (3) Let MDM grant the permission
We don't provide a UI to grant the permission in the application.
Instead, the `deviceName` is the `Build.MODEL` by default, unless
advanced users or admins using MDM set the permission, in which case
it's the serial number of the device.
### (4) Let MDM set a custom/override device name
This could be an alternative to (3) if it is easier for customers using
MDM software to manage it this way. Though I doubt it...
-----
Going with option (3) is safe, and the other options can be added
incrementally in the future. However, it requires communicating to the
customer that they should set this permission for the `deviceName` to be
the serial of the device. That's not a problem yet, since the relevant
customer is using MDM to manage the app; it's trivial to set this
permission via that UI.
If we did want to show this permission to the user, I think option (1)
is most likely going to be better than option (2) in most cases.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
This was discovered as part of
https://github.com/firezone/firezone/pull/4213. When we reconnect to the
portal, we first need to join the correct room before sending any
messages to it. For example, as a client, we need to join the `client`
room before sending messages in it.
This implementation is meant to be a quick fix. The "proper" solution
would be to keep track of which rooms we have joined and reset that upon
reconnect. Introducing such a state machine is a much larger refactoring
that is likely not going to make much of a difference for now because we
only join a fixed number of rooms and that will usually succeed.
I thought this was going to use `cargo-deb` but it was actually easy
with the Tauri deb bundling we already use.
```[tasklist]
### Before merging
- [x] Make sure every file in the Tauri deb is also in our deb (e.g. icons)
```
Currently, an error returned by `Tunnel::poll_next_event` is only
logged. In other words, they are never fatal. This creates a tricky to
understand relationship on what kind of errors should be returned from
callbacks. Because connlib is used on multiple operating systems, it has
no idea how fatal a particular error is.
This PR removes all of these `Result` return values with the following
consequences:
- For Android, we now panic when a callback fails. This is a slight
change in behaviour. I believe that previously, any exception thrown by
a callback into Android was caught and returned as an error. Now, we
panic because in the FFI layer, we don't have any information on how
fatal the error is. For non-fatal errors, the Android app should simply
not throw an exception. The panics will cause the connlib task to be
shut down which triggers an `on_disconnect`.
- For Swift, there is no behaviour change. The FFI layer already did not
support `Result`s for those callbacks. I don't know how exceptions from
Swift are translated across the FFI layer but there is no change to what
we had before.
- For the Tauri client:
- I chose to log errors on ERROR level and continue gracefully for the
DNS resolvers.
- We panic in case the controller channel is full / closed. That should
really never happen in practice though unless we are currently shutting
down the app.
Resolves: #4064.
Bumps [clap](https://github.com/clap-rs/clap) from 4.5.2 to 4.5.3.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/clap-rs/clap/releases">clap's
releases</a>.</em></p>
<blockquote>
<h2>v4.5.3</h2>
<h2>[4.5.3] - 2024-03-15</h2>
<h3>Internal</h3>
<ul>
<li><em>(derive)</em> Update <code>heck</code></li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/clap-rs/clap/blob/master/CHANGELOG.md">clap's
changelog</a>.</em></p>
<blockquote>
<h2>[4.5.3] - 2024-03-15</h2>
<h3>Internal</h3>
<ul>
<li><em>(derive)</em> Update <code>heck</code></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="4e07b43858"><code>4e07b43</code></a>
chore: Release</li>
<li><a
href="8247c7ddf0"><code>8247c7d</code></a>
docs: Update changelog</li>
<li><a
href="677c52ce08"><code>677c52c</code></a>
chore: Update <code>heck</code> requirement (<a
href="https://redirect.github.com/clap-rs/clap/issues/5396">#5396</a>)</li>
<li>See full diff in <a
href="https://github.com/clap-rs/clap/compare/v4.5.2...v4.5.3">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
AppImages won't work with process splitting. (#3713)
As far as I can tell, they just produce one binary. Internally they use
FUSE or something to mount a squashfs image, but that image won't be
able to hook into systemd and run with root permissions and everything.
I don't think it's practical, and Tauri's AppImage bundling doesn't have
the features for it.
Even their deb bundler doesn't have any way to specify a path for a
daemon to be installed. The sidecar feature only seems intended for the
GUI app to call, not anything else on the system.
(There is such a thing as installing AppImages, but I don't think it's
worth pursuing - We should just do debs)
Closes#3699 if successful
Ref #3972
I don't understand why it started working. There's at least 3
possibilities:
- Some unrelated change in the last few weeks fixed it (Maybe bumping
Tauri to 1.6.1? https://github.com/firezone/firezone/pull/3881)
- It was a bug in the Github CI runner image that they fixed
- It's an awful race condition and adding `tracing::debug!` fixed it
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
This example will work once our latest gateway is pushed to GitHub
Container Registry, but to test it for now a few overrides can be added
to the `main.tf` to use our Google Artifact Registry and local module
instead:
```diff
module "gateways" {
-- source = "github.com/firezone/firezone/terraform/modules/google-cloud/apps/gateway-region-instance-group"
++ source = "../../../modules/google-cloud/apps/gateway-region-instance-group"
...
++ container_registry = "us-east1-docker.pkg.dev"
++ image_repo = "firezone-prod/firezone"
++ image = "gateway"
}
```
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Signed-off-by: Andrew Dryga <andrew@dryga.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Previously, we used `SocketState::send` without wrapping it in
`UdpSocket::try_io`. This meant that tokio had no chance of clearing the
readiness flag on the socket when we actually failed to send a packet,
resulting in many log messages like this:
```
Tunnel error: Resource temporarily unavailable (os error 11)
```
This PR refactors how we send UDP packets and when we read IP packet
from the device. Instead of just polling for send-readiness, we flush
all buffered packets and _then_ check for send-readiness. That will only
succeed if we managed to send all buffered packets and the socket still
has space for more packets.
Typically, this buffer only has 1-2 packets. That is because we
currently only ever read a single packet from the device. See #4139 for
how this might change. It may have more packets when our `Allocation`s
emit some (like multiple channel bindings in a row). Because we enforce
further send-readiness before continuing, this buffer cannot grow
unbounded.
Resolves: #3931.
In the future we will want to refactor this to a builder pattern to
prevent the number of parameters from growing and have them clearer but
this works simply for now.
Found while discussing #4174
---------
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
With the move to SANS-IO, we will be able to write deterministic unit
tests for the tunnel logic. To actually do that, `ClientState` and
`GatewayState` need to encapsulate all the logic that we want to test.
This PR does some minor refactoring on the functions on `ClientTunnel`
and moves several of them onto `ClientState`. It doesn't touch
`add_resources` and `remove_resource` because those depend on #4156.
Dependabot doesn't seem to consider the `Package.resolved` lockfile for
updates, only Package.swift.
Dependabot security updates however flag us for outdated dependencies in
`Package.resolved`.
There doesn't seem to be a good workaround, so revert back to previous
behavior and update Package.resolved via Xcode until support gets
better.
Bumps
[follow-redirects](https://github.com/follow-redirects/follow-redirects)
from 1.15.4 to 1.15.6.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="35a517c586"><code>35a517c</code></a>
Release version 1.15.6 of the npm package.</li>
<li><a
href="c4f847f851"><code>c4f847f</code></a>
Drop Proxy-Authorization across hosts.</li>
<li><a
href="8526b4a1b2"><code>8526b4a</code></a>
Use GitHub for disclosure.</li>
<li><a
href="b1677ce001"><code>b1677ce</code></a>
Release version 1.15.5 of the npm package.</li>
<li><a
href="d8914f7982"><code>d8914f7</code></a>
Preserve fragment in responseUrl.</li>
<li>See full diff in <a
href="https://github.com/follow-redirects/follow-redirects/compare/v1.15.4...v1.15.6">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/firezone/firezone/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
