c48ed2a1a0
When Firezone detects that the user is switching networks, we perform an internal reset where we clear all connections and also all local candidates. As part of the reset, we then send STUN requests to our relays to re-discover our host and server-reflexive candidates. In this scenario, the Gateway is still connected to its network and is therefore able to send its candidates as soon as it receives the connection intent from the portal. This opens us up to the following race condition which leads to a false-positive "ICE timeout": 1. Client roams network and clears all local state. 2. Client sends STUN binding requests to relays. 3. Client initiates a new connection. 4. Gateway acknowledges connection. 5. Client creates new ICE agent and attempts to seed it with local candidates. We don't have a response from the relays yet and therefore don't have any local candidates. 6. Client receives remote candidates and adds them to the agent. 7. ICE agent is unable to form pairs and therefore concludes that it is disconnected. 8. We treat the disconnected event as a connection failure and clear the connection. 9. Relays respond to STUN binding requests but we cannot add the new candidates to the connection because it is already cleared. The ICE spec states that after an agent transitions into the "disconnected" state, it may transition back to "connected" if e.g. new candidates are added as those allow the forming of new pairs. In general, it is recommended to not treat "disconnected" as a permanent state. To honor this recommendation, we introduce a 2s grace-period in which we can recover from such a "disconnected" state.
Rust development guide
Firezone uses Rust for all data plane components. This directory contains the Linux and Windows clients, and low-level networking implementations related to STUN/TURN.
We target the last stable release of Rust using rust-toolchain.toml.
If you are using rustup, that is automatically handled for you.
Otherwise, ensure you have the latest stable version of Rust installed.
Reading Client logs
The Client logs are written as JSONL for machine-readability.
To make them more human-friendly, pipe them through jq like this:
cd path/to/logs # e.g. `$HOME/.cache/dev.firezone.client/data/logs` on Linux
cat *.log | jq -r '"\(.time) \(.severity) \(.message)"'
Resulting in, e.g.
2024-04-01T18:25:47.237661392Z INFO started log
2024-04-01T18:25:47.238193266Z INFO GIT_VERSION = 1.0.0-pre.11-35-gcc0d43531
2024-04-01T18:25:48.295243016Z INFO No token / actor_name on disk, starting in signed-out state
2024-04-01T18:25:48.295360641Z INFO null
Benchmarking on Linux
The recommended way for benchmarking any of the Rust components is Linux' perf utility.
For example, to attach to a running application, do:
- Ensure the binary you are profiling is compiled with the
releaseprofile. sudo perf record -g --freq 10000 --pid $(pgrep <your-binary>).- Run the speed test or whatever load-inducing task you want to measure.
sudo perf script > profile.perf- Open profiler.firefox.com and load
profile.perf
Instead of attaching to a process with --pid, you can also specify the path to executable directly.
That is useful if you want to capture perf data for a test or a micro-benchmark.