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
[email protected]
https://lists.zx2c4.com/mailman/listinfo/wireguard
