mirror of
https://github.com/outbackdingo/firezone.git
synced 2026-01-27 18:18:55 +00:00
0ded6ad79d
As part of handling an incoming packet, `snownet` has to go through several steps: 1. The packet might be a control message from a STUN server, we handle that first. 2. The packet might from a TURN server, which could either be a control message or a channel-data message. The former should be handled directly where as the latter needs to unpacked and passed along further. 3. Once potentially unpacked, the packet could be a STUN message for an ICE agent of one of our connections. 4. Lastly, the packet might be a wireguard payload from one of our connections. Previously, we handled all of that in one big function which resulted in us sometimes "falling through" to the next branch when we didn't want that. For example, if a message is from a TURN server's address, it MUST be a control or channel data message but it can never be a wireguard packet. In certain circumstances, we don't detect that though. For example, if a channel is not yet bound, we refuse to decapsulate the message which results in us incorrectly passing on the message to later stages. We refactor the handling into individual functions and explicitly signal to the upper layer using `ControlFlow`, whether we should continue or abort. As an added benefit, this allows us to remove the "memory" of timed-out control messages in `StunBinding` and `Allocation`.
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.