We only use IPV6_DEFAULTGW at the moment. That means we just support the
gateway for the first IPv6 address/subnet. That should be changed later
after we figure out what variables should be used.
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.
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
The restart() function almost never works here - perhaps some part
of NM takes a bit too long to stop() and then blocks the start()
operation - but "sleep 2" between them makes everything fine.
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.
