fastd: add L2TP offload support

[neocturne]

This is still a WIP, in particular because fastd v22 hasn't been released yet. In addition to more testing, I'm also thinking about (optionally) statically linking the required parts of libmnl into fastd to reduce the size before v22 final. libmnl is linked into fastd statically now.

• Most of the added logic is in gluon-mesh-vpn-fastd; the new package/feature gluon-mesh-vpn-fastd-l2tp only contains a marker file
• With configurable = true, we always add null@l2tp before null, so the L2TP method is preferred
• The old GMAC-based methods are not supported anymore
• When mesh-vpn-fastd-l2tp is included, the following changed are applied to the fastd configuration:
  • offload_l2tp = 1. This also requires persisist_interface = 0 and mode = 'multitap'.
  • Toplevel peer_limit is set to 1, as Gluon supports only a single mesh_vpn interface
• The interface of each peer config is set to "mesh_vpn", so the interface for the single connection is correctly named "mesh_vpn" in Multi-TAP mode

On supernodes the following changes are necessary:

• Update to latest "main" branch of fastd
• Add "null@l2tp" to the front of the method list

By only enabling L2TP offloading on the Gluon nodes and not the super nodes, no other changes are necessary on the super nodes. If CPU performance is problematic on supernodes, L2TP offloading can be enabled on the supernode as well, but this will require more complex config adjustments, as a separate interface will be created for each peer.

Due to the inclusion of the L2TP kernel support, enabling the mesh-vpn-fastd-l2tp Gluon feature increases the image size (by roughly 9.2KiB on ar71xx-generic, compared to an image with the same configuration and only mesh-vpn-fastd).

TODO:

• fastd v22 release
• Testing
• Documentation

[kaechele]

Preliminary testing is looking promising. I was able to compile a build, run it in a VM and have it connect to a fastd server in L2TP offload mode. Performance is consistent with using Tunneldigger as an L2TP broker (as expected).
I will test this on actual hardware and with multiple clients tomorrow.

Thanks! This is looking good so far.

[neocturne]

I've just pushed an update that fixes opkg behaviour for "provides" for non-virtual packages. Without this patch, opkg would always prefer fastd-l2tp to satisfy gluon-mesh-vpn-fastd's dependency instead of defaulting to fastd, significantly increasing image size for configurations with non-L2TP fastd.

[neocturne]

As it turns out, the small opkg patch is not sufficient to make this work in all cases. It seems that the package dependency resolution of opkg still can't properly deal with dependencies that are satisfied via "provides" ... Making the build work reliably may take some time.

[neocturne]

As I don't think we can sufficiently improve opkg's dependency resolution wit acceptable effort, I have enabled L2TP support by default in the fastd package now instead of providing two different variants. The L2TP kernel modules are still only installed when the mesh-vpn-fastd-l2tp feature is enabled, so this doesn't waste too much space when L2TP is not needed.

Documentation of the new feature is still TODO.

[kaechele]

Documentation of the new feature is still TODO.

Happy to take a first stab at it unless you already started doing it.

[neocturne]

Documentation of the new feature is still TODO.

Happy to take a first stab at it unless you already started doing it.

Thanks for the offer, I haven't started yet.

[kaechele]

Stab No. 1: #2251
Please review wording, I may have used cipher and method interchangeably in ways that don't make sense.

[herbetom]

I'm currently testing this on two of my nodes. So far i'm quite happy with it and hadn't any problems. 👍

Once i find some time i will try to add this to the FFRN nightly branch.

Site: Freifunk-Rhein-Neckar/site-ffrn@d4fd95d

[neocturne]

I've rebased this and included the documentation contributed by @kaechele (#2251). It is now based on #2349 (hence labelled as blocked).