* Rust implementation status
@ 2017-03-05 11:42 Sascha Grunert
2017-03-12 23:09 ` Vladimir Matveev
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Sascha Grunert @ 2017-03-05 11:42 UTC (permalink / raw)
To: wireguard
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=
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Rust implementation status 2017-03-05 11:42 Rust implementation status Sascha Grunert @ 2017-03-12 23:09 ` Vladimir Matveev 2017-03-13 16:58 ` Sascha Grunert 2017-03-13 7:04 ` sopium 2017-03-14 16:29 ` sopium 2 siblings, 1 reply; 14+ messages in thread From: Vladimir Matveev @ 2017-03-12 23:09 UTC (permalink / raw) To: wireguard 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/ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rust implementation status 2017-03-12 23:09 ` Vladimir Matveev @ 2017-03-13 16:58 ` Sascha Grunert 2017-03-14 10:11 ` Vladimir Matveev 0 siblings, 1 reply; 14+ messages in thread From: Sascha Grunert @ 2017-03-13 16:58 UTC (permalink / raw) To: Vladimir Matveev; +Cc: wireguard [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rust implementation status 2017-03-13 16:58 ` Sascha Grunert @ 2017-03-14 10:11 ` Vladimir Matveev 2017-03-15 15:59 ` Jason A. Donenfeld 0 siblings, 1 reply; 14+ messages in thread From: Vladimir Matveev @ 2017-03-14 10:11 UTC (permalink / raw) To: Sascha Grunert; +Cc: wireguard > 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rust implementation status 2017-03-14 10:11 ` Vladimir Matveev @ 2017-03-15 15:59 ` Jason A. Donenfeld 2017-03-15 16:51 ` Vladimir Matveev 0 siblings, 1 reply; 14+ messages in thread From: Jason A. Donenfeld @ 2017-03-15 15:59 UTC (permalink / raw) To: Vladimir Matveev; +Cc: WireGuard mailing list 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? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rust implementation status 2017-03-15 15:59 ` Jason A. Donenfeld @ 2017-03-15 16:51 ` Vladimir Matveev 2017-03-15 17:03 ` Jason A. Donenfeld 0 siblings, 1 reply; 14+ messages in thread From: Vladimir Matveev @ 2017-03-15 16:51 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list В Ср, 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rust implementation status 2017-03-15 16:51 ` Vladimir Matveev @ 2017-03-15 17:03 ` Jason A. Donenfeld 0 siblings, 0 replies; 14+ messages in thread From: Jason A. Donenfeld @ 2017-03-15 17:03 UTC (permalink / raw) To: Vladimir Matveev; +Cc: WireGuard mailing list 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rust implementation status 2017-03-05 11:42 Rust implementation status Sascha Grunert 2017-03-12 23:09 ` Vladimir Matveev @ 2017-03-13 7:04 ` sopium [not found] ` <CAHmME9oFbpNBTszO_Q5m8EwiG0F0SH6BUd+1SFZGUDGH0wQ0gg@mail.gmail.com> 2017-03-14 16:29 ` sopium 2 siblings, 1 reply; 14+ messages in thread From: sopium @ 2017-03-13 7:04 UTC (permalink / raw) To: Sascha Grunert; +Cc: wireguard 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <CAHmME9oFbpNBTszO_Q5m8EwiG0F0SH6BUd+1SFZGUDGH0wQ0gg@mail.gmail.com>]
* Re: Rust implementation status [not found] ` <CAHmME9oFbpNBTszO_Q5m8EwiG0F0SH6BUd+1SFZGUDGH0wQ0gg@mail.gmail.com> @ 2017-03-13 14:39 ` Jason A. Donenfeld 2017-03-14 13:08 ` sopium 0 siblings, 1 reply; 14+ messages in thread From: Jason A. Donenfeld @ 2017-03-13 14:39 UTC (permalink / raw) To: sopium; +Cc: WireGuard mailing list [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rust implementation status 2017-03-13 14:39 ` Jason A. Donenfeld @ 2017-03-14 13:08 ` sopium 0 siblings, 0 replies; 14+ messages in thread From: sopium @ 2017-03-14 13:08 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rust implementation status 2017-03-05 11:42 Rust implementation status Sascha Grunert 2017-03-12 23:09 ` Vladimir Matveev 2017-03-13 7:04 ` sopium @ 2017-03-14 16:29 ` sopium 2017-03-14 18:49 ` Sascha Grunert 2 siblings, 1 reply; 14+ messages in thread From: sopium @ 2017-03-14 16:29 UTC (permalink / raw) To: Sascha Grunert; +Cc: wireguard 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rust implementation status 2017-03-14 16:29 ` sopium @ 2017-03-14 18:49 ` Sascha Grunert 2017-03-18 10:51 ` Sascha Grunert 0 siblings, 1 reply; 14+ messages in thread From: Sascha Grunert @ 2017-03-14 18:49 UTC (permalink / raw) To: sopium; +Cc: wireguard [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rust implementation status 2017-03-14 18:49 ` Sascha Grunert @ 2017-03-18 10:51 ` Sascha Grunert 0 siblings, 0 replies; 14+ messages in thread From: Sascha Grunert @ 2017-03-18 10:51 UTC (permalink / raw) To: sopium; +Cc: wireguard 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Rust implementation status @ 2017-03-13 17:00 Sascha Grunert 0 siblings, 0 replies; 14+ messages in thread From: Sascha Grunert @ 2017-03-13 17:00 UTC (permalink / raw) To: sopium; +Cc: wireguard [-- 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 --] ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2017-03-18 10:47 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-05 11:42 Rust implementation status Sascha Grunert
2017-03-12 23:09 ` Vladimir Matveev
2017-03-13 16:58 ` Sascha Grunert
2017-03-14 10:11 ` Vladimir Matveev
2017-03-15 15:59 ` Jason A. Donenfeld
2017-03-15 16:51 ` Vladimir Matveev
2017-03-15 17:03 ` Jason A. Donenfeld
2017-03-13 7:04 ` sopium
[not found] ` <CAHmME9oFbpNBTszO_Q5m8EwiG0F0SH6BUd+1SFZGUDGH0wQ0gg@mail.gmail.com>
2017-03-13 14:39 ` Jason A. Donenfeld
2017-03-14 13:08 ` sopium
2017-03-14 16:29 ` sopium
2017-03-14 18:49 ` Sascha Grunert
2017-03-18 10:51 ` Sascha Grunert
2017-03-13 17:00 Sascha Grunert
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.