On Thu, 2018-02-15 at 16:07 +0100, Jason A. Donenfeld wrote: > Hi Thomas, > > Upstream WireGuard here.
Hi Jason, thanks for reaching out. > > I still think, it would be great to have wireguard support in > > NetworkManager not via a VPN plugin. But that is for another day. > > I fully agree, and I'd be happy to work with you on doing this, if > you're interested. For this, you can either attempt to reuse the > systemd-networkd stuff, or roll it yourself, likely using some > derivative of this code: > https://lists.zx2c4.com/pipermail/wireguard/2018-February/002387.html > . It doesn't look like you're using any of the systemd netlink > library > stuff now, so it may indeed be best to roll it yourself. > > I've been suggesting to Max that he makes his plugin talk to the > kernel directly, because the current implementation of shelling out > to > wg-quick has numerous problems and so the current plugin shouldn't be > used as is. But hopefully it'll get there. > > Are you interested in working on real non-plugin NetworkManager > integration? If so, maybe find me on freenode (I'm zx2c4), and we can > discuss. Yes, we are interested in that, but currently nobody did any work on that (AFAIK). But once somebody picks it up, it should be doable quickly. As wireguard support got added to networkd, I supposed the netlink API is reasonably stable? We were still waiting until the kernel part is merged upstream. But that is not a blocker, merely a reason for wireguard support not having a sufficiently high priority to implement it -- until now. Looking forward for that, best, Thomas ======= PS: a few details that might help with implementation. I think it would be a better expirience if wireguard would by directly supported by NetworkManager. The main reason for that is, that the VPN API is not as powerful as it should be, so VPN plugins unfortunately feel a bit alien. That should possibly be improved. But there is really no strong reason why wireguard has to be a VPN "plugin". It certainly is more complex to get a great expirience and the only benefit seems to be that it's maintained outside of NetworkManager's source tree. NetworkManager knows "device plugin". These are shared libraries loaded by NM to support certain device types. There is no stable ABI, hence all plugins must be in-tree and match NM's version. The use of them is mainly to reduce package dependencies of the core NetworkManager package, and reduce the binary size if you don't need it. Device plugin sources are sub directories in [1]. Essentially, device plugins consist of subclass of NMDevice and a factory to create them. Since a wireguard plugin has no external dependencies, probably it shouldn't be a "device plugin" but just statically linked into the core daemon. The only downside would be an increase of the binary size -- which is probably better then the burden of a separate package. All you need is a "nm-device-wireguard.c" file in [1]. Maybe looking at "NMDeviceMacsec" would be a good start [2]. [1] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/devices?id=7621fe4e1a6da7d61fe9e9398937bc5dd536c8be [2] https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=1a24f528c8645148e9612adff34d6edf70fdbb34 What is also needed, is how clients (nmcli, nm-connection-editor) configure a wireguard setting. That commonly works by having a "NMSettingWireguard" in libnm-core to contain all properties relevant for wireguard. Unfortunately, it tends to be a bit combersome to implement these setting classes. See also [2] for how it was done for Macsec. Wireguard's peers are complex objects, similar to NMSettingIPConfig's NMIPRoute/NMIPAddress. I think NM would not re-use systemd's netlink implementation. We fork (copy + paste) parts of systemd's source tree [3], but we only use the parts that we really want from there (like DHCPv4, DHCPv6, LLDP). We don't use any netlink related systemd API directly, and I think we shouldn't. The main reason is that we already have our way to handle netlink (which works quite well). Switching to systemd API would be a large effort, only to end up with something that is less flexible to our needs. [3] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/systemd/src?id=7621fe4e1a6da7d61fe9e9398937bc5dd536c8be The embeddable-wg-library is very nice! and we certainly should look at that for inspiration, same for the networkd code. But I think we should take the relevant netlink parts and extend our existing netlink code. We are about to drop using libnl3 [4]. I personally think that netlink is convenient enough, hence for a large project like NetworkManager it seems preferrable to craft our own netlink code that suits our needs best. [4] https://github.com/NetworkManager/NetworkManager/pull/67 We need to support rtnetlink for wireguard, which all happens in NMPlatform [5] [6]. [5] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/platform/nm-linux-platform.c?id=7621fe4e1a6da7d61fe9e9398937bc5dd536c8be#n1389 [6] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/platform/nm-linux-platform.c?id=7621fe4e1a6da7d61fe9e9398937bc5dd536c8be#n5432 Currently, we only use generic netlink for nl80211. I am contemplating, whether nl80211 and wireguard should both re-use the one netlink socket from the NMPlatform singleton instead of opening multiple sockets. That would require to integrate the genl requests into platform's send-receive code [7]. Not sure about that though... [7] https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/platform/nm-linux-platform.c?id=7621fe4e1a6da7d61fe9e9398937bc5dd536c8be#n6775
signature.asc
Description: This is a digitally signed message part
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
