device->want_signal was never set to TRUE when addrconf was started,
causing random netlink events (say for link-local address addition
or removal) to trigger the config-changed signal from
nm_ip6_device_sync_from_netlink() at the wrong time. This would
cause IPv6 address configuration to look like it succeeded, when
in fact the config timeout was still in-force. Thus device
activation would proceed if IPv4 was enabled, but a few seconds later
the device would be deactivated due to the still active IPv6
timeout.
So fix that and clarify when the events from the IPv6 manager happen,
and what the want_signal variable is really for.
The error object passed to the plugin's add-connection handler wasn't
getting properly cleared if an earlier plugin had failed to write
the connection and fell back to the current plugin.
NM previously only cleared secrets when the VPN service daemon quit,
and the service daemons are on a 10-second inactivity timer. So if
the user tried to re-activate the failed VPN connection within 10
seconds the old secrets would get used, which clearly isn't what we
want. Ensure that whenever the VPN connection fails or disconnects,
we ask the settings service for secrets again the next time.
NM didn't pass it to MM anyway, so it was mainly unused, but the band settings
were still wrong. Fix that (and still preserve ABI) by adding a new property
for allowed bands that can actually hold all the bands instead of limiting
to 16-bits. Clean up some of the deprecation stuff at the same time to make
it clearer what's deprecated and what to do about it.
Commit 715ddd2045 broke sharing because
sometimes a multi-argument string gets passed in rule->rule. Revert
most of that commit. A bunch of cleanups by dcbw too.
Fix up refcounting, plus it turns out that we already have the MAC address
lying around as a GObject data item, so we don't need to go grab it
from the connection itself.
An ethernet device that's actually a component of a modem could get
added to the device list, but then destroyed without getting removed
from the device list.
So that Bluetooth can use them. They used to be NMDevice subclasses, but
we need them to be generic objects that both bluetooth and the normal
modem stack can use. All because GObject can't do multiple inheritance,
but that would probably be even messier.
So now that we have generic modem objects, we can create the actual
NMDevice subclasses that will wrap them for non-BT modems, and then
also have NMDeviceBt wrap them too for DUN.
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.
In the past networkmanager did not allow to manually disconnect devices.
Manually disconnected devices will not be automatically reconnected until one
of the following events occur:
1. user activates a connection for the currently disconnected device
2. network manager awakes from hibernate/suspend
3. network manager is restarted (e.g. reboot)
Add a Disconnect method to generic NMDevice dbus interface; set a new private
autoconnect_inhibit flag if Disconnect method is called through dbus.
Based on this auto activation for devices gets inhibited until one
of the above events occur.
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.
Previous connection-assumption code that made sure not to touch
ethernet devices when NM quit also didn't clean up after devices
that were physically removed, which was wrong.
Or really, any time the parent IP4 config is cleared which is pretty
much only when the device is going down. Avoids a warning when
nm_system_add_ip4_vpn_gateway_route() can't get the parent IP4Config
because it doesn't exist.
The secrets provider might be unrefed while processing the response,
causing a double-free when the unref triggers the weak ref notifier
and clears out the GetSecretsInfo, but then later the dbus handler
that got the response in the first place tries to free the info
explicitly. So keep the provider around while processing the result.
Instead of immediately... devices handled externally from NM (by
ModemManager or Bluez or whatever) have a slight delay in reporting
to NM that they device has been removed (due to internal housekeeping
and then pushing the event into D-Bus signals or something) and thus
when NM notices PPP failures and tries to reschedule activation
of autoconnect=true connections, it fails the reactivation because
the device actually is no longer present, but it hasn't gotten the
device-removed event from MM or Bluez yet. That sets the invalid
tag on the connection, and when the device gets replugged, the
invalid tag suppresses autoconnect.
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.
