The recommended netlink buffer size is based on the system's page size,
which means that the current size is far too small for systems with 16k
or 64k pages, such as Asahi Linux or RHEL's kernel-64k for ARM64. On
these systems, the server fails to start with errors like this:
Error: Decode error occurred: invalid netlink buffer: length field says 1444 the buffer is 1260 bytes long
Instead, follow the kernel's own netlink docs to compute the buffer
size. The approach here matches the approach merged into Chromium
recently:
https://chromium-review.googlesource.com/c/chromium/src/+/4312885
The maintenance badge leads to https://gist.github.com/cheerfulstoic/d107229326a01ff0f333a1d3476e068d
_Actively Maintained_ is described there as
> The maintainer(s) of this project are responding to issues and integrating code contributions
...which should set the correct expectations for people stumbling upon. Not explicitly said, but I count that also means we'll be doing (minor, mostly) releases.
Should fix#242.
We depend on `getrandom` feature of `rand_core`, but we weren't specifying that.
It worked because `curve25519-dalek 4.0.0-pre.2` was pulling the `getrandom` feature of `rand_core`, but after updating it to `4.0.0-pre.5` it stopped pulling `rand_core` altogether.
After the cargo-update, all out dependencies are on their newest version, sans clap 3.2, which could be updated to 4.0. It has quite some breaking API changes, so I'll leave that for a separate PR.
Using nightly one leads to having to resolve lints more frequently than rust releases, which is
getting inconvenient.
It also leads to a small compatibility issue with stable clippy: if we need to #[allow] a lint that
is only present in nightly clippy, then stable clippy complains about unknown ling in the `allow`.
* client: Update enable_or_disable_peer exit message to be more accurate
* server: Implement disable-peer and enable-peer commands
* server: Immediately apply enable- and disable-peer to device
- fix#228
- the musl libc is used on Alpine, a minimal linux distribution commonly
used in docker images. It's also used on OpenWRT which might be of
interest to innernet.
Since peer endpoints can be either IPv4 or IPv6, it doesn't make sense
to specify a default MTU that could only work with IPv4 based on only
the server's endpoint.
Setting to 1412 instead of 1420 in order to accomodate PPPoE peers,
which should fit most internet situations.
Ryan Gonzalez