Simplifies code internally, and makes it easier for clients as well in
some cases where they want to control what ends up in the resulting
hash and what does not.
The Settings.Connection interface is now only provided by NetworkManager
itself since there is only one settings service. NM can validate
requests for secrets internally and thus there's no need to lock down
GetSecrets using a separate D-Bus interface, since PolicyKit provides
that functionality on systems where this is desirable (ie multi-user).
Single-user systems that do not have PolicyKit will inherently trust
the user already, or if not D-Bus auth is flexible enough to lock
down the GetSecrets method individually even if it's not on a separate
D-Bus interface.
Second, since only clients like connection editors or applets will be
calling the GetSecrets method, there's no need for 'hints' or
'request_new' arguments here since this method should never trigger
an interactive secrets request. Only NM should send those requests
when it knows it needs to ask the user, either during connection or
after validating the incoming GetSecrets request. A connection editor
type application should never be able to trigger the normal
"What's your passphrase" dialog thats provided by the secret agent
for that user's session.
Due to limitations in dbus-glib, where one GObject cannot have more
than one introspection XML object attached to it, we used to include
more than one <interface> in the VPNConnection object introspection
XML. This was suboptimal for two reasons:
1) it duplicated the Connection.Active introspection XML which
made it harder for clients to use the introspection data in a
dynamic fashion, besides looking ugly in the docs
2) not many other programs use this feature of dbus-glib, which
means it didn't get a lot of testing, and broke, which sucks
for NM.
To fix this issue, create a base class for NMVpnConnection that
handles the Connection.Active API, and make NMVpnConnection itself
handle just the VPN pieces that it layers on top. This makes
dbus-glib happy because we aren't using two <interface> blocks
in the same introspection XML, and it makes the NM code more
robust because we can re-use the existing Connection.Active
introspection XML in the NMVpnConnectionBase class.
The current agent isn't in the 'pending' list, so don't check
the list for the agent and bail if it's not found since that
won't handle the current agent going away.
If NM asks for secrets, and then a client calls ActivateDevice on
that same connection, the secrets tries counter doesn't get reset
and NM then thinks we need completely new secrets when we really
don't since the old secrets request isn't valid anymore.
Also ensure the secrets tries gets reset on success and failure
to match behavior of wifi.
If NM asks for secrets, and then a client calls ActivateDevice on
that same connection, the secrets tries counter doesn't get reset
and NM then thinks we need completely new secrets when we really
don't since the old secrets request isn't valid anymore.
Found by Evan Broder
Allows NM to signal to an agent that an in-progress secrets
request is no longer needed. This could happen if the device
for which the request was started was removed, disabled, or the
network being connected to changed, or whatever.
Since settings storage is now handled by NetworkManager, we must
have the ability to read/write all connection types at all times.
Since the 'keyfile' plugin is the only plugin that can handle all
connection types, build it into NetworkManager.
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.
System settings still links to libnm-glib, which also contains
an NMDeviceWimax class. We don't care about the libnm-glib
class, so link the wimax bits first to ensure they are the ones
used.
This issue will go away when user settings is removed in the
near future.
Otherwise it doesn't auto-scan and we get no network list. As a later
optimization, we could detect this, call iwmx_sdk_get_connected_network()
to get the current NSP, match that up with a connection, and "assume"
the connection like we do for Ethernet devices.
Otherwise it doesn't auto-scan and we get no network list. As a later
optimization, we could detect this, call iwmx_sdk_get_connected_network()
to get the current NSP, match that up with a connection, and "assume"
the connection like we do for Ethernet devices.
Sometimes the add/remove code will get re-entered by the SDK because
the SDK is stupid. Lock the code to ensure we don't double-detect
the same device.
If wimaxd gets started after NetworkManager, we need to notify
NetworkManager that the daemon has found and set up any wimax
interface it finds. Most of the code for this was there but
not previously hooked up.
