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().
When the receive buffer is too small, we easily can hit ENOBUFS during recvmsg()
and need to resync the platform cache. But even worse, we possibly also loose
ACKs for pending netlink requests so that requests seem to fail (although they
might have succeeded).
Avoid that harder by increasing the buffer size to 8MB. This is also
done by networkd:
be660c371b
When we decide to add a new link, we alredy checked that no such link exists
(ignoring race conditions).
It is wrong to accept a EXITS failure when adding the link. There is no guarantee
that the existing link has all the same properties as the one we intend to add.
More importantly, this link was added externally outside of NetworkManager and it
should not be taken over.
Just treat EXISTS as a failure as any other.
When reading from netlink-socket fails with NLE_NOMEM, messages were
lost. In this case the cache must be resynced and all pending messages
from the socket are rejected via "event_handler_recvmsgs (platform, FALSE)".
In this case, we don't want to handle the received messages as the
cache anyway needs to resync. However, we are still interested in
all queued ACKs that are there.
We are also interested in RTM_NEWADDR messages which we use to detect
kernel support via _support_kernel_extended_ifa_flags_detect().
NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST is a multi-flag value combining all
the hooks that compose a user-request. Add a special value that has no esplicit
meaning except that it ~is~ a user-request.
For update, don't delete first and add it again. Just do it
in one step.
For recheck, don't delete all connections first to add them
all anew. Instead, check what changes and only emit the changed
signal if there are any actual changes.
