and nm_vpn_connection_get_ip_ifindex(). For VPN types that have no own
IP interface, we often want instead lookup the IP interface from the
parent device.
ip_iface and ip_ifindex come as a pair. They must be either set both, or not
at all. Ensure that whenever setting one, the other is set too (or cleared).
Add a new "Config" property to the D-Bus interface for team devices
and show its value through "nmcli device show". The property contains
the full JSON configuration from teamd for the device.
https://bugzilla.redhat.com/show_bug.cgi?id=1310435
Sometimes the netlink event lacks the IFLA_ADDRESS attribute with
the MAC address of the link. In this case, take the value from
the cached link instance. A missing netlink attribute should have the
meaning of reusing the previous value, not clearing the address.
Introduce two environment variables to configure logging
for the VPN plugins:
- NM_VPN_LOG_LEVEL: when set, a syslog logging level (0-7).
- NM_VPN_LOG_SYSLOG: either 0 or 1, whether the plugin should
log to stdout or syslog. Basically, if NetworkManager itself
runs in the forground, we also want that the plugin logs
to stdout.
This logging domain will be used to enable debugging of the VPN plugins.
However, the plugins might expose sensitive data in this mode, so exclude
the new domain from "LOGD_ALL".
This is not C# but glib. Using interfaces is so cumbersome, that they
don't simplify code but make it more complicated.
E.g. following signals and its subscribers is complicated enough. It gets
more complicated by having NM_SETTINGS_SIGNAL_CONNECTION_ADDED and
NM_CP_SIGNAL_CONNECTION_ADDED. Of course, your favorite IDE has no idea
about glib interfaces, so figuring out who calls who gets more
complicated.
This undoes commit 4fe48b1273. Originally,
NMConnectionProvider had only one function get_best_connection(). But it
kept growing and more functions were added.
If we want to ~hide~ certain part of the NMSettings API, we should move them
to a separate header which gives internal access.
Instead of accessing the singleton getter nm_settings_get(), obtain
the settings instance from the device instance itself via
nm_device_get_settings().
This will replace nm_connection_provider_get_connections(), but has
a different API.
Instead of returning a (const) GSList list, it returns a (cached) NULL
terminated array. The reason for this change is simply that I find
arrays more convenient to use (in this case) and it doesn't have the
overhead of a GSList instance per entry.
Like with nm_connection_provider_get_connections(), cache the result
internally. This for one is more convenient for the caller, which
doesn't need to free the result. On the other hand, the list of
connections is fairly static, this allows us to reuse the same list.
nm_settings_get_connections() returns a sorted list. We have many users
of nm_connection_provider_get_connection(), which returns the same result,
but undefined order.
Next NMConnectionProvider will be dropped. Thus, we don't want to
seamlessly replace nm_connection_provider_get_connection() by a sorted
version nm_settings_get_connections().
Rename nm_settings_get_connections() to make clear it is sorted.
Downstream might want to choose a different default value for
main.rc-manager setting (and it can does so, by compiling with
explicit resolvconf or netconfig support).
Make the default configurable at build-time and also embed it into
the manual page of "NetworkManager.conf".
https://bugzilla.redhat.com/show_bug.cgi?id=1337222
This sorts the entries of the [vpn] section alphabetically.
The sorting order doesn't really matter, but having a defined,
stable way to export a connection is preferred. Also, it looks
better when looking at the keyfile with an editor.
Currently NM proceeds with the activation of a device just after the
IPv6 configuration is applied. Server applications will bind to IPv6
addresses as soon as NM signals the presence of network connectivity,
but since the addresses are still tentative the bind will fail. There
are a couple of solutions to this.
Linux kernel supports "optimistic DAD", which is a modification of
Neighbor Discovery and SLAAC processes that allows addresses to be
used (under certain contraints) while kernel is performing DAD on
them. However it is not feasible to let NM enable optimistic DAD for
the devices it controls for the following reasons:
- it is not guaranteed to be always available since it can be turned
off at compile time
- RFC 4429 states that it should not be used for manually entered
addresses
- it works only with autoconf addresses generated by kernel
Therefore, use a different approach and handle this in NM by waiting
that the kernel completes DAD before continuing activation. We build a
list of addresses that are tentative just after the new configuration
is applied and then we asynchronously wait a platform address-change
event where all NM-configured addresses become non-tentative.
A similar solution has been adopted also by other network managing
tools:
https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f8012cd3919https://bugzilla.redhat.com/show_bug.cgi?id=1243958
With this check, the function is safe to use even with invalid
logging levels. But it can still be inlined as for most cases
@level is a (enum) constant and the check can be evaluated at
compile time.
Oddly enough, on a default build with
./autogen.sh && make && strip ./src/NetworkManager
this patch decreases the size of the binary by 8k.
Basically every logging statement is wrapped by a nm_logging_enabled()
to evaluate the function call of the logging lazy.
Make the function a candidate for inlining, it safes some space. On
a default build it goes for me from 2580584 to 2560104 bytes (20k).
$ ./autogen.sh && make && strip ./src/NetworkManager
We really expect this assertion not to be violated.
As we want for nm_logging_enabled() to become smaller and inline,
remove the runtime assertion from regular builds.
Live fast and dangerous.
Instead of calling _ensure_initialized() at various places
to ensure that we setup logging before any logging commands
are executed, initialize the logging fields in the global variable.
This removes code from nm_logging_enabled(), which we want to
become a static inline function.
When one of the configuration snippet is malformed, NM doesn't tell
which file caused the error:
$ NetworkManager --print-config
Failed to read configuration: Key file does not start with a group
Fix this.
$ NetworkManager --print-config
Failed to read configuration: /usr/lib/NetworkManager/conf.d/test.conf: Key file does not start with a group
As explained in the function comment, a NULL value for @val is
acceptable. Otherwise:
$ nmcli connection edit
(process:2276): nmcli-CRITICAL **: check_valid_name: assertion 'val' failed
Fixes: fb8fe1d8cb
Instead of using (only) a hard-coded list of VPN types,
prefer lookup the VPN settings from the .name files.
Still, fallback to a hard-coded list if the plugin cannot
be found, because for connection-add we currently don't
actually need the plugin installed.
GCC can place each symbols into separate sections making it possible for
ld to discard unneeded sections (and thus symbols afterwards). This achieves
almost the same size benefits as LTO without the huge performance
penalty (and the undefined behavior with -g).
The cost of more section headers in .o files seems to be negligible.
Before:
359.73user 71.94system 1:29.67elapsed 481%CPU (0avgtext+0avgdata 137948maxresident)k
text data bss dec hex filename
2772228 74848 9272 2856348 2b959c src/NetworkManager
With LTO:
740.37user 94.89system 4:13.83elapsed 329%CPU (0avgtext+0avgdata 118316maxresident)k
text data bss dec hex filename
2435437 74224 8704 2518365 266d5d src/NetworkManager
With --gc-sections:
365.63user 72.34system 1:30.12elapsed 485%CPU (0avgtext+0avgdata 138016maxresident)k
text data bss dec hex filename
2498498 74040 8408 2580946 2761d2 src/NetworkManager
