NMDeviceEthernet and NMDeviceMacsec implement their own retry policy
for connection using 802.1X, and consider the credentials wrong when
the authentication fails for 3 times. In such case, they also disable
autoconnection for the device by setting the state reason NO_SECRETS.
This means that it's not possible at the moment to choose how many
times the authentication will be retried since they don't use the
standard reconnection logic.
Change NMDeviceEthernet and NMDeviceMacsec to use the number of
retries from connection.autoconnect-retries instead of a hardcoded
value to decide how many times the authentication must be restarted.
Use the per-connection authentication timeout for 802.1X Ethernet,
MACsec and Wi-Fi connections. In case the value is not defined, fall
back to the global one.
The wpa_supplicant API supports to enable/disable each TLS version
individually, or leave it at the default. Currently, the default
means to enable a TLS version, thus, the only meaningful option
for the momemnt means to explicitly disable it.
In the future, supplicant may disable options by default, and
the inverse option can become interesting to configure
"tls_disable_tlsv1_0=0". When that happens, we can solve it by
adding another flag NM_SETTING_802_1X_AUTH_FLAGS_TLS_1_0_ENABLE.
Change the previous behavior of the NMSetting8021xAuthFlags.
Previously, when not specifying TLS_DISABLE_DEFAULT, all
options were unspecified. On the other hand, when specifying
a single TLS disable flag, all versions were explicitly enabled
or disabled.
Instead, change the meaning of the disable flags. When present,
it explicitly disables an option. But it does not explicitly enable
it.
Some AAA servers have issues interoperating with select TLS versions,
which wpa_supplicant negotiates by default.
This commit allows disabling troubling versions of TLS so that
connecting to broken authentication servers could be possible.
We log updates of the Wi-Fi AP with a separate logging domain LOGD_WIFI_SCAN.
However, there is ony "update" message that is triggered every 6 seconds, which
becomes especially verbose.
Suppress this one and only log it when compiled --with-more-logging. And then
only log with level LOGL_TRACE, so the user still can filter this one out.
We should only start autoconnecting after the scan is complete.
Otherwise, we might activate a shared connection or pick a
connection based on an incomplete scan list.
https://bugzilla.gnome.org/show_bug.cgi?id=770938
It allows derived classes to override the autoconnect-allowed
state.
We already have
- NM_DEVICE_AUTOCONNECT property, which is two parts:
- NMDevicePrivate::autoconnect_user, which is settable via
D-Bus by the use, to allow the device to autoconnect.
- NMDevicePrivate::autoconnect_intern, which is set by
internal decision.
- NM_DEVICE_AUTOCONNECT_ALLOWED signal, where other devices can
subscribe to block autoconnect. Currently that is only used
by NMDeviceOlpcMesh.
These two make up for nm_device_autoconnect_allowed().
Add another way to allow derived classes to disable autoconnect
temporarily. This could also be achieved by having the device
subscribe to NM_DEVICE_AUTOCONNECT_ALLOWED of self, or by adding
a signal slot. But a plain function pointer seems easier.
The NMDevice's autoconnect property is settable via D-Bus and is is
also modified by internal decision, like when no PIN is available.
Certain internal actions cause clearing the internal autoconnect flag,
but they should not override the user desicion.
For example, when NM awaks from sleep it would reenable autoconnect,
but it should not reenable it for devices where the user explicitly
said that autoconnect is to be disabled.
Similarly, activating a device alone is not yet an instruction to
re-enable autoconnect. If the user consciously disables autoconnect,
it should stay enabled. On the other hand, activating a device should
reenable autoconnect if it was blocked by internal decision.
We need to track these two flags separately, and set them accordingly.
Since we emit BSS_UPDATED signal before SCAN_DONE, it is very likely
that nothing actually changed. This clutters the logs with update
messages.
Also move the added/removed logging messages inside ap_add_remove().
We would call ap_add_remove() at several places without logging the
change.
We initialize the BSS asyncronously. Don't declare SCAN_DONE
until all BSS are up.
Otherwise, especially during the very first scan we declare SCAN_DONE
when having no BSS yet. This wrongly removes the pending action
"wifi-scan", while "autoconnect" cannot happen as there are not BSS
yet. Thus we declare "startup-complete" too early.
Another issue is that we may start autoconnecting with an incomplete
scan list, and thus pick a non-preferred connections.
https://bugzilla.gnome.org/show_bug.cgi?id=777831
In nm_wifi_ap_new_from_properties(), we checked that the BSSID is valid
and bailed out otherwise. Since we call nm_wifi_ap_update_from_properties()
on a created BSSID, we should ensure there too that an update does not cause
the address to become invalid.
In the unlikely case where an update would change a previously valid address
to an invalid one, we would ignore the update.
Thus, move the check for addresses inside nm_wifi_ap_update_from_properties().
Before, the NEW_BSS signal was not careful to emit the signal only when the BSS
is seen for the first time. Consequently, supplicant_iface_new_bss_cb() checked
whether it already knows about the new BSS.
Merge NEW_BSS and BSS_UPDATED. Now we emit BSS_UPDATED when either the
BSS is new or changed.
Also, in supplicant_iface_new_bss_cb() (now supplicant_iface_bss_updated_cb())
no longer constructs an @ap instance if we have a @found_ap.
In some situations there can be a value of having a separate ADD signal.
But only when there the consumers care, and if the consumers can trust that
ADD is not just an UPDATE. The only consumer doesn't care and it not not be
trusted, so merge the signals.
If the assoc-request is cancelled while an "AddNetwork" request is
pending, we must cleanup the added network when the request succeeds.
The issue can also happen when NetworkManager shuts down and exits
the mainloop. This scenario is unsolved as the cleanup action
"RemoveNetwork" has no chance to run.
"AddBlob" works differently in that blogs are added with a specific name,
not like "AddNetwork", where a new D-Bus path is created. Maybe we should
also cleanup blobs that were added by us, but currently we don't.
Instead of having a NM_SUPPLICANT_INTERFACE_CONNECTION_ERROR signal to notify
about failures during AddNetwork/SelectNetwork, accept a callback to report
success/failure.
Thereby, rename nm_supplicant_interface_set_config() to
nm_supplicant_interface_assoc().
The async callback is guaranteed to:
- be invoked exactly once, signalling success or failure
- always being invoked asyncronously.
The pending request can be (synchronously) cancelled via
nm_supplicant_interface_disconnect() or by disposing the
interface instance. In those cases the callback will be invoked
too, with error code cancelled/disposing.
ifnet has two extra instances @p12_type/@phase2_p12_type, that only
differed from @pk_type/@phase2_pk_type by their suffix.
But as the suffix field as unused, we can drop that entirely.
If one property has multiple ways to be handled, we should not create
two ObjectType instances, instead let the ObjectType have enough
information to act accordingly.
The PKCS#11 URIs start with the "pkcs11:" scheme. There's a slight
possiblity of a clash with file names relative to the ifcfg file, but
that's probably is unlikely enough the leave us not worried.
The alteratives are probably more horrible (using a different key, or
using a separate key for the scheme alone) and it's already simple
enough to avoid a clash by using an absolute file name.
main() should pass the same atomic-section-prefix setting to it's
NMConfig instances. Currently both are NULL, but make it a define
to make this explicit.
Also, make static array @default_values const and sanitize value
when setting PROP_ATOMIC_SECTION_PREFIXES property.
When the main ifcfg file contains no IP addresses, the method
will be "disabled". Later, when reading IP addresses for the
aliases, we must ensure that the method is manual.
Otherwise, validation fails with
ip.addresses: this property is not allowed for method=disabled
Update the connectivity state if we go from CONNECTED_GLOBAL to
CONNECTED_LOCAL. It will likely fail immediately (unless there's a default
route we're not aware of or the check URL is routable locally), keeping the
Connectivity property up-to-date.
The purpose of "rc-manager=symlink" is so that the administrator can point
the "/etc/resolv.conf" as a symlink to a certain file, and thus indicating
that a certain component is responsible to manage resolv.conf, while others
should stay away from it.
For example, systemd-resolved never touches "/etc/resolv.conf", but
expects the admin to setup the symlink appropriately. It also recognizes
whether the symlink points to it's own resolv.conf in /run or to another
component.
Previously, "rc-manager=symlink" would always replace a regular file
with a symlink to "/var/run/NetworkManager/resolv.conf". Only if
"/etc/resolv.conf" is already a symlink somewhere else, NM would not
touch it. This with the exception that if "/etc/resolv.conf" points to
"/var/run/NetworkManager/resolv.conf", it would replace the symlink
with the same link to raise inotify events.
Change behavior so if "/etc/resolv.conf" is already a regular file, keep
it as file.
This means, if you have multiple components that don't care, everybody
can write the "/etc/resolv.conf" (as file) and there is no clear
expressed responsibility.
It was wrong that NetworkManager would convert the file to a symlink,
this should be reserved to the admin. Instead, NetworkManager should
accept that the intent is unspecified and preserve the regular file.
It's up to the admin to replace the symlink to somewhere else (to keep
NM off), or to point it to "/var/run/NetworkManager/resolv.conf", to show
the explicit intent.
The wrong behavior causes dangling symlinks when somebody disables
NetworkManager for good.
https://bugzilla.redhat.com/show_bug.cgi?id=1367551
After commit 2049e97d9e ("dhcp: refactor parsing of 'request' and
'also request' options") NM parses all the existing 'request' and
'also request' from the original configuration file and appends them
as 'also request' to avoid duplicates and conflicts.
So if the original file contains 'request x' (which means "request
only option x instead of builtin defaults"), we would translate it
into 'also request x', which appends the option to the builtin
defaults, causing duplicates in the DHCP request as dhclient seems not
smart enough to sanitize the list by itself.
To fix this, ensure that the request list is reset if the
configuration file contains a 'request'.
Fixes: 2049e97d9ehttps://bugzilla.gnome.org/show_bug.cgi?id=778430
Also change the signature of the NM_SUPPLICANT_INTERFACE_STATE signal,
to have three "int" type arguments. Thereby also fix the subscribers
to this signal that wrongly had type guint32, instead of guint
(which happens to be the same underlying type, so no real problem).
https://mail.gnome.org/archives/networkmanager-list/2017-February/msg00021.html
