Odd, we iterate over a thousand names, without aborting when
the first key isn't present.
On the other hand, it means we cannot parse more then 1000
routes either :(
Anyway, don't heap allocate the temporay string for the key
name.
The order in which the attribute names are returns should
be defined and stable. Sort them and re-use the helper functions.
Sorting is good, because it gives a consistent order. Maybe we don't
want to commit to this in the API, officially the order is still
arbitrary. In practice, we rely on the order of attribute names
when converting the attributes to a string. The same configuration
should produce the same string representation.
That doesn't mean we commit to a fixed order in the string
representation. It does not mean, that the order must always be this
way, we can still change it. But between multiple runs of the same
binary, the order should be stable.
Note that our hash tables are seeded with a random number. Hence,
their order is not only abitrary, it is also unstable and changes
for each run of the application.
At several places we create strv arrays where the
strings themself are not deep-copied.
This helper function iterates over such an "const char **"
array, clones the strings, and updates the strv array
inplace to be a "char **" strv array.
This helper function is to reduce code duplication.
At various places we get the (string) keys of a GHashTable.
Add a helper function that does that, including an argument
for optional sorting.
The helper function is there to get reduce code duplication.
Source files for enum types are generated by passing segments of the
source code of the files to the `glib-mkenums` command.
This patch removes those parameters where source code is used from
meson build files by moving those segmeents to template files.
https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00057.html
There are three headers `nm-secret-agent-old.h`,
`nm-vpn-plugin-old.h`, and `nm-vpn-service-plugin.h`, which are
named as no introspection headers. However, these files also
join to the rest headers to generate introspection data.
This patch merges those no introspection headers with the public
headers.
`generate-plugin-docs.pl` script which is used to parse
`nm-setting-c*.c` files depends on autotools. This is because it
parses the `Makefile.am` in order to figure out the setting files
it needs to parse.
This patch makes the script independent of autotools by passing
the necessary setting files by command line instead of parsing the
`Makefile.am` file. It also changes the autotools' and meson's
accordingly.
We don't use them, so add a compiler warning about their use.
I think they are annoying, because sizeof(x) and typeof(x) might
evaluate at runtime. Especially the typeof() extension is useful
for macros, but behaves badly with variable-length arrays due to
running code at runtime.
But the worst is, G_STATIC_ASSERT() is implemented by declaring
an array of negative length. Usually, the checked condition should
be a compile time constant, but with VLAs the compiler would not evaluate
the static-assert at compile time and instead accept it silently. It's easy
to mess up static asserts to wrongly have a non-constant condition,
especially when the static-assert is used inside a macro.
Just say no.
NM_FLAGS_HAS() uses a static-assert that the second argument is a
single flag (power of two). With a single flag, NM_FLAGS_HAS(),
NM_FLAGS_ANY() and NM_FLAGS_ALL() are all identical.
The second argument must be a compile time constant, and if that is
not the case, one must not use NM_FLAGS_HAS().
Use NM_FLAGS_ANY() in these cases.
In the past we had NMDefaultRouteManager which would coordinate adding
the default-route with identical metrics. That especially happened, when
activating two devices of the same type, without explicitly specifying
ipv4.route-metric. For example, with ethernet devices, the routes on
both interfaces would get a metric of 100.
Coordinating routes was especially necessary, because we added
routes with NLM_F_EXCL flag, akin to `ip route replace`. We not
only had to avoid that activating two devices in NetworkManager would
result in a fight over the default-route, but more importently
to preserve externally added default-routes on unmanaged interfaces.
NMDefaultRouteManager would ensure that in case of duplicate
metrics, that the device that activated first would keep the
best default-route. It would do so by bumping the metric
of the second device to find a unused metric. The bumping itself
was not very important -- MDefaultRouteManager could also just not
configure any default-routes that show up as second, the result
would be quite similar. More important was to keep the best
default-route on the first activating device until the device
deactivates or a device activates that really has a better
default-route..
Likewise, NMRouteManager would globally manage non-default-routes.
It would not do any bumping of metrics, but it would also ensure that the routes
of the device that activates first are not overwritten by a device activating
later.
However, the `ip route replace` approach has downsides, especially
that it messes with routes on other interfaces, interfaces that are
possibly not managed by NetworkManager. Another downside is, that
binding a socket to an interface might not result in correct
routes, because the route might just not be there (in case of
NMRouteManager, which wouldn't configure duplicate routes by bumping
their metric).
Since commit 77ec302714 we would no longer
use NLM_F_EXCL, but add routes akin to `ip route append`. When
activating for example two ethernet devices with no explict route
metric configuration, there are two routes like
default via 10.16.122.254 dev eth0 proto dhcp metric 100
default via 192.168.100.1 dev eth1 proto dhcp metric 100
This does not only affect default routes. In case of a multi-homing
setup you'd get
192.168.100.0/24 dev eth0 proto kernel scope link src 192.168.100.1 metric 100
192.168.100.0/24 dev eth1 proto kernel scope link src 192.168.100.1 metric 100
but it's visible the most for default-routes.
Note that we would append the routes that are activated later, as the order
of `ip route show` confirms. One might hence expect, that kernel selects
a route based on the order in the routing tables. However, that isn't
the case, and activating the second interface will non-deterministically
re-route traffic via the new interface. That will interfere badly with
with NAT, stateful firewalls, and existing connections (like TCP).
The solution is to have NMManager keep a global index of the default route-metrics
currently in use. So, instead of determining the default-route metric based solely
on the device-type, we now in addition generate default metrics that do not
overlap. For example, if you activate eth0 first, it gets route-metric 100,
and if you then activate eth1, it gets 101. Note that if you deactivate
and re-activate eth0, then it will get route-metric 102, because the
best route should stick on eth1 (which reserves the range 100 to 101).
Note that when a connection explititly selects a particular metric, then that
choice is honored (contrary to NMDefaultRouteManager which was more concerned
with avoiding conflicts, then keeping the exact metric).
https://bugzilla.redhat.com/show_bug.cgi?id=1505893
NMManager will need to know the state of all device at once.
Hence, load it once and cache it in NMConfig.
Note that this wastes a bit of memory in the order of
O(number-of-interfaces). But each device state entry is
rather small, and we always consume memory in the order
of O(number-of-interfaces).
binary-search can find an index of a matching entry in a sorted
list. However, if the list contains multiple entries that compare
equal, it can be interesting to find the first/last entry. For example,
if you want to append new items after the last.
Extend binary search to optionally continue the binary search
to determine the range that compares equal.
The @keep_link_local logic was wrong: when set to TRUE we must not
delete addresses and when set to FALSE we must delete addresses only
if they are unknown.
Also, ignore link-local addresses when comparing positions.
Fixes: 19d6d54b6f
meson spawns the tests in a way that the test process is
a session leader. Since the test wants to create a new
process group to kill a group of processes that it starts,
it failed.
$ meson test -C build test-general-with-expect
The test would have succeed when wrapping the test for example
by strace:
$ meson test -C build --wrap='strace' test-general-with-expect
Fix that, by forking once more.
There are some tests located in different directories which are
using the same name. To avoid any confussion a prefix was used to
name the test and the target.
This patch uses the prefix just for the target, to avoid any
collision that may happen, and uses the `test-` pattern as the
name.
https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00051.html
The `libnm_linking` test that belongs to the libnm-util's general
tests is failing because the test is not able to find the
`test-libnm-linking` binary, which is executed as a child process.
The problem lies to the `BUILD_DIR` macro definition which is
used to set the place to find the binary, and is wrongly defined
with the source directory.
This patch changes its value to the build directory that fixes
the problem.
https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00049.html
generate-settings-docs.py script is used to generate the
`nm-settings-docs.xml` and `nm-property-docs.xml` files. However,
to generate these files properly, the path where `libnm` shared
library is built must be passed to the script.
This patch uses the recently added `--lib-path` parameter to
pass the `libnm`'s built directory, which allows the proper
generation of the files in meson.
https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00045.html
generate-settings-docs.py script uses the `LD_LIBRARY_PATH` to
prepend directories to the library search path, which is useful to
load a just built libnm shared library, when generating the
`nm-settings-docs.xml` and `nm-property-docs.xml` files.
However, this is a problem for meson, which is not able to set
environment variables when executing the script.
This patch adds a new optional parameter, `-l` or `--lib-path` that
can be used to pass different paths to be prepended without using
the `LD_LIBRARY_PATH` environment, which can still be used.
[thaller@redhat.com: fix script to handle None lib_path argument]
https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00044.html
The commit was accidentally reverted during systemd code merge from
upstream.
devices/test: give more time to dad checking in test-arping
# random seed: R02Sc708af827453d4ace33cd27ffd3d7f0b
1..2
# Start of arping tests
**
NetworkManager:ERROR:src/devices/tests/test-arping.c:95:test_arping_common: assertion failed (nm_arping_manager_check_address (manager, info->addresses[i]) == info->expected_result[i]): (1 == 0)
ok 1 /arping/1
PASS: src/devices/tests/test-arping 1 /arping/1
./tools/run-nm-test.sh: line 193: 2836 Aborted "${NMTST_DBUS_RUN_SESSION[@]}" "$TEST" "$@"
# NetworkManager:ERROR:src/devices/tests/test-arping.c:95:test_arping_common: assertion failed (nm_arping_manager_check_address (manager, info->addresses[i]) == info->expected_result[i]): (1 == 0)
ERROR: src/devices/tests/test-arping - too few tests run (expected 2, got 1)
ERROR: src/devices/tests/test-arping - exited with status 134 (terminated by signal 6?)
Fixes: 8c0dfd7188
NM_CONFIG_GET_DATA_ORIG is the configuration that was loaded the first time.
NM_CONFIG_GET_DATA is the currently loaded one. Sometimes we want to always
stick to the original configuration, if we don't support reloading the
parameter (for example main.plugins, because it would be cumbersome to properly
implementing loading/unloading setting plugins.
In this case however, we can allow reloading the configuration just fine.
Of course, this only matters, if the device appears after the configuration
is reloaded, for example by reloading the driver.
Also, don't log any warnings, unless necessary.
Add the PSK agent support to support PSK networks. Note that the PSK
itself will be saved by IWD on the first successful connection to the
network and will not be updated when it is changed by the user on the NM
side, this still needs fixing like a bunch of other problems.
[bgalvani@redhat.com: fix checking return value of nm_utils_random_bytes()]
Let the config file select between creating classes of NMDeviceWifi
(for the usual wpa_supplicant based devices) and NMDeviceIwd depending
on the new NetworkManager.conf setting.
[bgalvani@redhat.com: fix leaking @backend in create_device()]
Add the NMIwdManager singleton to be responsible for matching
NMDeviceIwd objects created from platform devices, to IWD Device dbus
objects when they appear/disappear.
