Rust implementation status

Rust implementation status

[Sascha Grunert]

Hey folks,

I want to call for participation of the Rust userspace implementation of =
WireGuard. The template for the initial implementation was this: =
https://www.wireguard.io/xplatform/ and can be found here: =
https://git.zx2c4.com/wireguard-rs/.

What works for now:

- A main working executable (`cargo run -- -h`) which parses the command =
line parameters via the `clap` crate
- General debug and tracing support via the `log` crate
- Daemonizing support
- The wireguard library which creates a local socket and waits for =
incoming connections (reference implementation)

What needs to be done in the next steps:

- The actual parsing of the incoming message and writing them to the =
wireguard device (see `TODO`)
- Higher test coverage via unit testing
- A plan how to use the tokio.rs futures with the current implementation
- Wider operating system (Windows) support for the current =
implementation
- Get rid of the unsafe code

I tried to use as much idiomatic Rust (like using the `nix` crate and =
Rust vectors instead of raw pointers) as possible for now. So what do =
you think?

Best regards,
Sascha=

Re: Rust implementation status

[Vladimir Matveev]

Hi, Sascha,

I'm a Rust programmer, and I really like that there is now a Rust
implementation of the Wireguard daemon!

I have a few question and suggestions.

1. Instead of hand-rolling your own error management implementation,
consider using the error-chain[1] crate. It seems that many popular
crates now depend on it[2]. It would make the Wireguard crate more
interoperable and more readable for those who is already accustomed
with error-chain. On the first glance, your custom implementation
resembles error-chain very much.

2. Consider publishing the project on some hosting service like Github
or Gitlab or something else, which would allow easier community
participation. I would very much like to help with its development, but
I never participated in any mailing-list based projects and I
personally find it very inconvenient, and I think that the pull
requests mechanics is greatly superior. Also, almost all Rust ecosystem
lives on Github, so lots of Rust developers are quite accustomed to it,
and you will most certainly attract more contributors that way.

3. On a related note, consider publishing a link to this project in the
Rust community, in particular, in the Rust subreddit[3] and maybe on
The Rust Programming Language Forum[4]. I think that many people there
will be very interested in a project like this, because it is network-
related, it is pretty low level, and it will probably depend on the
current "hot" crates in the Rust community, like tokio.

4. I think it would be quite idiomatic to split the interface to WG
into a separate library crate, which the main binary would depend on.

5. I wonder, is it really necessary to perform daemonization manually?
As far as I understand the current situation in the daemon writing and
init systems, it is expected that daemons won't fork themselves and
will continue working in foreground when started, while service
management systems like systemd or launchd will take care of keeping
them alive, collecting logs, starting, restarting, etc. Daemonizing
also seems quite unidiomatic on Windows. I also personally think that
avoiding manual daemonization will make the code and architecture
simpler and more manageable.

6. Have you decided which cryptographic libraries you are going to use?
Or are you planning to implement the necessary primitives in this
project?

I'm really looking forward to the further development of this project,
and I'm willing to participate in it if you're looking for
contributors.

Best regards,
Vladimir

  [1]: https://crates.io/crates/error-chain
  [2]: https://crates.io/crates/error-chain/reverse_dependencies
  [3]: https://www.reddit.com/r/rust/
  [4]: https://users.rust-lang.org/

Re: Rust implementation status

[sopium]

Hi,

2017-03-05 20:42 GMT+09:00 Sascha Grunert <saschagrunert@icloud.com>:
> Hey folks,
>
> I want to call for participation of the Rust userspace implementation of =
WireGuard. The template for the initial implementation was this: https://ww=
w.wireguard.io/xplatform/ and can be found here: https://git.zx2c4.com/wire=
guard-rs/.
>
> [......]

I have got an initial working prototype of the WireGuard protocol in
Rust.

The code is at the `wg` branch of `TiTun`[1].

1. https://github.com/sopium/titun/tree/wg

Most of the essential aspects of the WireGuard protocol is
implemented. The missing parts should not be too hard to add.

Only Linux is supported, for the moment.

The implementation is quite fast =F0=9F=9A=80, although I haven't spent a l=
ot of
effort in optimization yet. It uses a fixed number of threads to
process packets from UDP socket or TUN device (similar to the other
Haskell impl, nara), and uses fine-grained locking to exploit
parallelism. I get 600Mbps+ to 800Mbps+ throughput and about 0.5ms
latency, between my Haswell Xeon-E3 desktop and a local KVM
instance. It should be able to get even faster with SO_REUSEPORT
sockets and multi-queue TUN devices.

Please review and test.

Regards,
Sopium

Re: Rust implementation status

[Jason A. Donenfeld]

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

Hey Sopium,

Wonderful! I'm traveling now but will review first thing next week.

Please make sure you've implemented https://www.wireguard.io/xplatform/ so
that all implementations can share the same tooling.

Jason

On Mar 13, 2017 00:04, "sopium" <sopium@mysterious.site> wrote:

Hi,

2017-03-05 20:42 GMT+09:00 Sascha Grunert <saschagrunert@icloud.com>:
> Hey folks,
>
> I want to call for participation of the Rust userspace implementation of
WireGuard. The template for the initial implementation was this:
https://www.wireguard.io/xplatform/ and can be found here:
https://git.zx2c4.com/wireguard-rs/.
>
> [......]

I have got an initial working prototype of the WireGuard protocol in
Rust.

The code is at the `wg` branch of `TiTun`[1].

1. https://github.com/sopium/titun/tree/wg

Most of the essential aspects of the WireGuard protocol is
implemented. The missing parts should not be too hard to add.

Only Linux is supported, for the moment.

The implementation is quite fast 🚀, although I haven't spent a lot of
effort in optimization yet. It uses a fixed number of threads to
process packets from UDP socket or TUN device (similar to the other
Haskell impl, nara), and uses fine-grained locking to exploit
parallelism. I get 600Mbps+ to 800Mbps+ throughput and about 0.5ms
latency, between my Haswell Xeon-E3 desktop and a local KVM
instance. It should be able to get even faster with SO_REUSEPORT
sockets and multi-queue TUN devices.

Please review and test.

Regards,
Sopium


_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

[-- Attachment #2: Type: text/html, Size: 2834 bytes --]

Re: Rust implementation status

[Sascha Grunert]

[-- Attachment #1: Type: text/plain, Size: 6433 bytes --]

Hello Vladimir,

I just read that there is another WireGuard Rust implementation here:
https://github.com/sopium/titun/tree/wg

1. Instead of hand-rolling your own error management implementation,
consider using the error-chain[1] crate. It seems that many popular
crates now depend on it[2]. It would make the Wireguard crate more
interoperable and more readable for those who is already accustomed
with error-chain. On the first glance, your custom implementation
resembles error-chain very much.

This sounds great, I or we can go forward with that crate if it provides
better error handling.
 
2. Consider publishing the project on some hosting service like Github
or Gitlab or something else, which would allow easier community
participation. I would very much like to help with its development, but
I never participated in any mailing-list based projects and I
personally find it very inconvenient, and I think that the pull
requests mechanics is greatly superior. Also, almost all Rust ecosystem
lives on Github, so lots of Rust developers are quite accustomed to it,
and you will most certainly attract more contributors that way.

I already thought about this but the project owner wants to have a single
place where the sources lives. But mirroring code is possible as well,
like we already do on github: https://github.com/WireGuard/wireguard-rs
 
3. On a related note, consider publishing a link to this project in the
Rust community, in particular, in the Rust subreddit[3] and maybe on
The Rust Programming Language Forum[4]. I think that many people there
will be very interested in a project like this, because it is network-
related, it is pretty low level, and it will probably depend on the
current "hot" crates in the Rust community, like tokio.

Yes this is a good idea and we can do that if we have a small working
prototype. :)
 
4. I think it would be quite idiomatic to split the interface to WG
into a separate library crate, which the main binary would depend on.

Yeah sounds reasonable. Lets look forward to this.
 
5. I wonder, is it really necessary to perform daemonization manually?
As far as I understand the current situation in the daemon writing and
init systems, it is expected that daemons won't fork themselves and
will continue working in foreground when started, while service
management systems like systemd or launchd will take care of keeping
them alive, collecting logs, starting, restarting, etc. Daemonizing
also seems quite unidiomatic on Windows. I also personally think that
avoiding manual daemonization will make the code and architecture
simpler and more manageable.

The actual implementation follows strictly this guideline:
https://www.wireguard.io/xplatform/
Usually I agree in letting the daemon stuff to systemd or something else,
but we want to avoid fragmentation, that different implementations behave
differently.
 
6. Have you decided which cryptographic libraries you are going to use?
Or are you planning to implement the necessary primitives in this
project?

Not now, there is no such decision done yet.

I am looking really further for your contribution, since it is currently a "one man show",
which is pretty though for me.

I know that a main development on GitHub would spread the project better into the
open source world. Maybe we need to discuss this point at some time.

Best regards,
Sascha

Am 13. März 2017 um 00:10 schrieb Vladimir Matveev <dpx.infinity@gmail.com>:

Hi, Sascha,

I'm a Rust programmer, and I really like that there is now a Rust
implementation of the Wireguard daemon!

I have a few question and suggestions.

1. Instead of hand-rolling your own error management implementation,
consider using the error-chain[1] crate. It seems that many popular
crates now depend on it[2]. It would make the Wireguard crate more
interoperable and more readable for those who is already accustomed
with error-chain. On the first glance, your custom implementation
resembles error-chain very much.

2. Consider publishing the project on some hosting service like Github
or Gitlab or something else, which would allow easier community
participation. I would very much like to help with its development, but
I never participated in any mailing-list based projects and I
personally find it very inconvenient, and I think that the pull
requests mechanics is greatly superior. Also, almost all Rust ecosystem
lives on Github, so lots of Rust developers are quite accustomed to it,
and you will most certainly attract more contributors that way.

3. On a related note, consider publishing a link to this project in the
Rust community, in particular, in the Rust subreddit[3] and maybe on
The Rust Programming Language Forum[4]. I think that many people there
will be very interested in a project like this, because it is network-
related, it is pretty low level, and it will probably depend on the
current "hot" crates in the Rust community, like tokio.

4. I think it would be quite idiomatic to split the interface to WG
into a separate library crate, which the main binary would depend on.

5. I wonder, is it really necessary to perform daemonization manually?
As far as I understand the current situation in the daemon writing and
init systems, it is expected that daemons won't fork themselves and
will continue working in foreground when started, while service
management systems like systemd or launchd will take care of keeping
them alive, collecting logs, starting, restarting, etc. Daemonizing
also seems quite unidiomatic on Windows. I also personally think that
avoiding manual daemonization will make the code and architecture
simpler and more manageable.

6. Have you decided which cryptographic libraries you are going to use?
Or are you planning to implement the necessary primitives in this
project?

I'm really looking forward to the further development of this project,
and I'm willing to participate in it if you're looking for
contributors.

Best regards,
Vladimir

[1]: https://crates.io/crates/error-chain
[2]: https://crates.io/crates/error-chain/reverse_dependencies
[3]: https://www.reddit.com/r/rust/
[4]: https://users.rust-lang.org/
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

[-- Attachment #2.1: Type: text/html, Size: 18526 bytes --]

Re: Rust implementation status

[Vladimir Matveev]

> I just read that there is another WireGuard Rust implementation here:
> https://github.com/sopium/titun/tree/wg

I see. I think that joining efforts would be nice, but, if I understand
it correctly, that project is intended to provide a different
interface, using WG as an underlying protocol. I personally think that
it would be better to separate these layers, providing the connectivity
daemon and higher-level features separately. I may be wrong though, it
is quite possible that the combined approach will be more useful.

> This sounds great, I or we can go forward with that crate if it
> provides
> better error handling.

I have actually submitted a pull request to the github repository
already which does exactly that :)

> I already thought about this but the project owner wants to have a
> single
> place where the sources lives. But mirroring code is possible as
> well,
> like we already do on github: https://github.com/WireGuard/wireguard-
> rs

This is understandable, I think. But still, maybe doing development on
Github and publishing the contents of the repository there to the main
repository is possible? I believe that taking advantage of the issue
tracker and the pull requests system there would be very useful and
convenient.

I actually suggest putting TODO items as issues on Github as the first
step, so it would be clear what should be done next.

> > 4. I think it would be quite idiomatic to split the interface to WG
> > into a separate library crate, which the main binary would depend
> > on.
> 
> Yeah sounds reasonable. Lets look forward to this.

There are several ways to do it, actually. If you don't mind, I may
send a pull request which implements one later.

> The actual implementation follows strictly this guideline:
> https://www.wireguard.io/xplatform/
> Usually I agree in letting the daemon stuff to systemd or something
> else,
> but we want to avoid fragmentation, that different implementations
> behave
> differently.

I'm pretty sure that when WG get popuar, differences in behavior will
be unavoidable. Also, since all of the userspace WG projects seem to be
in quite a flux state now, maybe it is worth considering to change
these guidelines when it is not late yet?

> > 6. Have you decided which cryptographic libraries you are going to
> > use?
> > Or are you planning to implement the necessary primitives in this
> > project?
> 
> Not now, there is no such decision done yet.
> 
> I am looking really further for your contribution, since it is
> currently a "one man show",
> which is pretty though for me.
> 
> I know that a main development on GitHub would spread the project
> better into the
> open source world. Maybe we need to discuss this point at some time.
> 
> Best regards,
> Sascha
> 
> Am 13. März 2017 um 00:10 schrieb Vladimir Matveev <dpx.infinity@gmai
> l.com>:
> 
> > Hi, Sascha,
> > 
> > I'm a Rust programmer, and I really like that there is now a Rust
> > implementation of the Wireguard daemon!
> > 
> > I have a few question and suggestions.
> > 
> > 1. Instead of hand-rolling your own error management
> > implementation,
> > consider using the error-chain[1] crate. It seems that many popular
> > crates now depend on it[2]. It would make the Wireguard crate more
> > interoperable and more readable for those who is already accustomed
> > with error-chain. On the first glance, your custom implementation
> > resembles error-chain very much.
> > 
> > 2. Consider publishing the project on some hosting service like
> > Github
> > or Gitlab or something else, which would allow easier community
> > participation. I would very much like to help with its development,
> > but
> > I never participated in any mailing-list based projects and I
> > personally find it very inconvenient, and I think that the pull
> > requests mechanics is greatly superior. Also, almost all Rust
> > ecosystem
> > lives on Github, so lots of Rust developers are quite accustomed to
> > it,
> > and you will most certainly attract more contributors that way.
> > 
> > 3. On a related note, consider publishing a link to this project in
> > the
> > Rust community, in particular, in the Rust subreddit[3] and maybe
> > on
> > The Rust Programming Language Forum[4]. I think that many people
> > there
> > will be very interested in a project like this, because it is
> > network-
> > related, it is pretty low level, and it will probably depend on the
> > current "hot" crates in the Rust community, like tokio.
> > 
> > 4. I think it would be quite idiomatic to split the interface to WG
> > into a separate library crate, which the main binary would depend
> > on.
> > 
> > 5. I wonder, is it really necessary to perform daemonization
> > manually?
> > As far as I understand the current situation in the daemon writing
> > and
> > init systems, it is expected that daemons won't fork themselves and
> > will continue working in foreground when started, while service
> > management systems like systemd or launchd will take care of
> > keeping
> > them alive, collecting logs, starting, restarting, etc. Daemonizing
> > also seems quite unidiomatic on Windows. I also personally think
> > that
> > avoiding manual daemonization will make the code and architecture
> > simpler and more manageable.
> > 
> > 6. Have you decided which cryptographic libraries you are going to
> > use?
> > Or are you planning to implement the necessary primitives in this
> > project?
> > 
> > I'm really looking forward to the further development of this
> > project,
> > and I'm willing to participate in it if you're looking for
> > contributors.
> > 
> > Best regards,
> > Vladimir
> > 
> > [1]: https://crates.io/crates/error-chain
> > [2]: https://crates.io/crates/error-chain/reverse_dependencies
> > [3]: https://www.reddit.com/r/rust/
> > [4]: https://users.rust-lang.org/
> > _______________________________________________
> > WireGuard mailing list
> > WireGuard@lists.zx2c4.com
> > https://lists.zx2c4.com/mailman/listinfo/wireguard

Re: Rust implementation status

[sopium]

Hi,

 ---- On Mon, 13 Mar 2017 23:39:03 +0900 Jason A. Donenfeld <Jason@zx2c4.com> wrote ---- 
 > Hey Sopium,
 > Wonderful! I'm traveling now but will review first thing next week.
 > Please make sure you've implemented https://www.wireguard.io/xplatform/ so that all implementations can share the same tooling.
 > Jason

Yeah, that's definitely on my TODO list.

Re: Rust implementation status

[sopium]

Hi Sascha and folks,

 ---- On Sun, 05 Mar 2017 20:42:00 +0900 Sascha Grunert <saschagrunert@iclo=
ud.com> wrote ----=20
 > Hey folks,=20
 > =20
 > I want to call for participation of the Rust userspace implementation of=
 WireGuard. The template for the initial implementation was this: https://w=
ww.wireguard.io/xplatform/ and can be found here: https://git.zx2c4.com/wir=
eguard-rs/.=20
 > =20
 > What works for now:=20
 > =20
 > - A main working executable (`cargo run -- -h`) which parses the command=
 line parameters via the `clap` crate=20
 > - General debug and tracing support via the `log` crate=20
 > - Daemonizing support=20
 > - The wireguard library which creates a local socket and waits for incom=
ing connections (reference implementation)=20
 >
 > [...]

I have kept an eye on this. It seems that you were mostly working
on the `xplatform` stuff, and haven't started on the actual
implementation of the protocol yet. My code has (partly)
implemented the protocol, but lacks the `xplatform` ui. So it
seems like a perfect time to merge efforts. What do you think?

And to all who are interested in userspace WG impls, in
particular Rust impls, I have adjusted the goal of my project to
=E2=80=9Cto write a secure, compatible, cross-platform and reasonably
fast user-space implementation of WireGuard in Rust=E2=80=9D. I am also
committed to finishing and maintaining it. There is a big TODO
list, and contribution is welcome!

For those not closely following this thread, the project is at:

  https://github.com/sopium/titun/tree/wg

Regards,
Sopium

Re: Rust implementation status

[Sascha Grunert]

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]

Hey guys,

I would really like to do that. For the main development I would throw this into discussion: https://github.com/WireGuard/wireguard-rs/issues/1#issuecomment-286521908

I guess it would be more visible to the Rust community if we allow maintaining it via the GitHub repository.

@Jason, what do you think?

Best regards,
Sascha

Am 14. März 2017, 17:29 +0100 schrieb sopium <sopium@mysterious.site>:
> Hi Sascha and folks,
>
> ---- On Sun, 05 Mar 2017 20:42:00 +0900 Sascha Grunert <saschagrunert@icloud.com> wrote ----
> > Hey folks,
> >
> > I want to call for participation of the Rust userspace implementation of WireGuard. The template for the initial implementation was this: https://www.wireguard.io/xplatform/ and can be found here: https://git.zx2c4.com/wireguard-rs/.
> >
> > What works for now:
> >
> > - A main working executable (`cargo run -- -h`) which parses the command line parameters via the `clap` crate
> > - General debug and tracing support via the `log` crate
> > - Daemonizing support
> > - The wireguard library which creates a local socket and waits for incoming connections (reference implementation)
> >
> > [...]
>
> I have kept an eye on this. It seems that you were mostly working
> on the `xplatform` stuff, and haven't started on the actual
> implementation of the protocol yet. My code has (partly)
> implemented the protocol, but lacks the `xplatform` ui. So it
> seems like a perfect time to merge efforts. What do you think?
>
> And to all who are interested in userspace WG impls, in
> particular Rust impls, I have adjusted the goal of my project to
> “to write a secure, compatible, cross-platform and reasonably
> fast user-space implementation of WireGuard in Rust”. I am also
> committed to finishing and maintaining it. There is a big TODO
> list, and contribution is welcome!
>
> For those not closely following this thread, the project is at:
>
> https://github.com/sopium/titun/tree/wg
>
> Regards,
> Sopium
>
>

[-- Attachment #2: Type: text/html, Size: 2529 bytes --]

Re: Rust implementation status

[Jason A. Donenfeld]

On Tue, Mar 14, 2017 at 3:11 AM, Vladimir Matveev
<dpx.infinity@gmail.com> wrote:
> I see. I think that joining efforts would be nice, but, if I understand
> it correctly, that project is intended to provide a different
> interface, using WG as an underlying protocol. I personally think that
> it would be better to separate these layers, providing the connectivity
> daemon and higher-level features separately. I may be wrong though, it
> is quite possible that the combined approach will be more useful.

The objective of all wireguard implementations is to provide a simple
and uniform interface. Unity is very important. I have no interest
debating that point further. It is a stated project goal and a core
design consideration that drives discussion on this list forward.

> This is understandable, I think. But still, maybe doing development on
> Github and publishing the contents of the repository there to the main
> repository is possible? I believe that taking advantage of the issue
> tracker and the pull requests system there would be very useful and
> convenient.

The main repository is on git.zx2c4.com, but if people want to use PRs
and issues, and Sascha wants to review those, then that's of course
fine. Use whatever tools necessary. The important aspect is that the
canonical location for all WireGuard projects remains the same.

> I'm pretty sure that when WG get popuar, differences in behavior will
> be unavoidable.

You are so very wrong. If you start with this stupidity, sure, you'll
get brokenness. But if you actually attempt to carry out something
worthwhile, then each and every such difference will be squashed and
unified. I certainly intend to toil away to achieve this goal.

By the way, are you actually intending to contribute anything here, or
are you just on this list to bikeshed about procedural issues?

Re: Rust implementation status

[Vladimir Matveev]

В Ср, 15/03/2017 в 08:59 -0700, Jason A. Donenfeld пишет:
> On Tue, Mar 14, 2017 at 3:11 AM, Vladimir Matveev
> <dpx.infinity@gmail.com> wrote:
> > I see. I think that joining efforts would be nice, but, if I
> > understand
> > it correctly, that project is intended to provide a different
> > interface, using WG as an underlying protocol. I personally think
> > that
> > it would be better to separate these layers, providing the
> > connectivity
> > daemon and higher-level features separately. I may be wrong though,
> > it
> > is quite possible that the combined approach will be more useful.
> 
> The objective of all wireguard implementations is to provide a simple
> and uniform interface. Unity is very important. I have no interest
> debating that point further. It is a stated project goal and a core
> design consideration that drives discussion on this list forward.

Sorry, I don't understand what exactly wrong with my statement here; if
anything, I do agree with the goal of making Wireguard implementations
as slim as possible (i.e. following the guideline on https://www.wiregu
ard.io/xplatform/). My thoughts in this paragraph were about the
implementation here: https://github.com/sopium/titun, which, on the
first glance (and I may be wrong here, too) appeared to provide a much
more complex interface than the one declared in https://www.wireguard.i
o/xplatform/. And my point was that it is probably better to have
something simpler, on top of which a more complex interface could be
built by someone else. This was not even related to the way the
*official* Wireguard implementation should be done.

> 
> > This is understandable, I think. But still, maybe doing development
> > on
> > Github and publishing the contents of the repository there to the
> > main
> > repository is possible? I believe that taking advantage of the
> > issue
> > tracker and the pull requests system there would be very useful and
> > convenient.
> 
> The main repository is on git.zx2c4.com, but if people want to use
> PRs
> and issues, and Sascha wants to review those, then that's of course
> fine. Use whatever tools necessary. The important aspect is that the
> canonical location for all WireGuard projects remains the same.

Yes, I do agree with this, and I saw your answer on Github already and
I'm really glad that you are not against this approach.

> 
> > I'm pretty sure that when WG get popuar, differences in behavior
> > will
> > be unavoidable.
> 
> You are so very wrong. If you start with this stupidity, sure, you'll
> get brokenness. But if you actually attempt to carry out something
> worthwhile, then each and every such difference will be squashed and
> unified. I certainly intend to toil away to achieve this goal.

If you mean official implementations, sure, I totally agree, and I
agree that it is right. I was talking about unofficial implementations
- I don't believe it is possible to force someone not to create a
Wireguard implementation with a different interface, if they do decide
to do so.

> 
> By the way, are you actually intending to contribute anything here,
> or
> are you just on this list to bikeshed about procedural issues?

I'm very sorry if I said something which made you think so. I totally
do not intend to discuss any procedural issues, I do not have a right
to do so and I don't think I'm really competent. If I recall correctly,
the only thing I said about procedures is that doing development on
Github (in the sense of accepting PRs and tracking issues there) would
be benefitting for the Rust implementation of Wireguard. I really like
Wireguard, and I also like Rust, so I do want to participate in the
development of the Rust implementation of it to the best of my ability
to do so. Again, I'm sorry if I made a wrong impression here.

Re: Rust implementation status

[Jason A. Donenfeld]

On Wed, Mar 15, 2017 at 9:51 AM, Vladimir Matveev
<dpx.infinity@gmail.com> wrote:
> anything, I do agree with the goal of making Wireguard implementations
> as slim as possible (i.e. following the guideline on https://www.wiregu
> ard.io/xplatform/). My thoughts in this paragraph were about the
> agree that it is right. I was talking about unofficial implementations
> - I don't believe it is possible to force someone not to create a
> Wireguard implementation with a different interface,

Oh, okay, I understand now. Indeed "non-official" ports become harder
to keep consistent. For that reason, I'm actively soliciting
contributions to the main project organization, so we can work
together to get something unified, so that there aren't ugly
fractures.

> Yes, I do agree with this, and I saw your answer on Github already and
> I'm really glad that you are not against this approach.

Cool.

> I'm very sorry if I said something which made you think so.

It's okay, and no need for apology. I was just wondering what was
happening here.

Re: Rust implementation status

[Sascha Grunert]

Hey Folks,

To make it clear for now: If you want to contribute, simply use GitHub =
issues and pull requests. I will take care of the synchronisation of the =
repositories for now.

It would be really cool if we can focus on merging our efforts and =
planning the next steps via GitHub issues. Discussions via the mailing =
list are very welcome as well.

I merged the first pull request for now. Thank you very much and have a =
nice weekend!

Best regards,
Sascha


> Am 14.03.2017 um 19:49 schrieb Sascha Grunert =
<saschagrunert@icloud.com>:
>=20
> Hey guys,
>=20
> I would really like to do that. For the main development I would throw =
this into discussion: =
https://github.com/WireGuard/wireguard-rs/issues/1#issuecomment-286521908
>=20
> I guess it would be more visible to the Rust community if we allow =
maintaining it via the GitHub repository.
>=20
> @Jason, what do you think?
>=20
> Best regards,
> Sascha
>=20
> Am 14. M=C3=A4rz 2017, 17:29 +0100 schrieb sopium =
<sopium@mysterious.site>:
>> Hi Sascha and folks,
>>=20
>> ---- On Sun, 05 Mar 2017 20:42:00 +0900 Sascha Grunert =
<saschagrunert@icloud.com> wrote ----
>>> Hey folks,
>>>=20
>>> I want to call for participation of the Rust userspace =
implementation of WireGuard. The template for the initial implementation =
was this: https://www.wireguard.io/xplatform/ and can be found here: =
https://git.zx2c4.com/wireguard-rs/.
>>>=20
>>> What works for now:
>>>=20
>>> - A main working executable (`cargo run -- -h`) which parses the =
command line parameters via the `clap` crate
>>> - General debug and tracing support via the `log` crate
>>> - Daemonizing support
>>> - The wireguard library which creates a local socket and waits for =
incoming connections (reference implementation)
>>>=20
>>> [...]
>>=20
>> I have kept an eye on this. It seems that you were mostly working
>> on the `xplatform` stuff, and haven't started on the actual
>> implementation of the protocol yet. My code has (partly)
>> implemented the protocol, but lacks the `xplatform` ui. So it
>> seems like a perfect time to merge efforts. What do you think?
>>=20
>> And to all who are interested in userspace WG impls, in
>> particular Rust impls, I have adjusted the goal of my project to
>> =E2=80=9Cto write a secure, compatible, cross-platform and reasonably
>> fast user-space implementation of WireGuard in Rust=E2=80=9D. I am =
also
>> committed to finishing and maintaining it. There is a big TODO
>> list, and contribution is welcome!
>>=20
>> For those not closely following this thread, the project is at:
>>=20
>> https://github.com/sopium/titun/tree/wg
>>=20
>> Regards,
>> Sopium
>>=20
>>=20

Re: Rust implementation status

[Sascha Grunert]

[-- Attachment #1: Type: text/plain, Size: 1456 bytes --]

Hey folks,

This sounds really great, do you think you can contribute your work to the main WireGuard Rust source?

Best regards,
Sascha

Am 13. März 2017 um 08:04 schrieb sopium <sopium@mysterious.site>:

Hi,

2017-03-05 20:42 GMT+09:00 Sascha Grunert <saschagrunert@icloud.com>:
Hey folks,

I want to call for participation of the Rust userspace implementation of WireGuard. The template for the initial implementation was this: https://www.wireguard.io/xplatform/ and can be found here: https://git.zx2c4.com/wireguard-rs/.

[......]

I have got an initial working prototype of the WireGuard protocol in
Rust.

The code is at the `wg` branch of `TiTun`[1].

1. https://github.com/sopium/titun/tree/wg

Most of the essential aspects of the WireGuard protocol is
implemented. The missing parts should not be too hard to add.

Only Linux is supported, for the moment.

The implementation is quite fast 🚀, although I haven't spent a lot of
effort in optimization yet. It uses a fixed number of threads to
process packets from UDP socket or TUN device (similar to the other
Haskell impl, nara), and uses fine-grained locking to exploit
parallelism. I get 600Mbps+ to 800Mbps+ throughput and about 0.5ms
latency, between my Haswell Xeon-E3 desktop and a local KVM
instance. It should be able to get even faster with SO_REUSEPORT
sockets and multi-queue TUN devices.

Please review and test.

Regards,
Sopium



[-- Attachment #2.1: Type: text/html, Size: 2481 bytes --]