Given connection details, complete the connection as well as possible
using the given specific object and device, add it to system
settings, and activate it all in one method.
Instead of a bizare mechanism of signals back to the manager
object that used to be required because of the user/system settings
split, let each place that needs secrets request those secrets
itself. This flattens the secrets request process a ton and
the code flow significantly.
Previously the get secrets flow was something like this:
nm_act_request_get_secrets ()
nm_secrets_provider_interface_get_secrets ()
emits manager-get-secrets signal
provider_get_secerts ()
system_get_secrets ()
system_get_secrets_idle_cb ()
nm_sysconfig_connection_get_secrets ()
system_get_secrets_reply_cb ()
nm_secrets_provider_interface_get_secrets_result ()
signal failure or success
now instead we do something like this:
nm_agent_manager_get_secrets ()
nm_agent_manager_get_secrets ()
request_start_secrets ()
nm_sysconfig_connection_get_secrets ()
return failure or success to callback
We only really need one state for the supplicant interface which
simplifies handling in the Wifi and Wired device classes quite a
bit. It also simplifies the supplicant interface class too.
One behavioral change in the device classes is not running the
supplicant interface state changes from an idle; we'll have to
see if that causes problems. ISTR long ago that processing the
state change signals directly caused some issues, but we've
significantly reworked somethings since then so we may be able
to get away with this now.
Previously, NM reset permanent MAC to an interface while disconnecting. That
basically ignored MAC addresses set before NM started managing the interface.
Now, the initial MAC address is remembered and set back to the interface when
disconnecting.
The autoactivation code wasn't excluding subchannel-locked connections
when matching for devices that don't have subchannels. This only
produced a warning message though as the connection activation would
be failed by the check_connection_compatible hook.
Not all drivers will return errors when even when they don't provide
the GPERMADDR ethtool call; sometimes you'll get 00:00:00:00:00:00
which is clearly not right. In this case, fall back to the current
HW address just like if the ethtool GPERMADDR call failed.
- Just use a byte array to old MAC addresses so we don't need to
use .ether_addr_octet everywhere
- Consolidate setting the current MAC address into one location
- Make sure that if the GPERMADDR call fails we use the current MAC
(this wasn't done for wired devices)
- Make log messages consistent
This commit implements MAC cloning feature in NetworkManager. To support that,
'PermHwAddress' property is added into *.Device.Wired and *.Device.Wireless
interfaces. The permanent MAC address is obtained when creating the device, and
is used for 'locking' connections to the device. If a cloned MAC is specified
in connection to be activated, the MAC is set to the interface in stage1. While
disconecting, the permanent MAC is set back to the interface.
Where we can do so, let's use ifindex since that's actually unique
and doesn't change when the interface name changes. We already use
ifindex in a bunch of places, and netlink *only* uses ifindex, so
this will make it easier later when we move over to ifindexes fully.
Since the same interface could be used for both DHCPv4 and DHCPv6 we
can't just use 'iface' for tracking DHCP client lease changes. Instead
use a generated client ID, and track DHCP events based on the client's
PID instead of interface name.
Previously, ppp code would flip device state to _NEED_AUTH before
asking for secrets update; this is not the case anymore after landing
of f28a0df4a66e8f6c98327691c9c90df0604bbd28; hence, we need to
allow update of secrets in all ACTIVATING stages.
This patch updates this behaviour for all device classes with ppp
support.
Don't immediately tear down an active wired connection when the carrier
flips to off, but wait a few seconds for it to come back before breaking
the user's network.
Instead of doing this in every device subclass, do it in the NMDevice
superclass. nm_device_can_activate() already did the same logic that
each of the subclass device_state_changed() handlers were doing to
figure out whether they could do the transition from unavailable
to disconnected, so just use that in NMDevice and kill lots of code.
Keep a reference to the netlink monitor for as long as we have
signals attached to it. Also don't bother looking up the ifindex
in the carrier state signal handlers since we already have it
lying around in priv.
We don't actually care when pppd goes into the 'network' phase or the
'authenticate' phase, because we're looking for the IP4 configuration
to come back, and the device is already in the IP_CONFIG state.
Handling those phases would cause the device's state to jump around
between NEED_AUTH and IP_CONFIG when we were already past that phase.
Specifically, when the PPP link went down, the device would jump from
FAILED to IP_CONFIG because pppd entered the 'network' phase when
cleaning up the link. The device would also jump from IP_CONFIG to
NEED_AUTH during the connection process when we already had secrets.
With the addition of IPv6, both v4 and v6 configuration are run in
parallel, and when both have finished, then activation can proceed.
Unfortunately, two of the 3 users of PPP (PPPoE and 3G) ran PPP at
stage2, and when the PPP IPv4 config was received, jumped directly
to activation stage4. That caused the IPv6 code never to run, and
thus we hung at stage4 waiting for it to complete when nothing had
started it in the first place.
Instead, move PPP to stage3 so that
nm_device_activate_stage3_ip_config_start() can kick off both v4
and v6 IP code and we can successfully complete IP configuration
in all cases. PPP previously being in stage2 was an artifact of
the more simplistic pre-IPv6 configuration code where it didn't
matter if you skipped stage3.
