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.
NetworkManager does not allow default routes to be specified
as normal routes. They must be ignored. Especially, iproute2
which reads the ifcfg files in initscripts, does not allow
to specify a prefix length "default/x" except for "default/0".
https://bugzilla.gnome.org/show_bug.cgi?id=761631
When exporting an object, we first set the object path and then create
GDBus interface skeletons. While doing this, a signal can be generated
[1] and then nm_exported_object_signal_hook() can trigger the failed
assertion "interface != NULL" because the object is already exported
(priv->path != NULL) but the interface has not been registered yet.
To fix this, set the object path only after skeletons have been
created.
[1] This happens here every time I disable networking and restart NM:
#0 _g_log_abort (libglib-2.0.so.0)
#1 g_log (libglib-2.0.so.0)
#2 nm_exported_object_signal_hook (NetworkManager)
#3 signal_emit_unlocked_R (libgobject-2.0.so.0)
#4 g_signal_emit_valist (libgobject-2.0.so.0)
#5 g_signal_emit (libgobject-2.0.so.0)
#6 set_state (NetworkManager)
#7 nm_manager_update_state (NetworkManager)
#8 get_property (NetworkManager)
#9 object_get_property (libgobject-2.0.so.0)
#10 on_source_notify (libgobject-2.0.so.0)
#11 g_object_bind_property_full (libgobject-2.0.so.0)
#12 g_object_bind_property (libgobject-2.0.so.0)
#13 nm_exported_object_skeleton_create (NetworkManager)
#14 nm_exported_object_create_skeletons (NetworkManager)
#15 nm_exported_object_export (NetworkManager)
#16 nm_manager_setup (NetworkManager)
#17 main (NetworkManager)
#18 __libc_start_main (libc.so.6)
#19 _start (NetworkManager)
https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00041.html
They are actually u32 in the kernel. Plus if we use G_MAXINT32 it
causes gtkdoc to write out "Allowed values: <= G_MAXLONG" on i386
and "Allowed values: <= G_MAXINT" on x86_64, breaking multilib.
Fixes: 95dfd99afc
We detect support for IPv6 temporary addresses (IFA_F_MANAGETEMPADDR) or /64 v6 prefixes
(IFA_F_NOPREFIXROUTE) based on the presence of extended address flags. For the most part
this just works, but it fails down if upon initialization no addresses are present.
In such a case we would have assumed no support. Change that to default to available
support as the feature is already 2 years in upstream kernel.
Since commit 9ff161b2a1 ("device: move have_ip6_address() to
nm_ip6_config_get_address_first_nontentative()") the IP configuration
argument of nm_ip6_config_get_address_first_nontentative() must be
non-NULL. Add checks where needed.
Fixes: 9ff161b2a1
Fail only printed a message to stderr and exited.
Instead, print it with g_error(), which also breaks
in the debugger and produces a core-dump.
Also, it constructed the message based on an unchecked
format string and constructed a format string dynamically.
Just don't do that.
Also add a comment that these macros are discouraged because
they are cumbersome to write (requiring a test-name and a failure
message).
Also add a new conditional "debug" to enable more assertions and
more logging, which is disabled by default.
Also add a conditional "test" to disable running the unit tests
(make check) while building the package.
http://rpm.org/wiki/PackagerDocs/ConditionalBuilds
We should not check ip6_config for the link local address because
ip6_config contains the merged settings we want to configure,
not the addresses that are actually configured on the device.
Check ext_ip6_config_captured for that.
Also, reuse nm_ip6_config_get_address_first_nontentative() which
only takes an address after it survived DAD.
