It is a waste of resources instantiating a NMClient, filling the
object cache and then throwing everything away without using it. This
can take seconds on slow systems with many objects. Since the
ReloadConnections doesn't need anything from the cache, just execute
the D-Bus method call directly.
This will make NetworkManager look up APN, username, and password in the
Mobile Broadband Provider database.
It is mutually exclusive with the apn, username and password properties.
If that is the case, the connection will be normalized to
auto-config=false. This makes it convenient for the user to turn off the
automatism by just setting the apn.
We're dereferencing the info pointer in the argument list in the call to
nm_client_activate_connection_async(). Stealing it at that point causes
a crash.
This reverts a chunk of commit b298f2e605 ('cli: use cleanup macro for
freeing AddAndActivateInfo').
NM didn't support wpa-none for years because kernel drivers used to be
broken. Note that it wasn't even possible to *add* a connection with
wpa-none because it was rejected in nm_settings_add_connection_dbus().
Given that wpa-none is also deprecated in wpa_supplicant and is
considered insecure, drop altogether any reference to it.
Various cleanups:
- after detecting the modifier, remove it from the string right away.
It's redundant and confusing to do it later.
- rename variables and move to inner scope.
- don't use g_str_split() to split the property name at the
first dot. strchr() is sufficient.
Also, now that we strip the modifier from option early, they start also
working for aliases. There is no need to not support (or behave
differently) w.r.t. whether aliases support modifiers or not.
This fixes:
$ nmcli connection modify r +ip4 192.168.5.2/24
Error: invalid <setting>.<property> 'ip4'.
The enum values are unique throughout the source code so they
can easier be searched (e.g. with grep), compared to '\0'. It
is often interesting where a certain modifier is used, so searching
the source code is important to give relevant results.
Also, the modifier is really an enum and we shouldn't misuse char type.
If that would be a good idea in general, we wouldn't need any enums
at all. But we use them for good reasons.
$ nmcli connection add type ethernet con-name t autoconnect no
Error: ifname argument is required.
This reverts commit a91eafdf95 ('cli: 'con add': make ifname mandatory
(except bond,bridge,vlan) (bgo #698113)'). Apparently ifname argument was
required to avoid confusion (unexpected behavior). But I don't agree
that is an issue, it's just annoying. Often you really have just one
ethernet or Wi-Fi device, so this does not seem helpful.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/222
Up until now, a default-route (with prefix length zero) could not
be configured directly. The user could only set ipv4.gateway,
ipv4.never-default, ipv4.route-metric and ipv4.route-table to influence
the setting of the default-route (respectively for IPv6).
That is a problematic limitation. For one, whether a route has prefix
length zero or non-zero does not make a fundamental difference. Also,
it makes it impossible to configure all the routing attributes that one can
configure otherwise for static routes. For example, the default-route could
not be configured as "onlink", could not have a special MTU, nor could it be
placed in a dedicated routing table.
Fix that by lifting the restriction. Note that "ipv4.never-default" does
not apply to /0 manual routes. Likewise, the previous manners of
configuring default-routes ("ipv4.gateway") don't conflict with manual
default-routes.
Server-side this all the pieces are already in place to accept a default-route
as static routes. This was done by earlier commits like 5c299454b4
('core: rework tracking of gateway/default-route in ip-config').
A long time ago, NMIPRoute would assert that the prefix length is
positive. That was relaxed by commit a2e93f2de4 ('libnm: allow zero
prefix length for NMIPRoute'), already before 1.0.0. Using libnm from
before 1.0.0 would result in assertion failures.
Note that the default-route-metric-penalty based on connectivity
checking applies to all /0 routes, even these static routes. Be they
added due to DHCP, "ipv4.gateway", "ipv4.routes" or "wireguard.peer-routes".
I wonder whether doing that unconditionally is desirable, and maybe
there should be a way to opt-out/opt-in for the entire profile or even
per-routes.
https://bugzilla.redhat.com/show_bug.cgi?id=1714438
... and nm_utils_fd_get_contents() and nm_utils_file_set_contents().
Don't mix negative errno return value with a GError output. Instead,
return a boolean result indicating success or failure.
Also, optionally
- output GError
- set out_errsv to the positive errno (or 0 on success)
Obviously, the return value and the output arguments (contents, length,
out_errsv, error) must all agree in their success/failure result.
That means, you may check any of the return value, out_errsv, error, and
contents to reliably detect failure or success.
Also note that out_errsv gives the positive(!) errno. But you probably
shouldn't care about the distinction and use nm_errno_native() either
way to normalize the value.
Our coding style is to indent with tabs, but align with spaces.
This is not about the coding style though, but about the code
looking broken when not using 4 spaces per tab (in fact, some code
there is aligned as if using 8 spaces and it's already inconsistent).
Realign with spaces.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/223
We should prefer the cleanup macors nm_auto*() because they express
ownership in code.
Also, they allow to return early without additional cleanup code.
That way we can refactor if-else blocks.
Also, in cases where we intentionally pass on the reference, we use
g_steal_pointer(), which literally spells out what happens in code.
If we find a matching connection, ensure it's exactly as we want it
before actually proceeding to activate it. Fixes this problem:
# nmcli dev wifi connect "Network of Doom" password santa <-- bad
Error: Connection activation failed: (7) Invalid secrets
# nmcli dev wifi connect "Network of Doom" password satan <-- correct
Error: Connection activation failed: (7) Invalid secrets
The password is now correct, but nmcli chose to re-activate the wrong
connection it created previously.
Do not check for password when creating a simple connection object for
"nmcli dev wifi connect".
This makes no difference in practice. The password is checked for
existence later on and the connection instance is created anyway. This
just makes things look a bit more consistent.
Coverity correctly points out that nm_setting_vlan_get_num_priorities() can return
a negative value (-1 on assertion). Handle that by using the right integer type.
Instead of straight-out rejecting extra parameters for various nmcli
sub-commands (such as "nmcli dev status", "nmcli dev wifi rescan" or
"nmcli dev wifi connect", etc.), we just print a warning and go ahead.
This is unhelpful. In case the user makes a typo, we'll do the wrong
thing and possibly even drown the warning in the output.
While at that, let's make the error message consistent. One less string
to translate.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/217
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
Make use of the new API. Note that AddConnection2() covers all
functionality of AddConnection() and AddConnectionUnsaved(). Let's
only use one API for all.
There is a minor downside to this patch: now nmcli requires
libnm 1.20 API. Note that libnm's nm_client_add_connection2()
makes an effort to avoid AddConnection2() under the hood to
still work against older server versions. So, you can use nmcli
with libnm 1.20 to talk to older versions of NetworkManager.
But with this change nmcli strictly requires libnm 1.20. I think that is
sensible because commonly nmcli requires a libnm version that is as new
as itself.
Also, the value of allowing nmcli to talk to older NetworkManager
versions is during package upgrade (where the daemon might not be
restarted). This is much less concern w.r.t. to updating the nmcli/libnm
combo, which is commonly packaged together.
Initscripts already honor the DEVTIMEOUT variable (rh #1171917).
Don't make this a property only supported by initscripts. Every
useful property should also be supported by keyfile and it should
be accessible via D-Bus.
Also, I will soon drop NMSIfcfgConnection, so handling this would
require extra code. It's easier when DEVTIMEOUT is a regular property of
the connection profile.
The property is not yet implemented. ifcfg-rh still uses the old
implementation, and keyfile is not yet adjusted. Since both keyfile
and ifcfg-rh will both be rewritten soon, this property will be
implemented then.
