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.
Due to dbus-glib limitations we still have to keep two copies of this,
and furthermore PropertiesChanged won't yet trigger for the VPN bits
since there's no way to push out signals on a different interface.
It's a singleton, but PolicyKit didn't increment the reference count
when returning from polkit_authority_get() like we expected (which has
since been fixed upstream). So for now, just don't unref the authority
at all.
Since we don't do that, there's a chance that some PolicyKit calls could
be outstanding when either the NMSysconfigSettings object or one of the
NMSysconfigConnection objects are around, so we make sure we cancel any
PolicyKit calls when the object gets disposed. This is tricky, because
canceling them from the dispose may mean that the callback gets called
after the object is actually destroyed, so we have to be careful not to
access any private object data from the callbacks in that situation.
Based on a patch from Alexander Sack, but hugely
modified by me to make use of allocated realpath results
instead of stack-based arrays, and to fix an omission in
the original patch that would still have used the
non-realpath-resolved path to /etc/resolv.conf when doing
the atomic rename of the tempfile to resolv.conf.
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.
Two errors here; first, need_secrets_tls() was not updated correctly
for the certificate paths changes that landed recently, and would
have incorrectly returned "no secrets required" for the PATH scheme.
Second, an incorrect strcmp() comparison in need_secrets_phase2()
meant that the wrong TTLS phase2 method would get asked if it
required secrets.
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.
