wireguardnl: Go package for interacting with WireGuard via generic netlink
mdlayher at gmail.com
Mon Jul 23 17:59:12 CEST 2018
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! :)
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
> - 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
>>> 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
>>> - wireguardnl: netlink-based communication
>>> - wireguardcfg: text-based userspace configuration protocol
>>> - 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.
More information about the WireGuard