For WireGuard (like for all IP-tunnels and IP-based VPNs), the IP addresses of
the peers must be reached outside the tunnel/VPN itself.
For VPN connections, NetworkManager usually adds a direct /32 route to
the external VPN gateway to the underlying device. For WireGuard that is
not done, because injecting a route to another device is ugly and error
prone. Worse: WireGuard with automatic roaming and multiple peers makes this
more complicated.
This is commonly a problem when setting the default-route via the VPN,
but there are also other subtle setups where special care must be taken
to prevent such routing loops.
WireGuard's wg-quick provides a simple, automatic solution by adding two policy
routing rules and relying on the WireGuard packets having a fwmark set (see [1]).
Let's also do that. Add new properties "wireguard.ip4-auto-default-route"
and "wireguard.ip6-auto-default-route" to enable/disable this. Note that
the default value lets NetworkManager automatically choose whether to
enable it (depending on whether there are any peers that have a default
route). This means, common scenarios should now work well without additional
configuration.
Note that this is also a change in behavior and upon package upgrade
NetworkManager may start adding policy routes (if there are peers that
have a default-route). This is a change in behavior, as the user already
clearly had this setup working and configured some working solution
already.
The new automatism picks the rule priority automatically and adds the
default-route to the routing table that has the same number as the fwmark.
If any of this is unsuitable, then the user is free to disable this
automatism. Note that since 1.18.0 NetworkManager supports policy routing (*).
That means, what this automatism does can be also achieved via explicit
configuration of the profile, which gives the user more flexibility to
adjust all parameters explicitly).
(*) but only since 1.20.0 NetworkManager supports the "suppress_prefixlength"
rule attribute, which makes it impossible to configure exactly this rule-based
solution with 1.18.0 NetworkManager.
[1] https://www.wireguard.com/netns/#improved-rule-based-routing
NMPlatformObject is a base-type of all actual platform structs.
We very seldomly use this type directly. Most callers that pass
the plobj to nmp_object_new() will need to cast it.
Make the varible a void pointer to not require the cast.
nm_connection_get_setting() returns a pointer of type NMSetting.
That is very inconvenient, because most callers will need the
the result pointer as a setting subtype (like NMSettingConnection).
That would be like g_object_new() returning a "GObject *" pointer,
which is technically correct but annoying.
In the past that problem was avoided by having countless accessors
like nm_connection_get_setting_ip4_config(), etc. But that just blows
up the API and also is not generic. Meaning: the type is not a function
argument but the function itself. That makes composing the code harder
as the setting type cannot be treated generically (as a function argument).
Anyway. Add an internal wrapper that returns a void pointer.
mesh connections can be started at any time but prevent a connection
using ip auto configuration to start, if no mesh point providing the
network is in range.
To allow completion for mesh connections channel and band need to be
set. This is only done if both values are absent. It does not check
existing values against a given ap_freq. This maybe changed to throw an
error and detect a possible conflict. Any other check is left to verify
step of connection.
This change allows to use ap freq during complete. For tests 0 is passed
as frequency for now. This needs to be changed if completion of freq
should be tested.
[lkundrak@v3.sk, thaller@redhat.com: formatting fixes]
an essential feature of 802.11s is to allow moving/mobile mesh points
and adapt the topology dynamically. This includes starting a mesh point
not in range of others and establish the connection once it comes into
range. At the moment for this reason a mesh connection requires the
frequency to be fixed as supplicant does too.
mark ap if supplicant reports bss property "Mode = 'mesh'".
bss mode mesh is available since hostap_2_6-729-g213eb1885
check mesh connections are compatible with detected mode.
This ensures that we know whether wpa_supplicant was built with
CONFIG_MESH enabled.
[andreas.kling@peiker-cee.de: add add PROP_MESH_SUPPORT to
set_property()]
deactivate switches the device back to infrastructure mode for
compatibility reasons. This will prevent supplicant from de-assosiating
non-infrastructure connections as the interface goes down.
Disconnect asynchronously and wait for the result. This is required for
e.g. 802.11s mesh.
allow to call dbus method "Disconnect" and handle a callback given by
the caller. This allows graceful disconnects that require to wait for
the operation to complete.
Tombstones in /etc are not only to hide storages of type keyfile. They
are for hiding/shadowing any profile from persistant storage. That's
why we need to compare them already in _sett_conn_entry_sds_update().
Fix the prioriy of storages for the same UUID.
Note that the "$UUID.nmmeta" files (the tombstones) are handled by
keyfile plugin. But that is only to load them together during `nmcli
connection reload` when we iterate the files of the system-connections
directory. For the most part, nmmeta/tombstones are not keyfile specific
and handled by NMSettings. A tombstone in /run hides any profile (regardless
of the settings plugin). And a tombstones in /etc hides any profile, except
in-memory connections from keyfile /run directory.
Note that we now support keyfiles from read-only storage in /usr/lib.
Note also that we do support modifying and deleting these profiles.
That works by placing a shadowing profile to /etc or /run.
Surely this is questionable. It means that once the user uses D-Bus
to modify/delete a profile in /usr/lib, that profile becomes forever
shadowed by a different file, and there is no D-Bus API to return
to the original file. The user would have to drop the shadowing storages
from the file system. That is a problem.
But on the other hand, disallowing changes to such read-only profiles
is not very useful either. If you no longer can use D-Bus to modify such
profiles, what's the value here? How are applications supposed to handle
such profiles if there is no D-Bus API to do something sensible to them?
So, whatever problems read-only profiles and this shadowing causes, I don't
think that the solution is to entirely disallow changes via D-Bus.
At that point, we can just as well allow changes to profiles from
ifupdown. Note that you still cannot modify the profile directly (as the
ifupdown plugin does not support that). But you can delete the profile
(either temporarily via a tombstone in /run or permanently via a
tombstone in /etc). You also can make the profile in-memory, and take
it from there. Note that if you try to later store the in-memory profile
to disk again, then it depends on the order of settings plugins whether
that succeeds. If you have "plugins=keyfile,ifupdown", then the profile
will be stored as keyfile to /etc. If you have "plugins=ifupdown,keyfile",
then the modification will only be done in /run and the "to-disk" command
silently ignored (there really is no better solution).
First of all, the generated profile also gets generated as keyfile to
/run, thereby it looses the read-only flag (because this flag gets lost
when storing the profile to keyfile).
Second, I don't think we should artificially limit the capabilities
of the generated profile. If the user chooses to modify/delete it, so
just allow it.
