When the IPv4 method is 'auto' and there are static addresses
configured in the connection, start a DAD probe for the static
addresses and apply them immediately on success, without waiting for
DHCP to complete.
Note that if the static address is in the same subnet of the DHCP one,
when we add the DHCP address we want it to be primary and so we will
remove the static address temporarily to achieve the right order of
addresses.
https://bugzilla.redhat.com/show_bug.cgi?id=1369905
_nm_utils_init() is a __attribute__((constructor)) function,
that is, it runs during dlopen().
On the other head, g_module_open() itself calls dlopen().
It is prone to deadlock. Don't do it.
The check is only an aggressive assertion to crash the application
if it wrongly loads libnm and libnm-util/libnm-glib at the same time.
If that happens, all is lost already. We can just as well call the
assertion later. It's not supposed to fail anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=796804
Some properties in NetworkManager's D-Bus API are IPv4 addresses
in network byte order (big endian). That is problematic.
It is no problem, when the NetworkManager client runs on the same
host. That is the case with libnm, which does not support to be used
remotely for the time being.
It is a problem for an application that wants to access the D-Bus
interface of NetworkManager remotely. Possibly, such an application
would be implemented in two layers:
- one layer merely remotes D-Bus, without specific knowledge of
NetworkManager's API.
- a higher layer which accesses the remote D-Bus interface of NetworkManager.
Preferably it does so in an agnostic way, regardless of whether it runs
locally or remotely.
When using a D-Bus library, all accesses to 32 bit integers are in
native endianness (regardless of how the integer is actually encoded
on the lower layers). Likewise, D-Bus does not support annotating integer
types in non-native endianness. There is no way to annotate an integer
type "u" to be anything but native order.
That means, when remoting D-Bus at some point the endianness must be
corrected.
But by looking at the D-Bus introspection alone, it is not possible
to know which property need correction and which don't. One would need
to understand the meaning of the properties.
That makes it problematic, because the higher layer of the application,
which knows that the "Nameservers" property is supposed to be in network
order, might not easily know, whether it must correct for endianness.
Deprecate IP4Config properties that are only accessible with a particular
endianness, and add new properties that expose the same data in an
agnostic way.
Note that I added "WinsServerData" to be a plain "as", while
"NameserverData" is of type "aa{sv}". There is no particularly strong
reason for these choices, except that I could imagine that it could be
useful to expose additional information in the future about nameservers
(e.g. are they received via DHCP or manual configuration?). On the other
hand, WINS information likely won't get extended in the future.
Also note, libnm was not modified to use the new D-Bus fields. The
endianness issue is no problem for libnm, so there is little reason to
change it (at this point).
https://bugzilla.redhat.com/show_bug.cgi?id=1153559https://bugzilla.redhat.com/show_bug.cgi?id=1584584
nm_gobject_notify_together() freezes the notifications to emit both
notification signals together. That matters for NMDBusObject base
class, which hooks into dispatch_properties_changed() to emit a combined
"PropertiesChanged" signal.
Note, that during calls like nm_ip4_config_replace(), we already
froze/thawed the notifications. So, this change adds unnecessary
freeze/thaw calls, because signal emition is already frozen.
That is a bit ugly, because g_object_freeze_notify() is more heavy
than I'd wish it would be.
Anyway, for other places, like nm_ip4_config_reset_routes() that is
not the case. And correctness trumps performance.
Ultimately, the issue there is that we use NMIP4Config / NMIP6Config
both to track internal configuration, and to expose it on D-Bus.
The majority of created NMIP4Config / NMIP6Config instances won't get
exported, and but still pay an unnecessary overhead. The proper solution
to minimize the overhead would be, to separate these uses.
NM_GOBJECT_PROPERTIES_DEFINE() defines a helper function
_notify() to emit a GObject property changed notification.
Add another helper function to emit multiple notifications
together, and freeze/thaw the notification before.
This is particularly useful, because our D-Bus glue in
"nm-dbus-object.c" hooks into dispatch_properties_changed(),
to emit a combined PropertiesChanged signal for multiple
properties. By carefully freezing/thawing the notifications,
the exported objects can combine changes of multiple properties
in one D-Bus signal.
This helper is here to make that simpler.
Note that the compiler still has no problem to inline _notify()
entirey. So, in a non-debug build, there is little difference in
the generated code. It can even nicely inline calls like
nm_gobject_notify_together (self, PROP_ADDRESS_DATA,
PROP_ADDRESSES);
CC src/devices/ovs/src_devices_ovs_libnm_device_plugin_ovs_la-nm-device-ovs-bridge.lo
In file included from src/devices/ovs/nm-device-ovs-bridge.c:20:
In file included from ./shared/nm-default.h:307:
In file included from ./src/nm-logging.h:25:
./libnm-core/nm-core-types.h:28:10: fatal error: 'nm-core-enum-types.h' file not found
#include "nm-core-enum-types.h"
^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
CC src/settings/plugins/ifupdown/src_settings_plugins_ifupdown_libnms_ifupdown_core_la-nms-ifupdown-interface-parser.lo
In file included from src/settings/plugins/ifupdown/nms-ifupdown-interface-parser.c:23:
In file included from ./shared/nm-default.h:307:
In file included from ./src/nm-logging.h:25:
./libnm-core/nm-core-types.h:28:10: fatal error: 'nm-core-enum-types.h' file not found
#include "nm-core-enum-types.h"
^~~~~~~~~~~~~~~~~~~~~~
1 error generated.
make: *** [Makefile:13904: src/settings/plugins/ifupdown/src_settings_plugins_ifupdown_libnms_ifupdown_core_la-nms-ifupdown-interface-parser.lo] Error 1
Utilize _nm_setting_to_dbus() to serialize the setting. The main reason
is that this way we can also print the more complicated values
g_strdup_value_contents() can't grok, e.g. the GArrays and GHashTables.
Some effort was spent on tidying up the results in a manner it was done
previously, instead of reducing this to a plain g_variant_print(). It
looks good that way:
Before:
vpn
service-type : "org.freedesktop.NetworkManager.VPN.Novpn" (s)
user-name : NULL (sd)
persistent : FALSE (sd)
data : ((GHashTable*) 0xc61060) (s)
secrets : ((GHashTable*) 0xdda640) (s)
timeout : 0 (sd)
After:
vpn
service-type : 'org.freedesktop.NetworkManager.VPN.Novpn'
data : {'gateway': 'novpn.example.com', 'username': 'hello'}
secrets : {'password': 'world'}
Note that no effort was spent on printing the defaults. There are
multiple ways that could be achieved, but I'm not sure it would be all
that necessary given this is really just a quick'n'dirty debugging facilty.
AC_CHECK_FILE() does not work for cross compilation. Autoconf
documentation says:
Be aware that, like most Autoconf macros, they test a feature of the
host machine, and therefore, they die when cross-compiling. [1]
Test for the existance of the file directly. Of course, when cross
compiling, it's not at all clear that the host machine will run the same
distribution. And thus detecting --enable-ifcfg-rh based on the build
machine is likely wrong. Note, that we already did
AS_IF([test -z "$hostname_persist" -a -f /etc/SuSE-release], hostname_persist=suse)
which has the same problem.
At least, build no longer fails, and the user can inspect the ./configure
summary and see which features were misdetected.
[1] https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Files.html
The virtual function NMMetaType.get_nested() has only one caller:
nm_meta_abstract_info_get_nested(). That caller makes sure to
always pass in an @out_to_free argument, and that it is initialized
to NULL.
The local variable was just a copy of the (unchanging)
configuration nmc_config->multiline_output.
It is complicated enough to understand how nmc_config->print_output
and nmc_config->multiline_output affects nmc_print(). Don't use an
alias when referencing to nmc_config->multiline_output because it
hides where the value is used and where it causes a difference.
PrintDataCol contains a reference to the parent structure, for which
it was created. Previously, that was expressed via the "parent_idx"
field, which is an index into the list of all PrintDataCol entries.
That is inconvenient. Resolve the index to the actual pointer.
Note that during _output_selection_append() we still need to use
the index instead of resolving the pointer right away. That is because
_output_selection_append() grows the GArray into which the parent_idx
pointers to. So, obtaining the real pointer at that point would result
in using a dangling pointer later on.
Introduce a new step _output_selection_complete() which converts the
index into the actual pointer.
The print-output knows three modes: NORMAL, PRETTY, TERSE.
Never compare whether a mode is != a particular mode.
Instead, always explicitly check for the modes for which we enable a
particular behavior.
The effect is, that we always do something when the mode is set to a
particular value. We don't ever do something, if the mode is not set to
a particular value. Consistently opt-in is easier to understand.
The print-output knows three modes: NORMAL, PRETTY, TERSE.
Instead of using local variables "pretty" and "terse",
check for the output mode directly.
Note how we have tree modes, so mapping them to two boolean
variables is confusing. Especially at one place where we did:
pretty = (nmc_config->print_output != NMC_PRINT_TERSE);
while at other places:
pretty = (nmc_config->print_output == NMC_PRINT_PRETTY);
The header-cell is the header for a column with possibly many
rows.
We must not set:
header_cell->skip = nmc_config->overview && is_default;
for a particular cell, because it does not take into accound
the neighbouring rows. It is only correct, if there is only
one row.
Invert the logical meaning and rename "strip" to "to_print".
Each cell then can opt-in, whether it needs to be printed.
Only if no cell opts-in, it will be skipped.
Fixes: 9a19bbcb2f
Instead of re-fetching the UUID each time with a D-Bus call,
cache/memoize it.
On my system, this improves
$ make check-local-clients-tests-test-client
from 20.9 to 20.4 seconds (- 2.6%). That is not stellar, but noticible
enough to warrant this simple change.
These nmcli calls are inside a Util.iter_nmcli_output_modes()
loop, hence, --terse will passed to them already.
Specifying --terse more than once, causes nmcli to fail.
We didn't actually want to test how nmcli rejects such
duplicate arguments. Adjust the test.
Add more tests for various output modes of nmcli.
This most interestingly includes a terse output for
$ nmcli device status
Which was not tested previously (but a later commit will change
behavior here).
This blows up the number of tests even further.
Previously, the test invoked nmcli 850 times (taking ~15 seconds
ony my machine), afterwards, it is 1334 times (taking ~20 seconds).
No doubt, this seems excessive and questionable.
However, I maintain that the computer doesn't mind running a lot of
redundant tests. The important thing is, that we cover as many cases
as possible. Trying at the same time to minimize the number of tests
by avoiding duplicates and redundant tests, is just a lot of manual
labor. Manual labor that must be repeated whenever new tests are added, to
ensure that this test case is not yet covered. So, I am fine
with the large number of tests. Let the computer do the work.
Instead of letting each nmcli run write an individual .expected file,
combine the output of multiple runs in one file (per test).
Advantages:
- since there is a very large number of tests, having a file for each
tests is cumbersome. For example, since they are all added to
$(EXTRA_DIST) (and since we use non-recursive make), autoconf can
easily hit a length limit when processing all the file names.
- previously, whenever we added tests, all .expected files shifted
and the diff was large. Now, there is a chance that the diff is
smaller and more accurate.
It seems, curl_multi_socket_action() can fail with
connectivity check failed: 4
where "4" means CURLM_INTERNAL_ERROR.
When that happens, it also seems that the file descriptor may still have data
to read, so the glib IO callback _con_curl_socketevent_cb() will be called in
an endless loop. Thereby, keeping the CPU busy with doing nothing (useful).
Workaround by disabling polling on the file descriptor when something
goes wrong.
Note that optimally we would cancel the affected connectivity-check
right away. However, due to the design of libcurl's API, from within
_con_curl_socketevent_cb() we don't know which connectivity-checks
are affected by a failure on this file descriptor. So, all we can do
is avoid polling on the (possibly) broken file descriptor. Note that
we anyway always schedule a timeout of last resort for each check. Even
if something goes very wrong, we will fail the check within 15 seconds.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
On non-Windows, libcurl's "curl_socket_t" type is just a typedef for
int. We rely on that, because we use it as file descriptor.
Add a compile time check to ensure that.
Since this is "C" there are not namespaces and libraries commonly choose
a particular name prefix for their symbols.
In case of libcurl, that is "curl_".
We should avoid using the same name prefix, and choose something distinct.
Before:
$ nmcli connection up my-wired
Error: Connection activation failed: No suitable device found for this connection.
After:
$ nmcli connection up my-wired
Error: Connection activation failed: No suitable device found for this connection (device eth0 not available because device has no carrier).
This relies on nm_manager_get_best_device_for_connection() giving a
suitable error. That is however a bit complicated, because if no
suitable device is found, it's not immediately clear what is the
exact reason. E.g. if you try to activate a Wi-Fi profile, the
failure reason
"SSID is not visible"
is better than
"Wi-Fi profile cannot activate on ethernet device".
This is controlled by carefully setting the failure codes
NM_UTILS_ERROR_CONNECTION_AVAILABLE_* to indicate an absolute
relevance of the failure. And subsequently, by selecting the failure
with the highest relevance. This might still need some improvements,
for example by reordering checks (so that more relevant failures
are handled first) and tweaking the error relevance.
Before:
$ nmcli connection up my-wired ifname eth0
Error: Connection activation failed: Connection 'my-wired' is not available on the device eth0 at this time.
After:
$ nmcli connection up my-wired ifname eth0
Error: Connection activation failed: Connection 'my-wired' is not available on device eth0 because device has no carrier
Still unused, but will be used to give a better failure reason when
no device is found.
The difficulty here is to select the failure message from the most appropriate
device. This might still need some tweaking by setting the error codes accordingly
and re-ordering checks so that failure cares that are more accurate are handled
first.
Note the special error codes NM_UTILS_ERROR_CONNECTION_AVAILABLE_*.
This will be used to determine, whether the profile is fundamentally
incompatible with the device, or whether just some other properties
mismatch. That information will be importand during a plain `nmcli
connection up`, where NetworkManager searches all devices for a device
to activate. If no device is found (and multiple errors happened),
we want to show the error that is most likely relevant for the user.
Also note, how NMDevice's check_connection_compatible() uses the new
class field "device_class->connection_type_check_compatible" to simplify
checks for compatible profiles.
The error reason is still unused.
It seems to me the NM_DEVICE_CLASS_DECLARE_TYPES() macro confuses more
than helping. Let's explicitly initialize the two fields, albeit with
another helper macro NM_DEVICE_DEFINE_LINK_TYPES() to get the list of
link-types right.
For consistency, also leave nop-lines like
device_class->connection_type_supported = NULL;
device_class->link_types = NM_DEVICE_DEFINE_LINK_TYPES ();
because all NMDevice class init methods should have this same
boiler plate code and to make it explicit that this is intended.
And there are only 3 occurences where this actually comes into play.
NMDeviceOvsPort and NMDeviceOvsInterface don't have an underlying link-type from platform.
Still use NM_DEVICE_CLASS_DECLARE_TYPES() macro, for consistancy reasons.
This requires to extend NM_DEVICE_CLASS_DECLARE_TYPES() macro, to support
a variadic argument list with zero link-types.
