- for nm_utils_enum_to_str(), whenever encounter a numeric value
that has no expression as enum/flag, encode the value numerically.
For enums, encode it as decimal. For flags, encode it as hexadecimal
(with 0x prefix).
Also check that an existing value_nick cannot be wrongly interpreted
as a integer, and if they would, encode them instead as integers only.
- Likewise, in nm_utils_enum_from_str() accept numerical values
and for nm_utils_enum_get_values() return enum nicks that look
like numeric values in their numeric form only.
- In nm_utils_enum_from_str(), don't use g_strsplit(), but clone the
string only once and manipulate it inplace.
- Accept '\n' and '\r' as additional delimiters for flags.
- For consistency, also return an err_token for enum types. If the caller
doesn't care about that, he should simply not pass the out-argument.
Unfortunately nm_utils_enum_to_str() doesn't allow to specify the
separator between enum values. Since the function is public API and
can't be modified now, add a new internal function which accepts the
separator as argument.
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.
"shared/nm-setting-metadata.h" will contain data structures
to handle NM setting properties in a generic way.
For now, this is internal API, but shared between libnm-core (which
extends to libnm, NetworkManager, device-plugins, settings-plugins),
and nmcli.
Related: https://bugzilla.gnome.org/show_bug.cgi?id=732292
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
