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.
Only fail an activated device if it's actually activated, and
only fail an activating device if the timeout triggers or if
the connect callback indicates failure, not based on device state.
The SDK internally use wchar_t for NSP names even though the
names are actually UTF-8 (since the driver uses UTF-8/ASCII). So
work around that by using the full network name buffer in case
the NSP name is an odd number of characters and thus widechar
comparison functions like wcscmp() would fail when given ASCII.
