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
(cherry picked from commit 2ab2254dd7)
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.
(cherry picked from commit 6eaded9071)
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.
(cherry picked from commit 2f9166e6b9)
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.
(cherry picked from commit c9dc0eba65)
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
(cherry picked from commit e0f9677018)
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().
(cherry picked from commit e3a489180b)
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.
(cherry picked from commit 29a53b1cd7)
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.
(cherry picked from commit c47026715e)
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.
(cherry picked from commit 66c45d0fdc)
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
(cherry picked from commit 5a03de7051)
When we create a source tarball, documentation and other generated files
are disted. Those files depend on the configure options when creating
the tarball. For example, the generated man pages contain the compile time
configurable default values.
For that reason, it is generally better to regenerate the documentation when
building NetworkManager. However, let's set explict configure options to
have a more reproducible way to generate the tarball.
When doing a release, you should not just call `make dist`. Instead, the
proper way of creating an official source tarball is:
$ ./contrib/fedora/rpm/build_clean.sh --srpm
(cherry picked from commit 432717cf47)
Otherwise, substitions are not properly expanded.
For example
- "AC_SUBST(nmrundir, '${runstatedir}'/$PACKAGE, [NetworkManager runtime state directory])"
gives ${runstatedir}/NetworkManager/resolv.conf
- "AC_SUBST(nmrundir, "${runstatedir}/$PACKAGE", [NetworkManager runtime state directory])"
gives ${prefix}/var/run/NetworkManager/resolv.conf
(cherry picked from commit 4de6f603e3)
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
(cherry picked from commit f71e1379d6)
We can't pass the password obtained from
nm_setting_802_1x_get_*private_key_password() to
nm_setting_802_1x_set_*private_key() as the latter also frees the old
password.
Fixes: afd2811028
(cherry picked from commit b2146a43e5)
scan_request_cb() handles the answer from the D-Bus "Scan" method.
At that point, the scan is not yet done, it merely started. It is
wrong to already signal SCAN_DONE.
The only place where we want to signal SCAN_DONE is when we actually
receive the "ScanDone" D-Bus signal.
(cherry picked from commit 75356841fb)
In the SCAN_DONE handler, NMDeviceWifi resets the flag that indicates
that a current scan request is pending. We need to first obtain the
new APs (NEW_BSS) before signalling SCAN_DONE.
(cherry picked from commit 40a4cc5b2d)
Cache the value for accessing the GObject property
NM_DEVICE_WIFI_SCANNING.
Re-evaluating the property every time by checking the
supplicant interface is ugly because it might change
under the hood. It should only change if (and only if)
we emit a notify changed signal.
Also, avoid accessing
nm_supplicant_interface_get_scanning (priv->sup_iface)
without checking whether priv->sup_iface is not NULL.
(cherry picked from commit 4e84472b47)
When we dump a list of APs, determine one timestamp for "now",
instead of re-evaluating it every time.
This ensures that all APs are printed with the same understanding
of the current timestamp.
(cherry picked from commit 5e4d13271c)
LOGD_WIFI_SCAN is there to avoid flodding the log with continous scan
results. It should not be used for messages related to scheduling scan
requests.
This is especially important, because LOGD_WIFI_SCAN domain is not
included in LOGD_DEFAULT.
(cherry picked from commit d5657d003c)
The _LOGD() macros of NMDeviceWifi print a logging context for each
line, that is, they add a prefix with the device name.
Replace nm_wifi_ap_dump() by nm_wifi_ap_to_string() and let device
log a message about the AP.
Also, update the format for printing the AP. Now, all fields are
separated by space.
(cherry picked from commit d98fa31ddd)
- no longer bother clearing .state and .reason when the .id
field is unset. The fields just don't matter and no user
accesses these fields when the glib source id is not set.
- unify logging and give them all a prefix "queue-state[%s, %s, %u]: ".
- drop nm_device_queued_state_peek(), it only had one caller,
thus inline the trivial check.
- make nm_device_queued_state_clear() a static function
queued_state_clear()
- rename queued_set_state() to queued_state_set().
(cherry picked from commit 96b167cd97)
Reorder code to be like in other source files:
- first includes and generic defines
- then various helper structs
- then GObject related declarations, with first signal and property
enums, then the private data, then the G_DEFINE_TYPE() itself.
- finally, forward declarations for functions.
(cherry picked from commit f97d8b86fb)
We don't want to waste a full "int" size to store the @hw_addr_type
in NMDevicePrivate. Previously, that was hacked around by using guint8.
Now, instead use a bitfield which has the right type.
(cherry picked from commit cac0738723)
These two structs are only used at exactly one place: as the type
for a field in NMDevicePrivate.
Having additional structs (that are only used at one place) only
add noise. Also, there are already prior-acts of using unnamed
structs in NMDevicePrivate in case of structs that only serve
to group/namespace a set of fields.
(cherry picked from commit 5151a6071f)
All callers either use a static @action argument or keep a clone
of the string that lives as long as the action is pending. So,
save cloning the string.
(cherry picked from commit 3bc1e02adf)
While we still recheck-available, we want to queue a pending action to block
startup-complete. However, we have to queue that before removing the pending
action for "wait for supplicant".
<debug> [...] device[0x563abbcca400] (wlp2s0): remove_pending_action (0): 'waiting for supplicant'
<info> [...] manager: startup complete
<debug> [...] device[0x563abbcca400] (wlp2s0): add_pending_action (1): 'queued state change to disconnected'
(cherry picked from commit 252e95c113)
Startup-complete means that all devices have settled in a state
and no further activation is pending. When we have a recheck-available
scheduled, we clearly should not yet declare startup-complete.
Add a new pending-action "recheck-available" to avoid:
<info> [1485520408.3920] device (wlp2s0): supplicant interface state: starting -> ready
<debug> [1485520408.3920] device[0x563abbcca400] (wlp2s0): remove_pending_action (0): 'waiting for supplicant'
<info> [1485520408.3920] manager: startup complete
<debug> [1485520408.3924] device[0x563abbcca400] (wlp2s0): add_pending_action (1): 'queued state change to disconnected'
(cherry picked from commit 11744b090e)
grep-ing for '\<scanning\>' yields 42 hits under src. But only 2 are actual
references to the "scanning" GObject property of NMDeviceWifi.
Use a #define with a unique name where we mean NMDeviceWifi's property.
(cherry picked from commit 95a95b3e48)
`nm` is used by "tools/create-exports-NetworkManager.sh" script.
Alloc configuring an explicit path during configure.
BINUTILS_NM=/usr/bin/nm ./configure
(cherry picked from commit 8bc88bcc7c)
ip4_addr_subnets_is_secondary() should fill the list of addresses in
the same subnet also when returning FALSE, because
nm_platform_ip4_address_sync() uses it.
Fixes: 2f68a50041
(cherry picked from commit a347962831)
_return() assigns the return value @retval and asserts that
currently no return-value is assigned -- in order not to overwrite
a once set value.
That requires, that we call _return() and exit the main-loop right
away, without possibility to call _return() again.
However, during client_properties_changed() we easily might
receive the "notify" signal multiple times, and thus call
quit_if_connected() and _return() multiple times. That would
lead to a wrong assertion failure.
Avoid that, by disconnecting the signal handler once we reach
_return().
Fixes: f7875a42b0
(cherry picked from commit ec91f950b8)
We no longer use wpa_supplicant for MAC address randomization. Instead, NetworkManager
handles it on it's own. It is actually important that supplicant does not interfere
when setting the MAC address of the device.
The code was only in effect when supplicant has a PreassocMacAddr property.
As this is a recent feature, the left-over code wasn't noticed until now.
https://mail.gnome.org/archives/networkmanager-list/2017-February/msg00003.html
Fixes: 767abfa690
(cherry picked from commit 0cb85f161e)
