But, of course, only one realized device can have the same
interface name at a time.
This commit effectively reverts most of:
1b37cd0340
core: allow ActiveConnections to be created without a device
But it's not easy to do a separate revert of that code due to
interdependencies with nm-manager.c.
Creating devices when they are defined by a connection also makes
makes it possible to require the NMDevice to be present when
activating it, which means we can remove a bunch of code from
NMManager that had to handle software devices not existing yet at
the time of the activation request.
But it also means we must be more careful when finding master
interfaces during slave activation, since we cannot simply match
by interface name alone. Instead we must find the master which
matches both the interface name and can control slaves of the type
which is being activated.
Ensure the platform link with the same interface name as the
NMDevice is actually compatible with it before using the link
for initialization of device properties. If not, remove the
NMDevice and create a new one since there are kernel resources
with a different type.
Unrealized devices aren't backed by kernel resources and so won't know
all of their attributes. That means three things:
1) they must update their attributes when they become realized
2) they must clear those attributes when unrealized
3) they must be looser in checking compatible connections until
they are realized
This requires that the setup() function be split into two parts, start & finish,
because finish must be run after add_device()
Also, we can simplify whether to pay attention to 'recheck-assume', which
is now dependent on priv->is_nm_owned, because the only case where NM should
*not* listen for the 'recheck-assume' signal is when the device is a
software device created by NM itself. That logic was previously spread
across the callers of add_device() but is now consolidated into
nm-manager.c::device_realized() and nm-device.c::nm_device_create_and_realize().
The device properties are obtained via netlink, thus we get proper
platform notifications whenever they change. So the device properties
always reflect the platform state and there is no need to refresh
it during update_connection()/check_connection_compatible().
This property is TRUE for devices that exist either as a kernel device
or are backed by some other resource (eg, ModemManager object, Bluez
device, etc). It will eventually be FALSE for software devices that
are not yet instantiated.
There is only one user of the NM_DEVICE_MASTER property (NMActiveConnection).
device_master_changed() uses the property for change notifications,
but returns early if !nm_device_get_master().
We might emit the "notify::master" signal too often, even when nothing
changed (because currently we always emit it when priv->master changes).
If we would fix that to only emit the signal when nm_device_get_master()
actually changes, it would still be correct, because device_master_changed()
doesn't care about notifications when the master is unset.
Hence, the only user doesn't care about the difference. So change it because
it's unexpected that the property and function are not completely equal.
Commit cd3df12c8f reused the
virtual function component_added() to notify the vlan device
about a possibly new parent.
This reuse of the virtual function for another purpose is confusing.
Clean that up by splitting the implementation and add a new
virtual function nm_device_notify_new_device_added() which gets
(only implemented by NMDeviceVlan).
When deleting a master-device either via `nmcli device delete`
or `ip link delete`, the slave-device would hang.
This seems to be broken for a very long time already.
This is due to the following:
#0 0x00005555555f548c in nm_device_slave_notify_release (self=0x555555dc1300, reason=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:2175
#1 0x00005555555d6de2 in nm_device_release_one_slave (self=0x555555de3dd0, slave=0x555555dc1300, configure=0, reason=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:1117
#2 0x00005555555f02b7 in device_link_changed (self=0x555555dc1300) at devices/nm-device.c:1460
Previously, nm_device_slave_notify_release() being called with reason
"NONE" did not actually transition the device-state, thus keeping the
device wrongly in activated state.
There were two callers that passed configure=FALSE to nm_device_release_one_slave(),
(and thus reason=NONE to nm_device_slave_notify_release()):
- (1) device_link_changed():
nm_device_release_one_slave (priv->master, self, FALSE, /*wrong reason NONE*/);
- (2) nm_device_removed():
nm_device_release_one_slave (priv->master, self, FALSE, NM_DEVICE_STATE_REASON_REMOVED);
We should always change the device-state during nm_device_slave_notify_release()
regardless of the reason.
(2) was added by commit c83b40aca7, later
refined by commit 5dd48f7527. In a way
change the second fix to perform some of the configuration (but still
not unenslaving the device).
The new object type represents tunnels over IPv4 and IPv6.
We have a single setting type (NMSettingIPTunnel) for tunnels and it
can't be shared among different device factories. So we define also a
single device type for all tunnels.
This new object will also represent GRE tunnels, which before were
instantiated as NMDeviceGre and had a ".Device.Gre" D-Bus
interface. This commit introduces a change in behavior.
This enum was unused and meaningless because the platform signals
are emitted as a consequence of netlink messages. It is not clear
whether a netlink message was received due to an external event
or an internal action.
The DHCP client from new libsystemd-network requires a link-local IPv6
address to be passed to the library; add a new argument to
nm_dhcp_manager_start_ip6() and related functions.
When deconfiguring a device, we must also explicitly clear the
default-route -- unless the device was assumed.
This can easily reproduced by disconnecting the cable from the
wired connection that has the default rout. Prevously, the
default-route was not cleared and lingered around.
https://bugzilla.gnome.org/show_bug.cgi?id=757587
Even if update_seen_bssids_cache() is called by set_current_ap() it did not
really update the cache because it was called in NM_DEVICE_STATE_PREPARE state.
So the cache was only updated by periodic_update() when the connection roamed
to another AP.
Fixes: 1283816b41https://bugzilla.redhat.com/show_bug.cgi?id=1094298
The nm_supplicant_config_add_*() functions used to log failures
themselves. As also the caller was logging the failure this resulted
in duplicate logging lines like:
<warn> MAC address randomization is not supported
<error> [1447867727.909185] [nm-device-wifi.c:2238] build_supplicant_config(): (wlp3s0): Couldn't add 802-11-wireless setting to supplicant config.
<error> [1447867727.909261] [nm-device-wifi.c:2472] act_stage2_config(): (wlp3s0): Activation: (wifi) couldn't build wireless configuration.
Instead, propagate the error reason back to the caller where there
is more context to log one single concise message.
Now you'd see only:
<error> [1447935996.859371] [nm-device-wifi.c:2475] act_stage2_config(): (wlp3s0): Activation: (wifi) couldn't build wireless configuration: 802-11-wireless: cannot enable mac-randomization due to missing supplicant support
Modems often don't expose all the required properties until they have
been unlocked, and that includes the IP types supported by the modem.
With an autoconnect WWAN connection where the SIM requires a PIN, there
were two problems:
1) the PIN is a secret and we don't have it until it's explicitly requested
during the activation process, so we cannot gate GSM connection availability
on whether a PIN is present since this happens long before we request secrets
2) when the modem is locked it may not report the supported IP types, which
caused an auto-activation to fail early becuase IP compatibility is checked
before the PIN is sent to the modem
Rework connection activation flow into a series of concrete steps, where the
PIN is sent to the modem if required, and only after the modem is actually
unlocked does the connection proceed. This does mean that any connection
marked 'autoconnect' can theoretically enable a PIN-locked modem even if
the connection has no PIN defined, but there's no good way around that.
NetworkManager would activate the connection
Device subclasses can call nm_device_recheck_available() at any time,
and the function would change the device's state to UNKNOWN in cases
where the device was available already. For WWAN devices, availability
is rechecked every time the modem state changes, resulting in:
NetworkManager[28919]: <info> (ttyUSB4): modem state changed, 'disabled' --> 'enabling' (reason: user-requested)
NetworkManager[28919]: <debug> [1445538582.116727] [devices/nm-device.c:2769] recheck_available(): [0x23bd710] (ttyUSB4): device is available, will transition to unknown
NetworkManager[28919]: <info> (ttyUSB4): modem state changed, 'enabling' --> 'searching' (reason: user-requested)
NetworkManager[28919]: <debug> [1445538582.776317] [devices/nm-device.c:2769] recheck_available(): [0x23bd710] (ttyUSB4): device is available, will transition to unknown
These properties limit whether the connection applies to a certain WWAN modem
based on the modem's device ID or SIM ID (as reported by the WWAN management
service), or through the MCC/MNC ID of the operator that issued the SIM card.
If the supplicant supports it and the connection requests it, tell
the supplicant to randomize the MAC address for the association.
In addition, like both iOS, Android, and other OSs always randomize
the MAC address when performing a WiFi scan.
Commit d518278011 changed
the hashing for the APs to use direct-hashing.
That was wrong because get_ap_by_path() needs a full
string-comparison.
Fixes: d518278011
Now that NM follows the supplicant's scan list and CurrentBSS, any AP that isn't
known to the supplicant will be 'fake', and priv->current_ap always tracks
CurrentBSS.
We can then simplify link_timeout_cb() because any AP that would have been
force-removed before will now be marked "fake" if it's unknown to the supplicant,
and will always be removed by set_current_ap(), so we can remove the force
argument. To better fix#733105 we never want to remove an AP known to
the supplicant, even if it we failed to connect to it.
https://bugzilla.gnome.org/show_bug.cgi?id=733105
Since commit 7cb323d923,
nm_ap_new_from_properties() will always return an
AP with BSSID set. Restore the assertion during
try_fill_ssid_for_hidden_ap().
This reverts commit e9bc18d2a7.
Previously most objects were implicitly unexported when they were
destroyed, but since refcounts may make the object live longer than
intended, we should explicitly unexport them when they should no
longer be present on the bus.
This means we can assume that objects will always be un-exported
already when they are destroyed, *except* when quitting where most
objects will live until exit because NM leaves interfaces up and
running on quit.
The @aps hash has the D-Bus path of the exported
object as key. It already rightly saved to additionally
copy the string and relied on the path being stable.
When doing that, we can just go one step further and
use direct-hashing instead of string-hashing.
Note that NMExportedObject already promises that
the path will not change as long as the object is
exported. See code comments in the export/unexport
functions.
For future use of ObjectManager, we must explicitly unexport
the AP and no longer depend on having it unexported during
deconstruction (because object manager keeps the instance alive).
Also refactor adding/removal of APs and move the export/unexport
calls to the place where we emit the signal.
