wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: Matt Layher <mdlayher@gmail.com>
To: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: wireguardctrl: Go package that enables control of WireGuard devices on multiple platforms
Date: Thu, 9 Aug 2018 12:10:59 -0400	[thread overview]
Message-ID: <5569ab33-74e4-94b9-4be6-424f41517e6f@gmail.com> (raw)
In-Reply-To: <e0d214b0-d1b4-4708-7e91-989060fcaf97@gmail.com>

I suppose this would be a good place to poll the audience for feedback 
on a question as well!

Right now I expose methods to access devices by both name and interface 
index.  However, the userspace implementations don't have the concept of 
an interface index exposed.  You can access it by doing an interface 
lookup for the tap interface name (net.InterfaceByIndex in Go), but then 
my userspace package does an immediate name lookup after that anyway.

Does it makes sense to continue to expose a way to fetch a WireGuard 
device by its interface index?  Is this useful compared to fetching a 
device by its name?  If not, I could remove it and rename the method 
"DeviceByName" to just "Device".

See: https://github.com/mdlayher/wireguardctrl/issues/6

Thanks in advance for the feedback!

- Matt


On 08/07/2018 02:16 PM, Matt Layher wrote:
> Hi all,
>
> It's been a couple of weeks since my previous thread, so I wanted to 
> follow up with a new one now that my Go package has a new name and an 
> extended scope:
>
> https://github.com/mdlayher/wireguardctrl
>
> wireguardctrl is a Go package that abstracts away the WireGuard 
> kernel, userspace, and any future OS-specific interfaces.
>
> At this point, I've got all of the device and peer retrieval 
> functionality done, but I still need to implement device peer 
> configuration for both the kernel and userspace interfaces.  There are 
> a couple issues open around this topic.
>
> I think this package is at a point where I'd feel comfortable having 
> folks try it out and see what happens.  I've got some integration 
> tests hooked up in Travis CI for both the kernel and userspace 
> modules, and it seems to work well!  My next plan is to consider 
> building some kind of one-shot utility for setting up a tunnel by 
> running a small program on two machines.
>
> Thanks for your time, and feel free to reach out here or on IRC for 
> any questions.
>
> - Matt Layher
>
> PS: Jason, if you do end up making a language bindings page for the 
> website, I'd still like this package to be listed there!  I also found 
> the beginnings of a Python library today: 
> https://github.com/apognu/wgctl.
>

      reply	other threads:[~2018-08-09 15:59 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-07 18:16 wireguardctrl: Go package that enables control of WireGuard devices on multiple platforms Matt Layher
2018-08-09 16:10 ` Matt Layher [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5569ab33-74e4-94b9-4be6-424f41517e6f@gmail.com \
    --to=mdlayher@gmail.com \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).