The device may not be created yet (in the case of software devices)
when the ActiveConnection is created; in that case we still want to
proceed with authorization for the connection, but we'll create the
device when authorization is complete.
Both NMActRequest and NMVPNConnection need to track their device's state,
so instead of both subclasses having to do so, consolidate that code into
the superclass.
Add a 'master-ready' property to NMActiveConnection that NMDevice can
watch for to indicate that the master connection/device is ready to accept
slaves. Since the slave device's ActiveConnection is already tracking
its master connection, and since ActiveConnections don't enter the
ACTIVATING state until their device is ready for slaves, it's pretty
trivial to implement this property.
We need to track the master active connection, since it may require authentication
or other operations to complete before the device actually starts activating.
We want to create the object earlier now, and figuring out the master is
a lot of code that we don't want to run before creating the object. The
master still must be set before exporting the object over D-Bus though,
as before.
Whether an active connection is assumed or connected from scratch is
only important during nm_device_activate(). When the activation process
is set up, there's no difference from any other active connection.
Acked-by: Dan Winship <danw@gnome.org>
Acked-by: Thomas Haller <thaller@redhat.com>
Change the way that nm-properties-changed-signal works, and parse the
dbus-binding-tool-generated info to get the exact list of properties
that it's expected to export.
This makes NM_PROPERTY_PARAM_NO_EXPORT unnecessary, and also fixes the
problem of properties like NMDevice:hw-address being exported on
classes where it shouldn't be.
We'll want to use NMActiveConnection more in the manager and also fold
the PendingActivation functionality into it. All this functionality
applies to the VPN connections too, so it makes sense to have it all
in the base class instead of both NMActRequest and NMVPNConnection.
Track a master active connection and emit wait/ready/fail when
it changes state. This signal is intended for devices to
delay their activation until a master device is ready.
That was always the goal, but never got there. This time we need it
for real to abstract handling of dependent connections so bite the
bullet and make it happen.
Adds a new "master" property to NMActiveConnection containing the path
of the master NMDevice if the connection has a master.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
A convenience so that clients which might key certain operations off
which connections are active (checking work mail only when on VPN for
example) can more easily get which connections are active. This would
allow those apps to store the UUID (which they would already be doing)
and not have to create a Connection proxy and then get the connection
properties just to retrieve the UUID of the connection. Instead they
can now get it from GetAll of the ActiveConnection object, which they
would already be doing.
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.
Remove all references to connection scope and user-settings services
from the various internal APIs of the daemon. The external DBus API
remains unchanged, albeit in stub form for scope stuff.
* introspection/nm-active-connection.xml
introspection/nm-vpn-connection.xml
libnm-glib/nm-active-connection.c
src/nm-activation-request.c
src/nm-active-connection.h
src/vpn-manager/nm-vpn-connection.c
- Remove "SharedServiceName" and "SharedConnection" bits from the D-Bus
and libnm-glib API since sharing didn't get implemented that way
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3797 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
* include/NetworkManager.h
- Add NMActiveConnectionState enum
* introspection/nm-active-connection.xml
introspection/nm-vpn-connection.xml
- Add 'State' property for overall active connection state
- Add 'Default' property, when True means this active connection
has the default route
- Add PropertyChanged signals so changes actually go out over the bus
* src/nm-active-connection.h
- Add defines for State & Default properties
* src/nm-activation-request.c
- Add 'state' and 'default' properties, hook up to device 'state-changed'
signal to determine active connection state
* src/vpn-manager/nm-vpn-connection.c
src/vpn-manager/nm-vpn-connection.h
src/vpn-manager/nm-vpn-manager.c
src/vpn-manager/nm-vpn-service.c
- Rename old 'state' to 'vpn-state'
- Rename nm_vpn_connection_get_state() -> nm_vpn_connection_get_vpn_state()
- Add 'state' and 'default' properties, hook up to the vpn connection's
'vpn-state-changed' signal
* libnm-glib/nm-active-connection.c
libnm-glib/nm-active-connection.h
- Add new 'state' and 'default' properties and accessors
* libnm-glib/nm-vpn-connection.c
libnm-glib/nm-vpn-connection.h
- Rename old 'state' property to 'vpn-state'
- Add new 'state' and 'default' properties and accessors
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3582 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
Rework VPN connection handling for a more consistent D-Bus API. The
VPNManager object has been removed, and active VPN connections are now the
same as any other active connection. The Manager object's ActivateConnection
and DeactivateConnection methods are used to start and stop a VPN connection,
and the VPNConnection objects are subclasses of the ActiveConnection objects.
When activating a VPN connection, pass the path of the active connection
to which the VPN connection is tied in the 'specific_object' argument.
Consequently, the libnm-glib API has been reworked to match this arrangement,
with the VPNManager object removed, and the NMVPNConnection objects now
being subclasses of NMActiveConnection.
git-svn-id: http://svn-archive.gnome.org/svn/NetworkManager/trunk@3504 4912f4e0-d625-0410-9fb7-b9a5a253dbdc
