The nm_device_check_connection_available() call seem to have been accidentally
removed from nm_device_recheck_available_connections() resulting in all
connections always being added.
Fixes 02ec76df5a
This should avoid a race when stopping dnsmasq.
This is still a hack, because we don't want to ever wait
for a process to terminate.
A better solution would be to have nm-dnsmasq-manager managing
the global state. Not only the dnsmasq instance of on NMDevice.
Instead it should keep track of all the child processes it starts
and it wants to start. This way, starting a new process should be
delayed until any (child or non-child) instances are gone.
That however would be a bigger change.
https://bugzilla.gnome.org/show_bug.cgi?id=728342https://bugzilla.gnome.org/show_bug.cgi?id=762008
Often a netlink event doesn't contain enough information to determine
the link type. Then we consult sysctl or ethtool. However, if we already
have the same object cached, we want to reused the (once detected) link-type.
There was a bug in lookup of the cached object.
It is ugly that nmtst_assert_connection_verifies_after_normalization() would
normalize the argument and modify it. An assertion should not have side-effects.
- "gsystem-local-alloc.h" and <gio/gio.h> are already included via
"nm-default.h". No need to include them separately.
- include "nm-macros-internal.h" via "nm-default.h" and drop all
explict includes.
- in the modified files, ensure that we always include "config.h"
and "nm-default.h" first. As second, include the header file
for the current source file (if applicable). Then follow external
includes and finally internal nm includes.
- include nm headers inside source code files with quotes
- internal header files don't need to include default headers.
They can savely assume that "nm-default.h" is already included
and with it glib, nm-glib.h, nm-macros-internal.h, etc.
Due to a kernel bug [1], we sometimes receive spurious NEWLINK
messages after a wifi interface has disappeared. Since the link is not
present anymore we can't determine its type and thus it will show up
as a Ethernet one, with no address specified. Request the link again
to check if it really exists.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1302037https://bugzilla.gnome.org/show_bug.cgi?id=761151
The dnsmasq process started as DHCP and DNS server for shared
connections now accepts additional configuration files at
/etc/NetworkManager/dnsmasq-shared.d/.
https://bugzilla.gnome.org/show_bug.cgi?id=761717
It's declared as never returning, making do a better at understanding control
flow. Otherwise it makes a poor guess:
In file included from test-crypto.c:37:
../../shared/nm-test-utils.h:1344:3: error: variable 'family' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
g_assert (FALSE);
^~~~~~~~~~~~~~~~
When NM tries to match a generated connection to a persistent one, it
considers also the metric of static routes. However, if the field is
set to -1 (use default value for the device) on the persistent
connection, the comparison will always fail because the generated
connection contains the actual value read from kernel.
To fix the issue, modify check_possible_match() to deal correctly with
-1 and translate it to the expected value for the current device when
performing the comparison.
This allows connections with static routes and default metric to
properly be re-assumed when NM is restarted.
https://bugzilla.redhat.com/show_bug.cgi?id=1302532
The existing checks assumed that all AP/AdHoc connections would use the
shared IP method. But what we really want to check for here is whether the
connection is AP/AdHoc. Leave the existing 'shared' check for backwards
compatibility.
Also move the check above the timestamp check, since the user shouldn't need
to manually set a timestamp just to get an AP-mode connection to autoconnect.
connections.c: In function ‘sort_connections’:
connections.c:1536:3: error: ‘return’ with no value, in function returning non-void [-Werror=return-type]
return;
^
Fixes: e8927c14ec
The request->scripts are allocated in handle_action() and request_free() is
only called after that, so it never sees it NULL. Coverity knows:
CID 59385 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking request->scripts suggests that it may be null,
but it has already been dereferenced on all paths leading to the check.
Coverity complains:
CID 59386 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking cons suggests that it may be null, but it has
already been dereferenced on all paths leading to the check.
The device never returns NULL access point list, it only deallocates it on
dispose(). Make this clear for Coverity:
CID 59387 (#1 of 1): Dereference before null check (REVERSE_INULL)
check_after_deref: Null-checking aps suggests that it may be null, but it has
already been dereferenced on all paths leading to the check.
