-
Notifications
You must be signed in to change notification settings - Fork 37
Add two-hop WireGuard for iOS #913
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
68b73dc to
71ca1d8
Compare
7f1b304 to
e268f75
Compare
2cbe126 to
a1d9fdf
Compare
52929aa to
41eb97c
Compare
685753d to
6d3b46d
Compare
|
@octol @neacsu @zaneschepke @rokas-ambrazevicius please leave your review early next week, preferably on Monday because we gotta move on with this and @zaneschepke is very close to bringing support for wg on android too. |
octol
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking great! Well done!
I left some side comments for stuff I noticed while reading the code, some which refers to code not touched by this PR. Feel free to do what you want with them
| run: | | ||
| cargo build --verbose --target aarch64-apple-ios -p nym-vpn-lib | ||
| rustflags="-L ${GITHUB_WORKSPACE}/build/lib/aarch64-apple-ios" | ||
| RUSTFLAGS=$rustflags cargo build --verbose --target aarch64-apple-ios -p nym-vpn-lib |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General comment not for this PR:
The platform stuff is really reaching a point where we should try to take a step back and rework it. Also I'm kinda think that this part here is the result of building both mac and ios during a single job while splitting them into separate seems likely more appropriate (like how android is separate from linux).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that's legit. Let's add a card for this and attack it in a separate PR.
| url: "https://github.com/nymtech/nym-vpn-client/releases/download/nym-vpn-core-v0.1.16/nym-vpn-core-v0.1.16_ios_universal.zip", | ||
| checksum: "41a5ecb8b0ab7cc2e6130179863761d12bcc988eda6c269cb00bd01a43449741" | ||
| url: "https://github.com/nymtech/nym-vpn-client/releases/download/nym-vpn-core-nightly/nym-vpn-core-v0.1.17-dev_ios_universal.zip", | ||
| checksum: "66a830cd46b912df1c11704b487f7a661299ff4583d142770ae04c0ceeaaad5c" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will break after the next nightly build?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will break. I believe this is a temp fix to get the Testflight out the door.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you need a custom build of the vpn lib that is non-temporary you can use a named tag like nym-vpn-core-ios-testflight. But maybe if we merge this on Monday we can create a new release core then and use that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That would be ideal 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we'll fix this with a follow up pr
| }, | ||
| }; | ||
|
|
||
| pub const DEFAULT_DNS_SERVERS: [IpAddr; 4] = [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick: separate config.rs file or similar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll do that in a separate PR to unblock folks that already base their work off this branch.
|
|
||
| /// Observer type that wraps network path changes into a channel. | ||
| #[derive(Debug)] | ||
| pub struct DefaultPathObserver { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this, wrapping channels in a strong type. Imho we should do this more often
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this struct implements OSDefaultPathObserver trait, making it a conduit for messages received via FFI boundary.
| @@ -0,0 +1,64 @@ | |||
| use tokio::sync::mpsc::{UnboundedReceiver, UnboundedSender}; | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side comment: for unbounded receivers/senders there is no confusion, but for bounded senders/receivers then the type has the same name for mpsc/broadcast/oneshot etc so it's nice to not import the whole path so it's easier to see in the code what channel it is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct. Bounded are different story.
| tracing::info!("User agent: {user_agent}"); | ||
|
|
||
| let generic_config = GenericNymVpnConfig { | ||
| mixnet_client_config: MixnetClientConfig { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated side comment: we should implement Default for MixnetClientConfig in the future
| }; | ||
|
|
||
| let bandwidth_controller = | ||
| BandwidthController::new(mixnet_client.clone(), self.task_manager.subscribe()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Side comment for the future:
Imho we should switch BandwidthController to use CancellationToken. Also, BandwidthController calls mixnet_client.disconnect() I just spotted, not sure what the implication of that is ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah what BandwidthController does is it seems that it just waits for task manager to shutdown before killing the mixnet client. I am not quite sure why it's done this way, this could be re-arranged.
| // Put in some manual error handling, the correct long-term solution is that handling | ||
| // errors and diconnecting the mixnet client needs to be unified down this code path | ||
| // and merged with the mix tunnel one. | ||
| mixnet_client.disconnect().await; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have a strong suspicion that this is a no-op since we pass in an external task_manager.subscribe() when creating the mixnet client, and the way to disconnect the mixnet_client is to call task_manager.signal_shutdown()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be, I ran out of time to investigate this any closer.
| } | ||
| } | ||
|
|
||
| #[derive(uniffi::Enum, Debug)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the thinking when deciding between placing stuff in this mod vs platform? Is platform something that will be phased out over time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simply a logical grouping of related types. Everything under mobile/ios in essence is a platform-specific stuff. I didn't want to move things too apart since it breaks connection between types.
Uh oh!
There was an error while loading. Please reload this page.