This is mainly to enable using 8021x networks, which have to be
preprovisioned as an IWD config file to be supported and can not be
configured by asking the user for secrets over DBus, this is an IWD's
design choice.
Note that this assumes that secrets are only used during the Stage 2 of
the activation, i.e. for the wifi handshake, not in the later stages.
Keep a list of IWD's Known Networks which are networks that have their
configurations stored by IWD including the secrets, either because they
have been connected to before or because they were preprovisioned on the
machine.
There are some tests located in different directories which are
using the same name. To avoid any confussion a prefix was used to
name the test and the target.
This patch uses the prefix just for the target, to avoid any
collision that may happen, and uses the `test-` pattern as the
name.
https://mail.gnome.org/archives/networkmanager-list/2017-December/msg00051.html
NM_CONFIG_GET_DATA_ORIG is the configuration that was loaded the first time.
NM_CONFIG_GET_DATA is the currently loaded one. Sometimes we want to always
stick to the original configuration, if we don't support reloading the
parameter (for example main.plugins, because it would be cumbersome to properly
implementing loading/unloading setting plugins.
In this case however, we can allow reloading the configuration just fine.
Of course, this only matters, if the device appears after the configuration
is reloaded, for example by reloading the driver.
Also, don't log any warnings, unless necessary.
Add the PSK agent support to support PSK networks. Note that the PSK
itself will be saved by IWD on the first successful connection to the
network and will not be updated when it is changed by the user on the NM
side, this still needs fixing like a bunch of other problems.
[bgalvani@redhat.com: fix checking return value of nm_utils_random_bytes()]
Let the config file select between creating classes of NMDeviceWifi
(for the usual wpa_supplicant based devices) and NMDeviceIwd depending
on the new NetworkManager.conf setting.
[bgalvani@redhat.com: fix leaking @backend in create_device()]
Add the NMIwdManager singleton to be responsible for matching
NMDeviceIwd objects created from platform devices, to IWD Device dbus
objects when they appear/disappear.
This is very similar to NMDeviceWifi but simplified to remove the things
currently unsupported and with calls to nm_platform_wifi_* and
nm_supplicant_* replaced with IWD DBus API calls. Only unsecured
infrastructure-mode networks are supported here.
[bgalvani@redhat.com: fix compilation error after rebase for
NMActRequestGetSecretsCallId]
[thaller@redhat.com: don't use _() macro strings server side.
Translating strings only makes sense for clients that set environment
variables accordingly.]
OLPC devices cannot autoconnect, according to can_auto_connect().
We should instead reject any attempt to autoconnect earlier, via
get_autoconnect_allowed().
(cherry picked from commit 7074b88a6a)
Derived classes should not modify or overwrite this essential behavior
of can_auto_connect(). It doesn't belong to the virtual function.
(cherry picked from commit 715aebe08a)
Replace the usage of g_str_hash() with our own nm_str_hash().
GLib's g_str_hash() uses djb2 hashing function, just like we
do at the moment. The only difference is, that we use a diffrent
seed value.
Note, that we initialize the hash seed with random data (by calling
getrandom() or reading /dev/urandom). That is a change compared to
before.
This change of the hashing function and accessing the random pool
might be undesired for libnm/libnm-core. Hence, the change is not
done there as it possibly changes behavior for public API. Maybe
we should do that later though.
At this point, there isn't much of a change. This patch becomes
interesting, if we decide to use a different hashing algorithm.
- cleanup data type and use guint32 consistently. We might want to
introduce a new "infinity" value. But since libnm's
NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range
0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity
will have the numerical value G_MAXINT32, hence guint32 is just
fine.
- make use of existing ipv6.dhcp-timeout setting and add global
default configuration in NetworkManager.conf
- instead of having subclasses call nm_device_set_dhcp_timeout(),
add a virtual function get_dhcp_timeout().
Only the D-Bus bits use it, and we wouldn't pass a GVariant array around
in internal code anyway. Also validate the scan options earlier rather
than waiting for the supplicant to tell us they are invalid.
Enable background scanning for most WiFi connections except for
shared/AP and BSSID-locked ones. Make the non-WPA-Enterprise
interval very, very long to effectively disable periodic scanning
while connected.
Related: https://bugzilla.gnome.org/show_bug.cgi?id=766482
Change it to return TRUE when scanning is prohibited so that we
don't have to use use g_signal_emitv() and its special handling of
return values. Make the return value only change when we don't
want the default behavior (which would be to allow the scan).
Also add a parameter to the signal indicating whether the scan is
user/dbus-requested or whether it's an internal periodic scan.
Since commit 2b51d3967 "device: merge branch 'th/device-mtu-bgo777251'",
we always set the MTU for certain device types during activation. Even
if the MTU is neither specified via the connection nor other means, like
DHCP.
Revert that change. On activation, if nothing explicitly configures the
MTU, leave it unchanged. This is like what we do with ethernet's
cloned-mac-address, which has a default value "preserve".
So, as last resort the default value for MTU is now 0 (don't change),
instead of depending on the device type.
Note that you also can override the default value in global
configuration via NetworkManager.conf.
This behavior makes sense, because whenever NM actively resets the MTU,
it remembers the previous value and restores it when deactivating
the connection. That wasn't implemented before 2b51d3967, and the
MTU would depend on which connection was previously active. That
is no longer an issue as the MTU gets reset when deactivating.
https://bugzilla.redhat.com/show_bug.cgi?id=1460760
In AP mode we should not look up an access point. It is wrong to
do, and it ends up marking the connection as hidden.
It seems wrong to me that if the client explicitly set
hidden=FALSE before AddAndActivate(), that complete_connection()
would still set it to TRUE if it cannot find the access
point. That is, because complete_connection() does not know
whether hidden was omitted or set intentionally by the user.
g_variant_new_parsed() returns a floating reference. Later, we pass
the floating reference to nm_settings_connection_new_secrets(),
but don't transfer ownership.
That might not be a bug (I didn't check), but it requires that
nm_settings_connection_new_secrets() does not take a reference
to the secrets variant.
Convert the floating reference to a real reference to avoid
this dangerous pattern.
Fixes: 0eb7617504
We pack the PSK byte array in a GVariant of type string,
hence all characters must be valid UTF-8.
Maybe we should do something more sophisticated but let's
just ignore such pass phrases.
Fixes: 0eb7617504
Exposure of this property on D-Bus would be useful for the GUIs to encourage
the users to enter a PIN or push a button.
We'll also use it to decide whether a connection will initiate WPS
enrollment unless the user overrides the default.
Now that we have a PMF connection property, get rid of the previous
code to globally enable/disable PMF and use the 'ieee80211w'
configuration option for each configured network when the supplicant
supports it.
Reduce the use of NM_PLATFORM_GET / nm_platform_get() to get
the platform singleton instance.
For one, this is a step towards supporting namespaces, where we need
to use different NMNetns/NMPlatform instances depending on in which
namespace the device lives.
Also, we should reduce our use of singletons. They are difficult to
coordinate on shutdown. Instead there should be a clear order of
dependencies, expressed by owning a reference to those singelton
instances. We already own a reference to the platform singelton,
so use it and avoid NM_PLATFORM_GET.
The address change involves setting the link down which causes the supplicant
interface to change state and in turn another scan attempt. This could lead to
a loop in case of broken drivers that are not able to change the MAC address
iff the MAC address is attempted at each scan request.
https://bugzilla.redhat.com/show_bug.cgi?id=1382741
IEEE_80211_IE_VHT_CAP has zero hits searching the internet.
WLAN_EID_VHT_CAPABILITY is how the same define is called by
kernel's "include/linux/ieee80211.h".
Use the same name as kernel.
Also, collect the maximum of @max_rate.
