DISCONNECTING: the only active network connection is now being disconnected
LOCAL, SITE, GLOBAL: one-stop items for level of connectivity, which
we'll use to show when we think we're actually connected to the internet
or behind a captive portal or something
sleep, wake, StateChange, all deprecated in 0.8, are now removed.
sleep & wake are replaced with the Sleep() method, while
StateChange is replaced with the StateChanged signal which has
the same arguments.
This policy will allow users to modify their personal connections (ie
maybe VPN connections, etc) distinctly from system-wide connections that
affect more than just their user. It makes sense to be more lenient when
making changes to settings that don't affect other users.
Meaning stays the same, but this will allow us to differentiate
in the future between personal connections (ie, just visible to
one user) and system connections (visible to more than one user).
It's the thing that owns the secrets anyway, and it simplifies things to
have the secrets handling there instead of half in NMActRequest and
half in NMManager. It also means we can get rid of the ugly signals
that NMSettingsConnection had to emit to get agent's secrets, and
we can consolidate the requests for the persistent secrets that the
NMSettingsConnection owned into NMSettingsConnection itself instead
of also in NMAgentManager.
Since the NMActRequest and the NMVPNConnection classes already tracked
the underlying NMSettingsConnection representing the activation, its
trivial to just have them ask the NMSettingsConnection for secrets
instead of talking to the NMAgentManager. Thus, only the
NMSettingsConnection now has to know about the agent manager, and it
presents a cleaner interface to other objects further up the chain,
instead of having bits of the secrets request splattered around the
activation request, the VPN connection, the NMManager, etc.
When a user makes an explicit request for secrets via GetSecrets
or activates a device, don't ask other users' agents for secrets.
Restrict secrets request to agents owned by the user that made the
initial activate or GetSecrets request.
Automatic activations still request secrets from any available agent.
A client calling GetSecrets on the connection should also request
secrets from agents in that client's session. ie, a connection
editor should be able to call GetSecrets, and get the secrets
stored by the agent in that session (the applet).
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.
Heavily modify Inaky's Intel WiMAX SDK glue (originally from connman)
to be more generic and more thread-safe, and suitable for use with
NetworkManager instead of rolling our own client code. Rewrite the
NMDeviceWimax code to mostly work.
Still to be done: actual connection logic, DHCP handling, spawning
wimaxd if it's not started yet
We're just going to quit here anyway, so we don't need to
make sure the property filter is unregistered. Fixes a
crash on exit if D-Bus has quit before NM has.
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
Don't bother trying to initialize the user settings proxy when it
isn't even active. Would trigger a warning to syslog if PolicyKit
permissions changed via changes to /usr/share/polkit-1/actions/.
By the time we get the udev device removal notification we may not
be able to read properties, since the device has already been
removed from sysfs. That means we can't get the ifindex, so we need
to fall back to the interface name. But we always want to prefer
the ifindex since that will never change as long as the device is
connected, unlike the interface name.
This patch updates timestamps in system connections. The update occurs on
connection activation and then periodically every 5 mins while the connection
is active. It only works for plugins having write support and for writable
connections (not read-only).
NMSysconfigSettings has the authoritative list of connections, no reason
to duplicate all that tracking code in NMManager. Add the missing bits
that the manager had to NMSysconfigSettings, and point NMPolicy at the
settings object instead of NMManager for that.
Everyone uses pm-utils still for sleep/wake support, and that's
traditionally how NM was put to sleep and woken up. But pm-utils
uses dbus-send without --print-reply so dbus-send quits immediately
after sending the message. That doesn't give NM enough time to
get the senders UID and thus validate the request, so the request
gets denied, and sometimes NM stays asleep after the machine is
woken up.
Instead, don't get the sender's UID and try to authorize it, but
just let the request go through. Rely on D-Bus permissions to
make sure that only root can call sleep/wake methods.
G_SLICE debugging uncovered a use-after-free when freeing the
batched user connection settings callback list. We don't
actually care about the DBusPendingCalls anyway, so just make
the list a counter and simplify the code in the process.
Previously the "Enable Wireless" state was somewhat tied to rfkill state,
in that when NM started up, rfkill state would take precedence over what
was listed in the state file, and if you rmmodded your wifi driver and
then modprobed it again after disabling wifi from the menu, wifi would
magically become re-enabled becuase rfkill state changed.
Fix that by creating a third wifi/wwan enable state that tracks the
actual user preference instead of just the rfkill state so that when
the user disables wifi it stays disabled, regardless of what happens
with rfkill.
This means you don't need pm-utils anymore, and that gnome-power-manager
doesn't need to poke NM explicitly for suspend/resume operations.
The old explicit sleep/wake request is still around for pm-utils or
gpm to use, but NM will listen for UPower events and act on them
regardless of what pm-utils or gpm do.
While it may not reduce the LOC it saves a few memory allocations
and is somewhat less error prone since callers don't need to free
the returned lists.
Moves the system settings permissions checking into the core service's
permissions checking, which at the same time enables 3-way permission
reporting (yes, no, auth) instead of the old yes/no that we had for
system settings permissions before. This allows UI to show a lock
icon or such when the user could authenticate to gain the permission.
It also moves the wifi-create permissions' namespace to the main
namespace (not .settings) since they really should be checked before
starting a shared wifi connection, rather than having anything to do
with the settings service.
Since these were properties they are harder to validate the caller as
dbus-glib doesn't have any hooks before the property is set. So we
install a low-level dbus filter function to catch property Set
requests before they get to dbus-glib and handle the property access
there.
When NM quits, we don't want to unmanage a device that has
an active connection and can take that connection over again when
NM starts back up. This makes '/etc/init.d/NetworkManager restart'
work seamlessly. All other devices get unmanaged so their
connection (and any dependent VPN connections or wpa_supplicant
processes) get terminated. This bug caused active VPN connections
over wifi to be left running even when they didn't have IP
connectivity.
There were two bugs:
1) the NMDevice class implemented connection_match_config() for
all device subclasses, but only Ethernet devices can assume
connections at startup. Thus the quit-time check passed for
active wifi devices too, and they weren't properly cleaned up
2) The logic for figuring out which devices to clean up after when
quitting was somewhat flawed; we want to default to unmanaging
devices and then skip that step for ones that meet specific
criteria. Instead the code defaulted to leaving all devices active
at shutdown.
NMSysconfigSettings inherited the "bus" property from NMSettingsService.
The property was originally created to allow us to specify what DBus
connection to use, which was important in the days of user settings
services. Now, however, the daemon is the only thing that has a settings
service, and so we can trim a bit of clutter by removing this property
and using NMDBusManager directly.
