search

gluxon / wireguard-uapi-rs

MIT License
31 stars 9 forks source link

Userspace implementations support #10

Closed MagicRB closed 3 years ago

MagicRB commented 4 years ago

Do you want to also include transparent support for userspace implementations? If yes, then I could try to figure it out and submit a PR, but no promises

EDIT: getting stuff from userspace should be easy, there are actual docs on this

MagicRB commented 4 years ago

After studying the source code a bit, I think we should create a trait, something like WireguardInterface, and then implement all the different types (2 currently, 3 if you count the android way), as for interface discovery, I think we should implicitly try all methods, and list the interfaces with the particular type of said interface. Or we could keep an internal mapping of interface and type, and dispatch the settings to the proper implementation, or we could ask the user, with an enum or something. Or we could have it both ways, a lower level trait based API, and a higher level, try everything and see what works API

gluxon commented 4 years ago

Do you want to also include transparent support for userspace implementations?

Yes definitely.

If yes, then I could try to figure it out and submit a PR, but no promises

I'll take a first stab at this in the next few days and give an update Tuesday 5/26.

Thanks for the suggestions on approach. I do think some kind of WireguardPlatformInterface trait makes sense.

MagicRB commented 4 years ago

:+1: If you need any help, or opinion or something, I'm your man.

gluxon commented 4 years ago

Quick update:

An initial version that just reads from Unix userspace implementations is on the userspace-implementation branch. It's not ready for public use and I wouldn't look at it yet. A few things still need to be done.

  1. This was a prototype version that uses .unwrap()/panic! rather than proper error propagation.
  2. Reading works, but updating/setting still needs to be done.
  3. It looks like IPv6 endpoints can have a scope ID. SocketAddrV6 doesn't handle this.
  4. Use a named pipe on Windows. (Instead of a unix socket.)
  5. Introduce some new traits to make the netlink and userspace sockets easier to interchangeably use. This will require a lot of thinking.

I'd estimate that this issue is about another 2 weeks away from being closed.

Or we could have it both ways, a lower level trait based API, and a higher level, try everything and see what works API

Just as a heads up: I am leaning towards a less auto-magical approach to start where users of this library will have to decide whether they want to talk to a userspace implementation or to the Linux kernel through netlink. Later on it might be useful to abstract this and choose the right communication channel given a non-conflicting interface name.

QuentinI commented 3 years ago

Hello! I would love to see this implemented; so I wanted to ask whether you are going to have time and desire to continue this, and if not, are you willing to accept/discuss a PR continuing or reimplementing your efforts on this?

gluxon commented 3 years ago

@QuentinI Sorry for the delays here. There's a work in progress PR from a few months ago. It'll be my top priority today and tomorrow to get it released.

gluxon commented 3 years ago

@QuentinI @MagicRB The userspace-implementation branch has a beta that can be used. I'm going to finish documentation and additional testing later this week. (Although the weekend is more likely since that's when I'll be free again.)

In lieu of better documentation, the example I was working off of is probably the best place to start if anyone is interested in beta testing. https://github.com/gluxon/wireguard-uapi-rs/blob/userspace-implementation/examples/userspace.rs

The API on this branch may change in the future. Happy for any kind of feedback.

xtexChooser commented 2 years ago

So it is available in the main branch now?

gluxon commented 2 years ago

Yup! The API could be better merged with the Linux-specific client though.