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
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.
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
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
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.
The compiler might be able to optimize the switch better.
But more importantly, it has the type information of the enum
and can give warnings about unmentioned enum values.
Drivers are stupid, and just like the platform ignores an all zeros
permanent address, so should it ignore all ones.
NetworkManager[509]: <debug> [1453743778.854919] [devices/nm-device.c:8885] nm_device_update_hw_address(): [0x190370] (eth0): hardware address now 86:18:52:xx:xx:xx
NetworkManager[509]: <debug> [1453743778.855438] [devices/nm-device.c:9138] constructed(): [0x190370] (eth0): read initial MAC address 86:18:52:xx:xx:xx
NetworkManager[509]: <debug> [1453743778.861602] [devices/nm-device.c:9148] constructed(): [0x190370] (eth0): read permanent MAC address FF:FF:FF:FF:FF:FF
It will only be in ext_ip6_config if it was added by the kernel,
which isn't usually the case since NM handles IPv6LL address
generation on new enough kernels.
If the LL address isn't found, IPv6 configuration will never
complete because DHCPv6 was started already but lack of an LL
address bails out early without handling the error.
Fixes: b8c2fc26c1
The @read_wired_static array is passed on as test function. But defining
it in a local scope is strictly speaking not correct because the lifetime
of the array ends before the test run. Move it to the outer scope, which
exists during the test runs.
Since commit bb868770, setting a gateway of "0.0.0.0"
or "::" in NMSettingIPConfig means to set the gateway
to NULL. There is indeed no difference between an unset
gateway and an any gateway. This change was done to have
a consistent behavior in NMSettingIPConfig.
Fixes: bb86877031
Two of these raised Coverity's eyebrows.
CID 59389 (#1 of 1): Insecure temporary file (SECURE_TEMP)
5. secure_temp: Calling mkstemp without securely setting umask first.
CID 59388 (#1 of 1): Insecure temporary file (SECURE_TEMP)
1. secure_temp: Calling mkstemp without securely setting umask first.
Last one raised mine.
When a connection is edited and saved, there's a small window during which and
unprivileged authenticated local user can read out connection secrets (e.g. a
VPN or Wi-Fi password). The security impact is perhaps of low severity as
there's no way to force another user to save their connection.
Coverity is angry:
CID 59367 (#1-3 of 3): Division or modulo by float zero (DIVIDE_BY_ZERO)
30. divide_by_zero: In expression
((double)max_level - (double)level) /
((double)max_level - (double)noise),
division by expression (double)max_level - (double)noise which may be zero has
undefined behavior.
Can not fail no fake platform, but makes Coverity worried:
CID 59381 (#1 of 1): Dereference null return value (NULL_RETURNS)
6. dereference: Dereferencing a null pointer device.
CID 59382 (#1 of 1): Dereference null return value (NULL_RETURNS)
10. dereference: Dereferencing a pointer that might be null value
when calling strcmp.
Not exactly true, since we ruled out the posibility earlier; but
we could still get rid of a couple of strcmps.
Calling va_start() (with va_end()) in between seems to work and
is done by systemd and other code occasionally.
However, it's not clear that this really works on every architecture.
So just replace thise one instance with a different implementation
by passing the arguments as an array.
First, cb751012a2 mistakenly converted the
act_stage_context_step() in connect_ready() to connect_context_clear()
instead of connect_context_step(). This would cause the IP Type retry
logic to fail and no further types to be tried. It also throws
away the ctx->first_error and causes all errors that MM returns on the
connect attempt to be dropped on the floor.
Second, not all errors should cause an advance to the next IP Type,
since some errors aren't related to it. Specifically, MM_CORE_ERROR_RETRY
when using Simple.Connect() means that a timeout was reached
in the internal connect logic, not a modem or network error. In
that case, try the connect again with the same IP Type before advancing
to the next type.
Fixes: cb751012a2
Tested-by: Ladislav Michl <ladis@linux-mips.org>
Tested-by: Tore Anderson <tore@fud.no>
Seems that "dash" has issues with trap EXIT. This causes
test failures on systems where the default shell is not "bash".
[thaller@redhat.com: patch extracted from BZ and modified to
use bash everywhere]
https://bugzilla.gnome.org/show_bug.cgi?id=761146
Specifically for resolvconf, if the write succeeded, but the pclose()
failed error would be left NULL and SR_ERROR would be returned, which
caused a crash in nm_dns_manager_end_updates().
