private_server_free() had only one caller: nm_bus_manager_private_server_register().
The only thing that nm_bus_manager_private_server_register() did in
addition was to check for duplicate server tags.
Merge the two functions.
Our convention is that when the body of an if() or for() spawns
more then one line, then it needs curly braces. If it's only one
line, it should have no curly braces. The latter part seems sometimes
a bit inconvenient, because changing
if (some_condition)
do_something ();
gets change to
if (some_condition) {
do_something ();
do_something_else ();
}
the diff shows 3 lines changed, although really only one changed.
But well, that's how it is...
Verify that an 8021x network is preprovisioned on IWD side before
declaring a connection as "available" or "compatible".
Also move the Infrastrucure mode check and the Hidden SSID check in
check_connection_available earlier because even if a compatible AP is
available and the connection can be used with wpa_supplicant, it can't
be used with IWD at this time.
This is mainly to enable using 8021x networks, which have to be
preprovisioned as an IWD config file to be supported and can not be
configured by asking the user for secrets over DBus, this is an IWD's
design choice.
Note that this assumes that secrets are only used during the Stage 2 of
the activation, i.e. for the wifi handshake, not in the later stages.
Keep a list of IWD's Known Networks which are networks that have their
configurations stored by IWD including the secrets, either because they
have been connected to before or because they were preprovisioned on the
machine.
Even Gentoo disables this plugin since before 0.9.8 release
of NetworkManager. Time to say goodbye.
If somebody happens to show up to maintain it, we may resurrect it
later.
If "$distro_plugins=ifnet" was set, configure.ac would use that
to autodetect --with-hostname-persist=gentoo. Replace that autodetect
part by checking for /etc/gentoo-release file.
Add a new device state reason code for unsupported IP method. It is
returned, for example, when users select manual IP configuration for
WWAN connections:
# nmcli connection mod Gsm ipv4.method manual ipv4.address 1.2.3.4/32
# nmcli connection up Gsm
Error: Connection activation failed: The selected IP method is not
supported
compared to the old:
Error: Connection activation failed: IP configuration could not be
reserved (no available address, timeout, etc.)
Note that we could instead fail the connection validation if the
method is not supported by the connection type, but adding such
limitation now could make existing connections invalid.
https://bugzilla.redhat.com/show_bug.cgi?id=1459529
Don't call nm_utils_parse_inaddr_bin() if the string returned by
mm_bearer_ip_config_get_address() and mm_bearer_ip_config_get_gateway()
is NULL, as the function requires a valid pointer. Throw an error if the
address is NULL, but allow an empty gateway.
Fixes: 7837afe87f
When a new settings-connection is populated with the actual settings
read from disk by the plugin, calling nm_settings_connection_update()
with KEEP mode also marks it as unsaved, which should not happen on a
new connection just written to (or read from) disk.
Introduce a new KEEP_SAVED persist mode that is similar to KEEP but
clears the UNSAVED flag.
Fixes: 023ce50d21https://bugzilla.redhat.com/show_bug.cgi?id=1525078
NMManager tries to assign unique route-metrics in an increasing manner
so that the device which activates first keeps to have the best routes.
This information is also persisted in the device's state file, however
we not only need to persist the effective route-metric which was
eventually chosen by NMManager, but also the aspired metric.
The reason is that when a metric is chosen for a device, the entire
range between aspired and effective route-metric is reserved for that
device. We must remember the entire range so that after restart the
entire range is still considered to be in use.
Fixes: 6a32c64d8f
If a volatile connection is deleted by user when it was already being
deleted internally because the device vanished, we may hit the
following failed assertion:
file src/settings/nm-settings-connection.c: line 2196
(nm_settings_connection_signal_remove): should not be reached
The @removed flag keeps track of whether we already signaled the
connection removal. Instead of throwing an assertion if we try to emit
the signal again, just return without action because this can happen
in the situation described above.
While at it, remove the @allow_reuse argument from
nm_settings_connection_signal_remove(): we should never emit the
signal twice. Instead, we should reset the @removed flag when the
connection is added.
Fixes: a9384452edhttps://bugzilla.redhat.com/show_bug.cgi?id=1506552
First check that the limit of 50 metric points is not surpassed.
Otherwise, if you have an ethernet device (aspired 100, effective
130) and a MACSec devic (aspired 125, effective 155), activating a
new ethernet device would bump it's metric to 155 -- more then
the 50 points limit.
It doesn't matter too much, because the cases where the limit of
50 could have been surpassed were very specific. Still, change
it to ensure that the limit is always honored as one would expect.
Fixes: 6a32c64d8f
Since meson 0.44 there is a new option type called `array`, which
allows to use an array with different values in those options.
These fits the needs of different options that are used to pass
binary paths, which have multiple paths as an alternate locations.
meson's version has been bumped to 0.44 and different options have
been changed to `array` type options.
https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00062.html
The compiler warns when we ignore the return value from write().
And assigning it to an unused variable, causes another warning.
Make some use of it, at least to handle EINTR. All other errors
are still ignored.
While at it, rework the write code to first write to a buffer
in memory.
src/dns/nm-dns-manager.c: In function ‘write_to_netconfig’:
src/dns/nm-dns-manager.c:387:8: error: ignoring return value of ‘write’, declared with attribute warn_unused_result [-Werror=unused-result]
write (fd, str, strlen (str));
^
src/settings/plugins/ifnet/nms-ifnet-connection-parser.c: In function ‘ifnet_update_parsers_by_connection’:
src/settings/plugins/ifnet/nms-ifnet-connection-parser.c:2600:26: error: variable ‘pppoe’ set but not used [-Werror=unused-but-set-variable]
gboolean wired = FALSE, pppoe = TRUE;
^~~~~
While at it, don't log line breaks in ifnet_update_parsers_by_connection().
Fixes: e912b36d95
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
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).
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 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.
This is very similar to NMDeviceWifi but simplified to remove the things
currently unsupported and with calls to nm_platform_wifi_* and
nm_supplicant_* replaced with IWD DBus API calls. Only unsecured
infrastructure-mode networks are supported here.
[bgalvani@redhat.com: fix compilation error after rebase for
NMActRequestGetSecretsCallId]
[thaller@redhat.com: don't use _() macro strings server side.
Translating strings only makes sense for clients that set environment
variables accordingly.]
