A bug exists where the conflict counter is cleared
regardless of whether or not the next probe attempt leads to
a successful address acquisition. This causes 'bursts' of
MAX_CONFLICTS probes followed by a delay of
RATE_LIMIT_INTERVAL instead of a single probe each
RATE_LIMIT_INTERVAL when beyond MAX_CONFLICTS.
The conflict counter should only be cleared after an
address is successfully acquired. This commit achieves that
goal.
From RFC3927:
A host should maintain a counter of the number of address
conflicts it has experienced in the process of trying to
acquire an address, and if the number of conflicts exceeds
MAX_CONFLICTS then the host MUST limit the rate at which it
probes for new addresses to no more than one new address per
RATE_LIMIT_INTERVAL. This is to prevent catastrophic ARP
storms in pathological failure cases, such as a rogue host
that answers all ARP probes, causing legitimate hosts to go
into an infinite loop attempting to select a usable address.
Signed-off-by: Jason Reeder <jasonreeder@gmail.com>
(cherry picked from commit 0cbc024d591e1b1095d90494e0337dabd9ef2e19)
See also "5df024f57a wwan: don't assume DNS info is always available"
which does the same for IPv4.
(cherry picked from commit cec7ade86c)
(cherry picked from commit 00f14736e6)
(cherry picked from commit 7c09527d5e)
(cherry picked from commit e3e86af74e)
(cherry picked from commit 0e812da25e)
gboolean is a typedef for "int".
While older compilers might treat such bitfields as unsigned ([1]),
commonly such a bitfield is signed and can only contain the values 0
and -1.
We only want to use numeric 1 for TRUE, hence, creating such bitfields
is wrong, or at least error prone.
In fact, in this case it's a bug, because later we compare
it with a regular gboolean
if (priv->scanning != new_scanning)
[1] https://lgtm.com/rules/1506024027114/
Fixes: e0f9677018
(cherry picked from commit 610ca87016)
(cherry picked from commit f326feaba3)
(cherry picked from commit 7689b9b73b)
(cherry picked from commit 9f41fae864)
The @connection argument can be NULL; add the (allow-none) annotation
otherwise calling the API with a NULL argument through GObject
introspection fails with:
Argument 1 does not allow None as a value
Fixes: 278fd4fb0f
(cherry picked from commit f396826466)
(cherry picked from commit a03b867ba4)
(cherry picked from commit cd6c17cb21)
(cherry picked from commit 8d4fce4daf)
If an operation is cancelled through the GCancellable, then the idiom is
that the operation is always cancelled, even if it has finished
successfully. To ensure this is the case, add calls to
g_simple_async_result_set_check_cancellable everywhere.
Without this, e.g. gnome-control-center will crash when switching away
from the power panel quickly, as the NMClient creation finishes
asynchronously and g-c-c assume that G_IO_ERROR_CANCELLED is returned to
ensure it doesn't access the now invalid user_data parameter.
https://bugzilla.gnome.org/show_bug.cgi?id=794088
(cherry picked from commit 26c215e22d)
(cherry picked from commit e1b99d9201)
(cherry picked from commit 2e62853509)
Discovered thanks to `-Wunused-value` when building on openSUSE Leap 42.3.
(cherry picked from commit c4f655579c)
(cherry picked from commit a30b2fcd84)
(cherry picked from commit b2b28cb644)
The asynchronous secret agent initialization doesn't work at all due to a
rather silly typo. Oops.
While at it, fix a whitespace error too.
(cherry picked from commit 603daa5b25)
I hit an assertion failure running with valgrind on a busy machine.
Maybe the timeout is just not long enough for every case.
Increase it.
(cherry picked from commit 88c24ffc6a)
(cherry picked from commit 54706e6557)
# random seed: R02S4ca8cfc3dace399c0f15b42411e45d2e
1..48
# Start of link tests
ok 1 /link/bogus
PASS: src/platform/tests/test-link-linux 1 /link/bogus
ok 2 /link/loopback
PASS: src/platform/tests/test-link-linux 2 /link/loopback
nmtst: initialize nmtst_get_rand() with NMTST_SEED_RAND=2697682474
ok 3 /link/internal
PASS: src/platform/tests/test-link-linux 3 /link/internal
ok 4 /link/external
PASS: src/platform/tests/test-link-linux 4 /link/external
# Start of software tests
./tools/run-nm-test.sh: line 193: 7589 Trace/breakpoint trap (core dumped) "${NMTST_DBUS_RUN_SESSION[@]}" "$TEST" "$@"
NMPlatformSignalAssert: src/platform/tests/test-link.c:298, test_slave(): failure to accept signal 0 times: 'link-changed-changed' ifindex 9 (1 times received)
ERROR: src/platform/tests/test-link-linux - too few tests run (expected 48, got 4)
ERROR: src/platform/tests/test-link-linux - exited with status 133 (terminated by signal 5?)
(cherry picked from commit 1ee6dea02f)
(cherry picked from commit 903ed7bc59)
The function should not close the input file descriptor; however
fdopen() associates the fd to the new stream so that when the stream
is closed, the fd is too. The result is a double close() and the
second call can in certain cases affect a wrong fd.
Use a duplicate fd for the stream.
Fixes: 1d9bdad1dfhttps://bugzilla.redhat.com/show_bug.cgi?id=1451236
(cherry picked from commit 597072296a)
(cherry picked from commit 01b10fe24d)
The bus manager takes extra references to the GDBusConnection every
time g_dbus_object_manager_server_get_connection() its called,
preventing its disposal once the connection is closed. This causes a
leak for each DHCP event.
https://bugzilla.redhat.com/show_bug.cgi?id=1461643
(cherry picked from commit 5b81d40338)
(cherry picked from commit bb4b6be912)
When the operation is cancelled, we must not touch user_data. Note that
NM_POLICY_GET_PRIVATE() theoretically doesn't dereference the pointer
(does it?) but doing pointer arithmetic on a dangling pointer is a very
ugly thing to do.
And of course, the memleak.
Fixes: 5c716c8af8
Fixes: a2cdf63204
(cherry picked from commit 3215508293)
(cherry picked from commit f1469558c0)
NMDeviceGeneric:check_connection_compatible() doesn't check for a
matching interface name. It relies on the parent implementation to
do that.
The parent implementation calls nm_manager_get_connection_iface().
That fails for NM_SETTING_GENERIC_SETTING_NAME, because that one has
no factory. Maybe this imbalance of having no factory for the Generic device
is wrong, but usually factories only match a distinct set of device
types, while the generic factory would handle them all (as last resort).
Without this, activating a generic connection might activate the
wrong interface.
(cherry picked from commit 3876b10a47)
(cherry picked from commit 753a2cc4d9)
Also accept DEFROUTE and GATEWAY when they are defined in
alias files -- provided, that they are not yet defined
in the main ifcfg file.
(cherry picked from commit 3cc00dd550)
When the main ifcfg file contains no IP addresses, the method
will be "disabled". Later, when reading IP addresses for the
aliases, we must ensure that the method is manual.
Otherwise, validation fails with
ip.addresses: this property is not allowed for method=disabled
(cherry picked from commit a8f0d88596)
src/nm-auth-utils.c:343:6: error: 'is_authorized' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (is_authorized) {
^
src/nm-auth-utils.c:320:11: note: 'is_authorized' was declared here
gboolean is_authorized, is_challenge;
^
src/nm-auth-utils.c:346:13: error: 'is_challenge' may be used uninitialized in this function [-Werror=maybe-uninitialized]
} else if (is_challenge) {
^
src/nm-auth-utils.c:320:26: note: 'is_challenge' was declared here
gboolean is_authorized, is_challenge;
^
(cherry picked from commit 24ab2a4945)
src/nm-default-route-manager.c: In function '_ipx_update_default_route':
src/nm-default-route-manager.c:769:23: error: 'is_assumed' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (!default_route && !is_assumed) {
^
src/nm-default-route-manager.c:763:13: note: 'is_assumed' was declared here
gboolean is_assumed;
^
(cherry picked from commit 857f26dd19)
The default route manager logs for each entry relevant information,
in a compact but cryptic way:
default-route: entry[0/dev:0x5633d5528560:enp0s25:1:+sync]: record:add 0.0.0.0/0 via 192.168.0.1 dev 2 metric 100 mss 0 rt-src user (100)
The flag whether a route is configured or not, was only expressed
via 0|1. Change that to log instead:
default-route: entry[0/dev:0x5633d5528560:enp0s25:+has:+sync]: record:add 0.0.0.0/0 via 192.168.0.1 dev 2 metric 100 mss 0 rt-src user (100)
(cherry picked from commit 82bfb6c46d)
Whenever we call update for a non-assumed, synced route, we must
force a resync with the platform. Even if according to our internal
book-keeping the route is already configured, the route may have
been removed externally. So we cannot assume that everything is
still up-to-date.
https://bugzilla.redhat.com/show_bug.cgi?id=1431268
(cherry picked from commit c3c251ea12)
Avoid using new_settings when they are none. Also, don't shortcut when
the connection hasn't been changed -- let the settings plugin decide if
it needs to rewrite the connection.
(cherry picked from commit b47340fd3f)
GLib 2.52 added a G_GNUC_PRINTF attribute to
g_dbus_message_new_method_error(). This triggered warning in
NetworkManager when built with -Wformat, which is an error when built
with -Werror=format-security. It seems that gcc isn't smart enough to
see that (foo = "bar") should be treated as a literal.
Fortunately there is a g_dbus_message_new_method_error_literal()
function which does not take printf-style arguments, and we don't need
them, so we can use that.
This patch was originally by Rico Tzschichholz <ricotz@ubuntu.com>, and
was submitted to Launchpad at
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1650972https://bugzilla.gnome.org/show_bug.cgi?id=780444
(cherry picked from commit 6a77258f4e)
