In ndisc_set_router_config(), we initialize NMNDiscAddress based on
NMPlatformIP6Address instances. Note that their handling of timestamps
is not entirely identical.
For convenience of the user, NMPlatformIP6Address allows to not specify
any timestamp. On the contrary, for convenience of implementation does
NMNDiscAddress always require fully specified timestamps.
Properly convert one representation into the other.
Previously we always updated resolv.conf on quit. When we are using
systemd-resolved the update is not necessary because the resolver on
127.0.0.53 would still be reachable after NM quits. Also, when NM
manages resolv.conf directly there is no need to update the file
again. Let's rewrite resolv.conf only when using dnsmasq.
https://bugzilla.redhat.com/show_bug.cgi?id=1541031
This makes its prototype compatible with GDestroyNotify so that GCC 8.0
won't warn.
The return value is not used anywhere and the unref() functions typically
don't return any.
Fixes the following error when building with gcc 4.8.5 and address
sanitizer:
src/dns/nm-dns-dnsmasq.c: In function 'update':
src/dns/nm-dns-dnsmasq.c:506:44: error: 'first_prio' may be used uninitialized in this function [-Werror=maybe-uninitialized]
} else if (first_prio < 0 && first_prio != prio)
^
Print the "tentative" flags as last. Most other flags, have more the character of
a user configured attribute, while "tentative" reflects the current state of the address.
Previously, we would log
secondary,tentative
and
tentative,mngtmpaddr,noprefixroute
Print the "tenative" flag last. This way, the flag that commonly
will flip by kernel's decision, is consistently printed last.
Previously, we would directly log get_expiry(), which is the absolute timestamp
inn nm_utils_get_monotonic_timestamp_s() scale. This time scale starts counting
somewhere around the time when the NetworkManager process starts, hence it is not
very intuitive to look at.
Instead, print the remaining time that is left counting from now. Since
we anyway only track timeouts with a granularity of whole seconds,
printing up to 4 decimal places is sufficiently precise.
We commonly only allow tabs at the beginning of a line, not
afterwards. The reason for this style is so that the code
looks formated right with tabstop=4 and tabstop=8.
I think we should avoid non-trailing tabs in source code.
Allowing unescaped tab characters in string literals, adds
noise when searching the code for non-trailing tabs.
Also, depending on the editor configuration, it might be
non-obvious that tabs are used. And while I dislike tabs in general,
I think they are especially bad, when they have actual meaning
in code.
Setting the state of NMActiveConnection results in invoking callbacks
in NMManager. Hence, it might be far-reaching. Clear
priv->queued_act_request before invoking the callbacks.
There is a small change in behavior:
Previously, the DEACTIVATING/DEACTIVATED states were set if and only if
the previous state was less or equal then ACTIVATED. For example,
if the state was already DEACTIVATING, it would have done nothing.
Now, nm_active_connection_set_state_fail() transitions the states
depending on the previous state. E.g. it would only set DEACTIVATING
state, if the previous state was ACTIVATING/ACTIVATED. On the other hand,
it would always progress the state to DEACTIVATED.
The new behavior makes more sense to me, although I doubt that there is
a visible difference.
unmanaged_to_disconnected() is supposed to mark the device as managed.
However, it may easily be unable to do so, for example if the device
is unmanaged by NM_UNMANAGED_USER_SETTINGS.
Shortly before actually enqueuing the activation request, check and
error out. Otherwise, we might hit an assertion later in
_device_activate().
Note how recheck_assume_connection() called:
nm_exported_object_export (NM_EXPORTED_OBJECT (active));
active_connection_add (self, active);
nm_device_queue_activation (device, NM_ACT_REQUEST (active));
That differs from the order during _internal_activate_generic(), where
we would end up with:
nm_exported_object_export (NM_EXPORTED_OBJECT (active));
nm_device_queue_activation (device, NM_ACT_REQUEST (active));
active_connection_add (self, active);
It makes more sense to me to *first* add the connection, and only then
starting the activation with nm_device_queue_activation().
Also, let active_connection_add() always export the new active
connection object, if it is not already exported. All callers of
active_connection_add() ensured that the new object is already
exported.
NM_DEVICE_OVS_INTERFACE_GET_PRIVATE() is implemented via the _NM_GET_PRIVATE()
macro. This macro uses C11's _Generic() to provide additional compiler checks
when casting from an incompatible pointer type.
As such,
NMDevice *device = ...;
NMDeviceOvsInterfacePrivate *priv;
priv = NM_DEVICE_OVS_INTERFACE_GET_PRIVATE (device);
causes a compilation error:
error: ‘_Generic’ selector of type ‘NMDevice * {aka struct _NMDevice *}’ is not compatible with any association
One workaround would be to cast the pointer first:
priv = NM_DEVICE_OVS_INTERFACE_GET_PRIVATE ((NMDeviceOvsInterface *) device);
A better fix is to mark NMDevice as a compatible pointer in _NM_GET_PRIVATE(),
which this patch does.
Previously, this went unnoticed, because due to bug "a43bf3388 build: fix configure
check for CC support of _Generic() and __auto_type", we failed to detect support
for _Generic() when compiling with -Werror. That essentially disables this check,
and NM_DEVICE_OVS_INTERFACE_GET_PRIVATE() would do a direct cast.
A workaround for this build failure might be to build with -Werror, which accidentally
results in not using _Generic().
https://bugzilla.gnome.org/show_bug.cgi?id=793183
Fixes: 8ad310f8e3
OvsInterface can postpone the stage3_ip[46]_config until the link
actually appears. It ought to restart the stage only when the link
appears, not upon further changes to it (which would trip an assertion
when starting the DHCP client while one already exists).
https://bugzilla.redhat.com/show_bug.cgi?id=1540063
Must always initialize cleanup variable, to be able to build with
"-fexceptions".
make[2]: Entering directory './contrib/fedora/rpm/NetworkManager.20180124-060444.C5tHCi/BUILD/NetworkManager-1.11.1'
CC src/devices/wifi/src_devices_wifi_libnm_device_plugin_wifi_la-nm-device-iwd.lo
In file included from ./shared/nm-utils/nm-glib.h:27:0,
from ./shared/nm-utils/nm-macros-internal.h:60,
from ./shared/nm-default.h:257,
from src/devices/wifi/nm-device-iwd.c:21:
src/devices/wifi/nm-device-iwd.c: In function ‘deactivate_async_finish’:
./shared/nm-utils/gsystem-local-alloc.h:37:8: error: ‘variant’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (*(Type*)v) \
^
src/devices/wifi/nm-device-iwd.c:405:29: note: ‘variant’ was declared here
gs_unref_variant GVariant *variant;
^~~~~~~
Fixes: d0c1e1a62a
XXX was used to either raise attention (NOTE) or to indicate
that this is ugly code that should be fixed (FIXME). The usage
was inconsistent.
Let's avoid XXX and use either NOTE or FIXME.
We can disable/enable configuration snippets per NetworkManager
version. But we must compare it against the current version
that we build, not the current API version.
In a previous patch I added deactivate_async to make sure that NM
auto re-connect waits for the IWD state to changed from "disconnecting"
to "disconnected" before starting a new activation when the user wants
to switch from one profile to another. This doesn't account for when
IWD itself goes into "disconnecting" because of a connect failure.
When IWD goes into the "disconnecting" state we call
nm_device_state_changed (NM_DEVICE_STATE_FAILED,
NM_DEVICE_STATE_REASON_SUPPLICANT_DISCONNECT)
immediately to give feedback to user as soon as possible. We will
return FALSE from get_autoconnect_allowed for the period the
"disconnecting" state.
Deactivating the connection translates to a Device.Disconnect dbus call
to IWD. The dbus call normally returns immediately because the
corresponding nl80211 command returns immediately but we can't rely on
that. Make sure that NMDevice waits for the IWD method return before
continuing with the new activation request when switching wifi networks.
The handler would until now check if nm_device_is_activating() was true
or the NMDevice state was "activated" to decide whether to report to
NMDevice that we'd been unexpectedly disconnected (i.e. connection
failed). However NM's "prepare" and "need auth" states correspond to
IWD's "disconnected" state because they don't involve Wifi
authentication/association.
Additionally nm_device_is_activating() returns TRUE even when NMDevice
state is "disconnected" but an activation request is pending. As a
result when switching networks, NMDevice would first save the activation
request and go into the "disconnected" state, we'd then call the IWD's
Disconnect method and when we received the IWD state change notification
to "disconnected", we'd cause the pending activation request to be
considered a failure. The handler shouldn't report a failed
connection when the NMDevice state is "disconnected".
We already avoid committing the IP configuration for external devices
(see commit 60334a2893). However, we still start DHCP/IPv6-autoconf
and, especially, we change sysctl values of the device.
To be sure that no action is taken on the device, return early from
the IP configuration phase, as in the method=disabled/ignore case.
https://bugzilla.redhat.com/show_bug.cgi?id=1530288
Previouslly, the value of ieee80211w and key_mgmt field in
wpa_supplicant.conf was defined by the value of pmf.
NM_SETTING_WIRELESS_SECURITY_PMF_DISABLE
ieee80211w=0
key_mgmt=wpa-eap
NM_SETTING_WIRELESS_SECURITY_PMF_OPTIONAL
ieee80211w=1
key_mgmt=wpa-eap wpa-eap-sha256
NM_SETTING_WIRELESS_SECURITY_PMF_REQUIRED
ieee80211w=2
key_mgmt=wpa-eap-sha256
Though these works, these does not include whole combinations.
The key_mgmt could be set independent of ieee80211w value.
For example, management frame protection could be used with
wpa-eap.
ieee80211w=2
key_mgmt=wpa-eap
And wpa-eap-sha256 could be used without management frame
protection.
ieee80211w=0
key_mgmt=wpa-eap-sha256
So this patch uses always key_mgmt=wpa-psk wpa-psk-sha256 or
key_mgmt=wpa-eap wpa-eap-sha256. By this setting, when AP
supports both, stronger algorithm will be chosen (ex. when AP
supports both wpa-eap and wpa-eap-sha256, wpa-eap-sha256 will be
chosen).
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
