Kotlin's `spottlessApply` uses the EOL in this file, so it messes up all
line endings if running it from windows without this change.
I don't see a down-side on standardizing this to something fixed for all
platforms and since we're already using LF everywhere I think keeping it
seems like the best.
Our sockets need to be initialized within a tokio runtime context. To
achieve this, we don't actually initialize anything on `Sockets::new`.
Instead, we call `rebind` within the constructor of `Tunnel` which
already runs in a tokio context.
Fixes: #4282
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
```[tasklist]
### Before merging
- [x] Manual test of MSI from CI
```
Bumps
[tauri-winrt-notification](https://github.com/tauri-apps/winrt-notification)
from 0.1.3 to 0.2.0.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/tauri-apps/winrt-notification/releases">tauri-winrt-notification's
releases</a>.</em></p>
<blockquote>
<h2>tauri-winrt-notification v0.2.0</h2>
<p>Updating crates.io index</p>
<!-- raw HTML omitted -->
<pre><code>Fetching advisory database from
`https://github.com/RustSec/advisory-db.git`
Loaded 613 security advisories (from /home/runner/.cargo/advisory-db)
Updating crates.io index
Scanning Cargo.lock for vulnerabilities (15 crate dependencies)
</code></pre>
<!-- raw HTML omitted -->
<h2>[0.2.0]</h2>
<ul>
<li><a
href="1427bbfadc"><code>1427bbf</code></a>(<a
href="https://redirect.github.com/tauri-apps/winrt-notification/pull/18">#18</a>)
Update MSRV to <code>1.62</code></li>
<li><a
href="1427bbfadc"><code>1427bbf</code></a>(<a
href="https://redirect.github.com/tauri-apps/winrt-notification/pull/18">#18</a>)
Update <code>windows</code> crate to <code>0.54</code></li>
</ul>
<!-- raw HTML omitted -->
<pre><code>`\`\`
Updating crates.io index
Packaging tauri-winrt-notification v0.2.0
(/home/runner/work/winrt-notification/winrt-notification)
Updating crates.io index
Packaged 29 files, 82.9KiB (40.8KiB compressed)
Uploading tauri-winrt-notification v0.2.0
(/home/runner/work/winrt-notification/winrt-notification)
Uploaded tauri-winrt-notification v0.2.0 to registry `crates-io`
note: Waiting for `tauri-winrt-notification v0.2.0` to be available at
registry `crates-io`.
You may press ctrl-c to skip waiting; the crate should be available
shortly.
Published tauri-winrt-notification v0.2.0 at registry `crates-io`
</code></pre>
<!-- raw HTML omitted -->
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/tauri-apps/winrt-notification/blob/dev/CHANGELOG.md">tauri-winrt-notification's
changelog</a>.</em></p>
<blockquote>
<h2>[0.2.0]</h2>
<ul>
<li><a
href="1427bbfadc"><code>1427bbf</code></a>(<a
href="https://redirect.github.com/tauri-apps/winrt-notification/pull/18">#18</a>)
Update MSRV to <code>1.62</code></li>
<li><a
href="1427bbfadc"><code>1427bbf</code></a>(<a
href="https://redirect.github.com/tauri-apps/winrt-notification/pull/18">#18</a>)
Update <code>windows</code> crate to <code>0.54</code></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="e43754023c"><code>e437540</code></a>
Publish New Versions (<a
href="https://redirect.github.com/tauri-apps/winrt-notification/issues/19">#19</a>)</li>
<li><a
href="1427bbfadc"><code>1427bbf</code></a>
chore(deps): update <code>windows</code> crate to 0.54 (<a
href="https://redirect.github.com/tauri-apps/winrt-notification/issues/18">#18</a>)</li>
<li>See full diff in <a
href="https://github.com/tauri-apps/winrt-notification/compare/tauri-winrt-notification-v0.1.3...tauri-winrt-notification-v0.2">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>
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: ReactorScram <ReactorScram@users.noreply.github.com>
```[tasklist]
- [x] Ensure whatever method we use to read the DNS servers actually works here, and doesn't have a strange memory ordering problem. If it does, read them from the registry by hand.
- [x] Graceful exit
- [x] Error handling
- [x] Clean it up and integrate it with the Tauri client
- [x] Replace `Notify` with channel of size one
- [x] Remove `Arc`
- [x] Replace `close` with panics
- [x] Remove `Pin`
- [x] Unit-test what happens if we register with RegNotify, close the handle, then modify our key
- [x] Merge with main and call `set_dns`
```
Previously, we would lose one message to the portal upon failing to send
it. We now mitigate this in two ways:
1. We also check the error from `poll_ready` and don't even pop a
message off from our buffer.
2. If sending still fails, we re-queue it to the front of the buffer.
In certain scenarios as discovered in logs from #4058, this might have
caused a loss of the "answer" message from a gateway to the client,
resulting in a state mismatch where the gateway thinks the connection is
established and the client times out on waiting for the answer.
This updates connlib to follow the new guidelines described in #4262. I
only made the bare-minimum changes to the clients. With these changes
`reconnect` should only be called when the network interface actually
changed, meaning clients have to be updated to reflect that.
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.
