Skip to content

Conversation

@pronebird
Copy link
Collaborator

@pronebird pronebird commented Aug 16, 2024

  • Add two-hop WireGuard integration for iOS
  • Rework OSTunProvider to match the system API available on iOS for configuring tunnel interface, routes, dns etc..
  • Add custom runner for wireguard on iOS. I am hoping we can harmonize the overall implementation between desktop and mobile but I have no energy to do that right now as the scope is only growing.

@pronebird pronebird force-pushed the wg-two-hop branch 5 times, most recently from 68b73dc to 71ca1d8 Compare August 16, 2024 18:33
@pronebird pronebird force-pushed the wg-two-hop branch 8 times, most recently from 7f1b304 to e268f75 Compare August 21, 2024 15:49
@github-actions github-actions bot requested a review from zaneschepke August 21, 2024 15:49
@pronebird pronebird force-pushed the wg-two-hop branch 10 times, most recently from 2cbe126 to a1d9fdf Compare August 23, 2024 11:23
@pronebird pronebird self-assigned this Aug 23, 2024
@pronebird pronebird force-pushed the wg-two-hop branch 7 times, most recently from 52929aa to 41eb97c Compare August 29, 2024 15:05
@pronebird pronebird marked this pull request as ready for review August 29, 2024 15:34
@pronebird pronebird changed the title WIP: Add wg two hop for iOS Add two-hop WireGuard for iOS Aug 29, 2024
@github-actions github-actions bot requested a review from zaneschepke August 29, 2024 16:02
@github-actions github-actions bot requested a review from zaneschepke August 29, 2024 16:24
@github-actions github-actions bot requested a review from zaneschepke August 29, 2024 17:46
@pronebird pronebird force-pushed the wg-two-hop branch 4 times, most recently from 685753d to 6d3b46d Compare August 30, 2024 16:03
@pronebird
Copy link
Collaborator Author

@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.

Copy link
Contributor

@octol octol left a 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
Copy link
Contributor

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).

Copy link
Collaborator Author

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"
Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would be ideal 👍

Copy link
Collaborator Author

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] = [
Copy link
Contributor

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?

Copy link
Collaborator Author

@pronebird pronebird Sep 2, 2024

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 {
Copy link
Contributor

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

Copy link
Collaborator Author

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};
Copy link
Contributor

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

Copy link
Collaborator Author

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 {
Copy link
Contributor

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());
Copy link
Contributor

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 ...

Copy link
Collaborator Author

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;
Copy link
Contributor

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()

Copy link
Collaborator Author

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)]
Copy link
Contributor

@octol octol Aug 30, 2024

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?

Copy link
Collaborator Author

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.

@pronebird pronebird merged commit 3e61c8d into main Sep 2, 2024
@pronebird pronebird deleted the wg-two-hop branch September 2, 2024 09:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants