Re: wireguard-go on windows
A glance at https://github.com/WireGuard/wgctrl-go/blob/master/internal/wguser/parse.go#L48 seems to indicate that we treat the first "blank" line produced by bufio.Scanner (which strips \n) as a sentinel to stop parsing, which would mean something like "errno=0\n\n" would parse the errno and be done once it interprets the final line "\n". The tests seem to indicate this works as expected, but I don't regularly develop on Windows and welcome PRs if something has changed. - Matt On 2/25/21 12:54 PM, Jason A. Donenfeld wrote: + Matt Layher Hi Davanath, We are trying to use wgctrl way of configuring the wireguard devices and facing issues while creating/configuring the wireguard device on windows. 1) First problem was while creating the wintun device using wintun.dll and using wgctrl for configuring it. It hangs in wgclient.ConfigureDevice api() wgctrl works with wireguard. wireguard uses wintun, but wireguard is not wintun. 2) So tried to first create the device through wireguard.exe. And then used wgctrl way to configure it, but wgClient.Devices() is not able to get the devices on our test windows boxes (even though it works on my development machine) This sounds like a potential bug in wgctrl. Matt -- I wonder if there's a bug in the parser, recently unearthed by a change in wireguard-go. Specifically, uapi stipulates that requests and responses end with \n\n. Is it possible that you're relying on the socket to EOF, instead of looking for the \n\n? Recent wireguard-go keeps the socket open, in case you want to send one request after another. Jason
Re: Python Wrapper for wireguard-tools
Hi all, Apologies for the delay! I meant to reply much sooner but lost track. I would also encourage you to use the native interfaces as much as possible, rather than binding to C or shelling out to wg(8). If you have any questions about decisions I made in wgctrl-go, I'd be happy to share my thoughts. - Matt On 8/22/20 3:05 PM, Jason A. Donenfeld wrote: Hey Andrew, The most complete "library" is actually the wgctrl-go one from Matt (CC'd). It's complete because it supports all the same interfaces as wg(8) -- Linux Netlink, OpenBSD IOCTL, and x-platform UAPI. The embeddable-wg-library is just for Linux Netlink, but I should maybe refactor that to be more modular. And as you pointed out, the wgnlpy stuff is Netlink also. If you wanted to start a new cross-platform library, and essentially "clone" Matt's Go library into a pure Python one, I'd certainly welcome that effort and would be happy to help. Jason
Re: DNS search domain support in wg-quick
I probably should have tried this sooner, but yep, the PostUp works by stealing what wg-quick is doing with resolvconf, and if you also also set DNS nameservers in the same statement: PostUp = echo -e "nameserver 192.168.1.1 fd00::1\nsearch lan.example.com lan.ipv4.example.com lan.ipv6.example.com" | resolvconf -a tun.%i -m 0 -x - Matt On 2019-09-26 2:40 p.m., Matt Layher wrote: I would like to add DNS search domain support to wg-quick and I have a working patch for Linux. It would look something like: [Interface] Address = fe80::2/128 PrivateKey = (redacted) DNS = 192.168.1.1, fd00::1 DNSSearch = lan.example.com, lan.ipv4.example.com, lan.ipv6.example.com I have a few questions to ask: 1) Is this something that we would like to have upstream? It appears it can also be done manually with a PostUp directive, but this also seems to wipe out the configuration set by the DNS key under the Interface section. 2) What is the policy for adding features like this across multiple platforms? It should be straightforward to port the change from Linux to FreeBSD and OpenBSD, but I'm unsure about Darwin and Android. Darwin appears to have a networksetup flag to do the trick, but the Android C changes would require much more scrutiny. Thanks for your time, Matt ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
DNS search domain support in wg-quick
I would like to add DNS search domain support to wg-quick and I have a working patch for Linux. It would look something like: [Interface] Address = fe80::2/128 PrivateKey = (redacted) DNS = 192.168.1.1, fd00::1 DNSSearch = lan.example.com, lan.ipv4.example.com, lan.ipv6.example.com I have a few questions to ask: 1) Is this something that we would like to have upstream? It appears it can also be done manually with a PostUp directive, but this also seems to wipe out the configuration set by the DNS key under the Interface section. 2) What is the policy for adding features like this across multiple platforms? It should be straightforward to port the change from Linux to FreeBSD and OpenBSD, but I'm unsure about Darwin and Android. Darwin appears to have a networksetup flag to do the trick, but the Android C changes would require much more scrutiny. Thanks for your time, Matt ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
[ANNOUNCE] wgctrl-go (formerly wireguardctrl) moved to WireGuard organization
Hello all, I'm pleased to announce that wgctrl-go (formerly wireguardctrl) has been moved to the WireGuard organization. I'd like to thank Jason for this offer, and for his help in making the transition happen as smoothly as possible. Package wgctrl is a Go package which enables control of WireGuard interfaces on multiple platforms. The new repository can be found at https://github.com/WireGuard/wgctrl-go. It was previously my personal project at https://github.com/mdlayher/wireguardctrl, which now redirects to the new location. The expected Go import path is now "golang.zx2c4.com/wireguard/wgctrl", and code which makes use of this package must be updated accordingly, including the package name switch from "wireguardctrl" to "wgctrl". Documentation can be viewed at https://godoc.org/golang.zx2c4.com/wireguard/wgctrl. At the moment, wgctrl-go supports configuring both Linux kernel and userspace WireGuard devices on UNIX platforms, but Windows support is actively being worked on. My intent is to add support for configuring any type of WireGuard device under a unified Go interface, so please do reach out if you're building a new implementation for a different platform which does not make use of the userspace configuration protocol. If you run into any trouble with wgctrl-go, feel free to reply to this email, file an issue, or reach out on #wireguard on freenode. Thanks for your time, Matt Layher ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Use of __kernel_timespec in userspace genetlink API
Hey all, I recently received a bug report for https://github.com/mdlayher/wireguardctrl which indicated that the timespec structure being returned from the WireGuard genetlink API was not of the expected size on a 32-bit machine. It then occurred to us that the userspace-facing API is returning a "__kernel_timespec"; something I did not realize before: https://git.zx2c4.com/WireGuard/tree/src/uapi/wireguard.h?id=91b0a211861d487382a534572844ff29839064f1#n38 https://git.zx2c4.com/WireGuard/tree/src/netlink.c?id=91b0a211861d487382a534572844ff29839064f1#n112 My C experience is very limited, and I have no experience working on C within the kernel, but is exposing a "__kernel*" type to userspace a normal procedure? I would have expected to see a regular timespec from linux/time.h, or perhaps a timespec64 in its place. I can do some slightly more intelligent checking to fix the current issue with my library, but I wanted to check in and confirm that this API contract is correct. Thanks for your time! - Matt Layher ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: wireguardctrl: Go package that enables control of WireGuard devices on multiple platforms
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. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Kernel module sends infinite netlink messages on v0.0.20180802
I can confirm that this is fixed for me as of latest master: $ dmesg | grep wireguard [ 50.396241] wireguard: module verification failed: signature and/or required key missing - tainting kernel [ 50.396675] wireguard: WireGuard 0.0.20180802-11-gc6505ee loaded. See www.wireguard.com for information. [ 50.396675] wireguard: Copyright (C) 2015-2018 Jason A. Donenfeld . All Rights Reserved. $ sudo ip link add dev wg0 type wireguard $ sudo ./wgnlbug -n 2 before: wg0 after: wg0 - peer: ZoJIpwr1iel/9emt2bNlnHhvasjZdmUD6v92Ry8z1Ro=: 0 IPs - peer: y84s8m/91ryGV8tTQbycauYcukCjrAG1B8vx44BsxWM=: 511 IPs $ sudo wg show interface: wg0 peer: ZoJIpwr1iel/9emt2bNlnHhvasjZdmUD6v92Ry8z1Ro= allowed ips: (none) peer: y84s8m/91ryGV8tTQbycauYcukCjrAG1B8vx44BsxWM= allowed ips: 2001:db8::1ff/128, 2001:db8::1fe/128, ... Thanks for the quick patch. I started with a pretty naive approach on my netlink message chunking implementation, but I'm glad I was able to help find a problem that way. I'll be sure to report anything else I find, but at this point, I think I'm feature-complete for both userspace and kernel APIs. - Matt On 08/08/2018 10:20 PM, Jason A. Donenfeld wrote: On Wed, Aug 8, 2018 at 5:30 PM Matt Layher wrote: Excellent! That's much more concise. Let me know if this fixes it for you, and please do keep messing with weird cases to see if you can find more bugs. I really appreciate you finding this. https://git.zx2c4.com/WireGuard/commit/?id=fd60e07ba3e294b94985a42d11afebf55f1d8829 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: Kernel module sends infinite netlink messages on v0.0.20180802
Excellent! That's much more concise.
- Matt
On Wed, Aug 8, 2018, 8:11 PM Jason A. Donenfeld wrote:
> Thanks for letting me know. I've got a simpler reproducer now:
>
> #!/bin/bash
>
> a=( )
> for i in {1..197}; do
> a+=( abcd::$i )
> done
>
> s="$IFS"
> IFS=,
> a="${a[*]}"
> IFS="$s"
>
> ip link del wg0
> ip link add wg0 type wireguard
> wg set wg0 peer "$(wg genkey)" allowed-ips "$a"
> wg set wg0 peer "$(wg genkey)" allowed-ips "$a"
> wg
>
> I'll have this fixed shortly and will ping back on this thread.
>
> Jason
>
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Kernel module sends infinite netlink messages on v0.0.20180802
Hi all,
While working on wireguardctrl, I found what I believe to be a bug with
the kernel module today. I'm using v0.0.20180802. At first I assumed
that my code was doing something wrong, but I'm able to make "wg show"
hang forever as well, so I believe this to be a problem with the kernel
module itself.
System information:
matt@nerr-2:~$ dmesg | grep wireguard
[ 1075.085912] wireguard: module verification failed: signature and/or
required key missing - tainting kernel
[ 1075.086235] wireguard: WireGuard 0.0.20180802 loaded. See
www.wireguard.com for information.
[ 1075.086235] wireguard: Copyright (C) 2015-2018 Jason A. Donenfeld
. All Rights Reserved.
matt@nerr-2:~$ uname -a
Linux nerr-2 4.15.0-30-generic #32-Ubuntu SMP Thu Jul 26 17:42:43 UTC
2018 x86_64 x86_64 x86_64 GNU/Linux
Here are the steps to reproduce the issue:
Grab my "wgnlbug" Go source program and build it:
https://github.com/mdlayher/wireguardctrl/blob/master/cmd/wgnlbug/main.go
$ go install github.com/mdlayher/wireguardctrl/cmd/wgnlbug
Reset wg0 to a clean state:
$ sudo ip link del dev wg0 && sudo ip link add dev wg0 type wireguard
Attempt to add multiple peers with 511 addresses each (the actual CIDR
is hard-coded for both and doesn't seem to matter). Note that you have
to Ctrl+C the program or it'll hang forever.
$ sudo time ./bin/wgnlbug -n 2
before: wg0
^CCommand terminated by signal 2
1.29user 2.62system 0:02.74elapsed 142%CPU (0avgtext+0avgdata
385236maxresident)k
0inputs+0outputs (0major+98292minor)pagefaults 0swaps
At this point, "wg show" appears to hang forever until something sends
it a KILL (kernel maybe?) as well:
$ sudo time wg show
Command terminated by signal 9
20.88user 40.39system 1:03.31elapsed 96%CPU (0avgtext+0avgdata
12233204maxresident)k
16128inputs+0outputs (92major+3058349minor)pagefaults 0swaps
A look at strace reveals what appears to be an infinite stream of
multi-part netlink messages with identical sequence numbers:
$ sudo strace wg show
...
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=}, msg_namelen=12, msg_iov=[{iov_base={{len=4072,
type=wireguard, flags=NLM_F_MULTI, seq=1533756618, pid=946},
"\x00\x01\x00\x00\x06\x00\x06\x00\x00\x00\x00\x00\x08\x00\x07\x00\x00\x00\x00\x00\x08\x00\x01\x00\x81\x00\x00\x00\x08\x00\x02\x00"...},
iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 4072
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=}, msg_namelen=12, msg_iov=[{iov_base={{len=4068,
type=wireguard, flags=NLM_F_MULTI, seq=1533756618, pid=946},
"\x00\x01\x00\x00\xd0\x0f\x08\x00\xcc\x0f\x00\x00\x24\x00\x01\x00\xc6\x24\x8a\x34\xcc\x3c\x4a\x23\x00\xd4\x94\x8d\xec\x58\xc6\x7c"...},
iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 4068
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=}, msg_namelen=12, msg_iov=[{iov_base={{len=4072,
type=wireguard, flags=NLM_F_MULTI, seq=1533756618, pid=946},
"\x00\x01\x00\x00\x06\x00\x06\x00\x00\x00\x00\x00\x08\x00\x07\x00\x00\x00\x00\x00\x08\x00\x01\x00\x81\x00\x00\x00\x08\x00\x02\x00"...},
iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 4072
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=}, msg_namelen=12, msg_iov=[{iov_base={{len=4068,
type=wireguard, flags=NLM_F_MULTI, seq=1533756618, pid=946},
"\x00\x01\x00\x00\xd0\x0f\x08\x00\xcc\x0f\x00\x00\x24\x00\x01\x00\xc6\x24\x8a\x34\xcc\x3c\x4a\x23\x00\xd4\x94\x8d\xec\x58\xc6\x7c"...},
iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 4068
recvmsg(3, ^C{msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=}, msg_namelen=12, msg_iov=[{iov_base={{len=4072,
type=wireguard, flags=NLM_F_MULTI, seq=1533756618, pid=946},
"\x00\x01\x00\x00\x06\x00\x06\x00\x00\x00\x00\x00\x08\x00\x07\x00\x00\x00\x00\x00\x08\x00\x01\x00\x81\x00\x00\x00\x08\x00\x02\x00"...},
iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 4072
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
strace: Process 946 detached
Hope this is helpful. If it isn't a kernel module problem, I'd be
curious to see what both my code and "wg" are doing that causes this.
It seems to be reproducible 100% of the time on my system.
- Matt Layher
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
wireguardctrl: Go package that enables control of WireGuard devices on multiple platforms
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. ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: wireguardnl: Go package for interacting with WireGuard via generic netlink
An update for those on the list, I've implemented Jason's requested name change and the API is now set up to allow seamless kernel and userspace implementations via https://godoc.org/github.com/mdlayher/wireguardctrl. I will explicitly encourage callers to use this interface rather than the "wireguardnl" package, unless we do end up with useful netlink-specific functionality like the situation I described previously. I'll keep working on this for now and report back when I have a working userspace implementation. Should be quite straightforward compared to dealing with netlink! :) - Matt On 07/23/2018 11:29 AM, Matt Layher wrote: Understood and renamed to "wireguardctrl" to avoid confusion. > But more importantly, you shouldn't expose either the netlink or the xplatform API distinction to users ever. They should be given one interface, not three, and that one interface should be able to select the right thing in 100% of cases. I can't say I agree with this under all circumstances. While I will encourage the use of the unified interface, I read that there could be future work to allow the netlink interface to support something like multicast group notifications. Would you plan on implementing the same functionality for the userspace interface? I think there are potential use cases for selecting one or the other, but if this ends up being untrue, I can always push these packages behind a Go "internal/" directory at a later time to prevent outside imports. - Matt On 07/23/2018 11:12 AM, Jason A. Donenfeld wrote: Hi Matt, This is super interesting and I actually did not discover it until after I pushed the first few commits to my package. I could see it making sense to refactor my current package layout to something like three packages: - wireguardnl: netlink-based communication - wireguardcfg: text-based userspace configuration protocol communication - wireguard: wrapper for both that detects the module in use and seamlessly presents a unified interface No, that's really not a good approach at all. First of all, do not take the raw name "wireguard". That's going to cause a lot of confusion. It's really not appropriate. But more importantly, you shouldn't expose either the netlink or the xplatform API distinction to users ever. They should be given one interface, not three, and that one interface should be able to select the right thing in 100% of cases. Jason ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: wireguardnl: Go package for interacting with WireGuard via generic netlink
Understood and renamed to "wireguardctrl" to avoid confusion. > But more importantly, you shouldn't expose either the netlink or the xplatform API distinction to users ever. They should be given one interface, not three, and that one interface should be able to select the right thing in 100% of cases. I can't say I agree with this under all circumstances. While I will encourage the use of the unified interface, I read that there could be future work to allow the netlink interface to support something like multicast group notifications. Would you plan on implementing the same functionality for the userspace interface? I think there are potential use cases for selecting one or the other, but if this ends up being untrue, I can always push these packages behind a Go "internal/" directory at a later time to prevent outside imports. - Matt On 07/23/2018 11:12 AM, Jason A. Donenfeld wrote: Hi Matt, This is super interesting and I actually did not discover it until after I pushed the first few commits to my package. I could see it making sense to refactor my current package layout to something like three packages: - wireguardnl: netlink-based communication - wireguardcfg: text-based userspace configuration protocol communication - wireguard: wrapper for both that detects the module in use and seamlessly presents a unified interface No, that's really not a good approach at all. First of all, do not take the raw name "wireguard". That's going to cause a lot of confusion. It's really not appropriate. But more importantly, you shouldn't expose either the netlink or the xplatform API distinction to users ever. They should be given one interface, not three, and that one interface should be able to select the right thing in 100% of cases. Jason ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: wireguardnl: Go package for interacting with WireGuard via generic netlink
Hey Jason, Thanks very much for WireGuard and for the information. > Something to consider with this is the chunking. Certainly! This was a first pass but these changes should be reasonable to port to Go as well. I suppose I'll have to introduce some more complicated test devices to this logic. I've filed a couple issues to track this and hope that I can at least implement the chunking get logic this week. > The other thing that might be sort of neat to try to implement is falling back to the userspace API: This is super interesting and I actually did not discover it until after I pushed the first few commits to my package. I could see it making sense to refactor my current package layout to something like three packages: - wireguardnl: netlink-based communication - wireguardcfg: text-based userspace configuration protocol communication - wireguard: wrapper for both that detects the module in use and seamlessly presents a unified interface > The thing you're dumping from a single device is all the peers. If you want a list of all interfaces, then the place to NLM_F_DUMP is RTM_GETLINK, where you can then inspect ifinfomsg->IFLA_LINKINFO->IFLA_INFO_KIND and make sure that it's "wireguard". Ahhh, that makes more sense to me. Perhaps I glossed over the uapi/wireguard.h documentation. For the time being, I'm doing a call to Go's "net.Interfaces" which is a bit easier (though less efficient) than doing rtnetlink calls directly. Perhaps this is something I can iterate on in the future as well. > If you're on IRC, come on into #wireguard on Freenode and poke me, and we can chat about it further; I'm zx2c4. Certainly! I don't have any further inquiries at this time, but I'll join up! Thank you again for WireGuard, and thank you very much for your time, feedback, and answers to my questions. - Matt Layher On 07/23/2018 07:59 AM, Jason A. Donenfeld wrote: Hey Matt, That's terrific! Thanks for making that. I look forward to seeing utilities develop around your library. Something to consider with this is the chunking. Since a device has many peers and a peer has many allowedips, it's possible that these might span multiple messages, larger than the maximum netlink packet size. For that reason, wg(8) will properly split things into several calls. Here's the set call: https://git.zx2c4.com/WireGuard/tree/src/tools/ipc.c#n558 It accounts for toobig_allowedips and toobig_peers with some goto jumps that are sure to make your eyes bleed (read: you can do better than that :-). Similar in the get call, we coalesce peers that span multiple messages: https://git.zx2c4.com/WireGuard/tree/src/tools/ipc.c#n899 https://git.zx2c4.com/WireGuard/tree/src/tools/ipc.c#n877 The other thing that might be sort of neat to try to implement is falling back to the userspace API: https://www.wireguard.com/xplatform/ This is a simple unix socket-based approach that mimics the same semantics as the netlink API, but is portable to different platforms. This is what wireguard-go and wireguard-rs and friends use for configuration. wg(8) implements both and provides an identical frontend for the two. However, I imagine you starting with netlink will be much more useful and is a good decision, since serious wireguard users are expected to continue using the serious kernel implementation. While I'm here, I did have one inquiry about "WG_CMD_GET_DEVICE": after working with a handful of generic netlink families, I was slightly surprised to see that a request paired with "NLM_F_DUMP" doesn't return a list of all WireGuard devices from the kernel. The thing you're dumping from a single device is all the peers. If you want a list of all interfaces, then the place to NLM_F_DUMP is RTM_GETLINK, where you can then inspect ifinfomsg->IFLA_LINKINFO->IFLA_INFO_KIND and make sure that it's "wireguard". WireGuard itself doesn't [necessarily need to] know all of the instances of itself, since it's instantiated by the rtnl subsystem. Check out kernel_get_wireguard_interfaces here: https://git.zx2c4.com/WireGuard/tree/src/tools/ipc.c#n458 If you're on IRC, come on into #wireguard on Freenode and poke me, and we can chat about it further; I'm zx2c4. Talk soon, Jason ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
wireguardnl: Go package for interacting with WireGuard via generic netlink
Hi all! I've heard quite a few good things about WireGuard and decided to try it out at home today. On top of that, I've done a lot of work with netlink and generic netlink in Go, and decided to implement a Go package that can use wireguard's generic netlink interface in the same way as the "wg" tool. To avoid confusion with "wireguard" or "wireguard-go", I've chosen "wireguardnl" as the name: https://github.com/mdlayher/wireguardnl This was just a fun experiment for me (it works, but no tests yet), but perhaps it'll be useful for someone who wants to inspect the kernel module from a Go program (no support for changing settings as of now, but that'd be fun!). While I'm here, I did have one inquiry about "WG_CMD_GET_DEVICE": after working with a handful of generic netlink families, I was slightly surprised to see that a request paired with "NLM_F_DUMP" doesn't return a list of all WireGuard devices from the kernel. Per the documentation, sending an interface index or name attribute works just fine to retrieve a single device, but perhaps it'd be nice to be able to just dump a list of all WireGuard devices when "NLM_F_DUMP" and no attributes are specified. For the time being, I can easily work around this with my "Devices" method by attempting to query the kernel for WireGuard device information about each of my network interfaces, and then filter out the ones that return "ENOTSUP". Thanks for WireGuard, it seems extremely promising so far! - Matt Layher ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
