Enables easier traversal of the object hierarchy; if a client is
watching signals on a device they can easily get back to the
parent NMActiveConnection object to grab connection details or
status.
Here's the problem:
- NM requests secrets
- secret agent returns secrets including some that are agent-owned or
not-saved (ie, transient secrets)
- for whatever reason (other secrets are system-owned, whatever) the
connection gets written back out to disk
- at some point later inotify triggers a connection re-read from disk
- the connection is read from disk, but doesn't contain the agent-owned
or not-saved secrets, because they obviously don't get saved
- nm_settings_connection_replace_and_commit() blows away the agent-owned
or not-saved secrets that the agent originally returned
- device activation no longer has the transient secrets
Re-reading connection data from disk shouldn't change transient secrets;
instead we need to merge the just-read system-owned secrets with whatever
transient secrets an agent sent. Transient secrets should only be cleared
by nm_connection_clear_secrets() to ensure that they stick around for as
long as we need them.
This used to only happen for user-created APs, but the supplicant
always wants a frequency no matter what, and the kernel drivers will
normally merge with any other IBSS with the same SSID no matter what
frequency is used, so we might as well just pass something since
it doesn't really matter in the end anyway.
As a bonus we get to remove the user_created stuff since it doesn't
really matter much anymore.
Commit e083cd5c63 stopped openconnect from
saving its secrets. It'd been working for a whole three minutes since my
previous commit.
We need to have at least one secret with an *extant* flags setting of
NM_SETTING_SECRET_FLAG_NONE, in order to trigger a write-out of the new
set of secrets. And we might as well list all the secrets we *know* the
auth-dialog is going to use, although we know there will be some secrets
that we cannot predict in advance (the form entry boxes).
All non-VPN secrets are considered system-owned if they do not
have any explicitly set secret flags, and this makes VPN secrets
treated the same way. As part of the import process plugins and
the applet already update secret flags. This ensures that VPN
secrets are treated consistently throughout the codebase.
Retries counter was not initialized when connections were loaded. That forced
the counter to start from -1 and continue decreasing on connection failures.
And connection attempts never stopped.
Instead of just with the old environment variable. This means we'll
log pppd debug output when the log level is changed via the D-Bus
interface now too.
Previously a secret marked NOT_SAVED or NOT_REQUIRED would be
treated as a system secret when checking returned secrets. That's
incorrect since unsaved or not required secrets aren't stored
by system settings.
Evil hack; but the problem is that before this commit anyone who
migrated connections wouldn't have the right secrets flag set in
their openconnect connections. Figuring out some way of updating
those connections now is harder and we don't want people to have
to go through the delete-connection-file-change-applet-stamp-rerun
dance. So we'll live with this for now...
Use one global PolkitAuthority object; we only really need to use it
in one place anyway. So consolidate the code that uses polkit into
nm-manager-auth.c.
If there's no SSID, we can't connect at all. So if a client passes
in a hidden AP, and doesn't send the SSID in the partial connection
info, we can't make a connection with it. Return an error instead
of crashing.
This reverts commit 2b12825faa.
Fixes the problem, but the real issue was clients passing AP objects
that don't have an SSID; we need to reject connection creation
requests where the SSID can't be found.
A network with hidden SSID can appear in gnome-shell indicator applet as
<unknown> entry. Clicking it can make NM crash if there is no SSID in wireless
setting nor in AP.
When removing all NSPs in the scan list clearly we should be clearing
out the current NSP as well, since it just got removed from the scan
list. And make sure the current NSP is cleared when activation fails
or when the device becomes disconnected, since it's not connected to
anything and thus can't have a current NSP either.
The current NSP should only be set during the activation attempt and
while the device is connected.
The WiMAX SDK will reject connect requests while the device is scanning,
which happens when right after suspend or when the wimax radio is
turned on. Postpone the connect attempt until the device says it's
not scanning anymore instead of having the connect attempt fail
and be retried.
For VPN connections, the interface name would be that of the VPN's
IP interface, but the script environment would be the that of the
VPN's parent device. Enhance the environment by adding any VPN
specific details as additional environment variables prefixed by
"VPN_". Leave the existing environment setup intact for backwards
compatiblity.
Additionally, the dispatcher never got updated for IPv6 support,
so push IPv6 configuration and DHCPv6 configuration into the
environment too.
Even better, push everything the dispatcher needs to it instead
of making the dispatcher make D-Bus requests back to NM, which
sometimes fails if NM has already torn down the device or the
connection which the device was using.
And add some testcases to ensure that we don't break backwards compat,
the testcases here were grabbed from a 0.8.4 machine with a hacked up
dispatcher to dump everything it was given from NM.
Enable the supplicant's optimized background scanning functionality
for WPA Enterprise setups so that roaming works correctly. Otherwise
there are issues pingponging between APs and having an up-to-date
scan list for roaming, since NM only scans every 2 minutes. The
supplicant can trigger optimized scans based on signal quality
thresholds and such and make these roaming decisions much better
than NM can.
This commit changes rfkill state handling slightly in the following
ways:
- when checking whether a user toggle request can change radio state,
ignore states we can change in radio_enabled_for_rstate() as a result
of the toggle; this fixes WiMAX enable/disable because a softblock
can be changed by telling wimaxd to enable the radio. As a side-effect
this also fixes handling of WiFi when altering the rfkill state as well.
- make WiFi user toggle requests change wifi killswitch state; this has
been long requested and on the TODO list for a while and it turns out
to be a lot easier to do these days. This provides the expected
behavior when disabling wireless from user agent menus since there's
not an easy way to do this other than dropping to shell and running
rfkill.
Allow clients to get a device by its IP interface name instead
of having to get the device list and iterate through each one,
and read the interface name to get what they want.
If the client knows the UUID, add a convenience function to get
the connection path directly, instead of having to iterate the
whole connection list and get each connection's details and then
check the UUID.
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.
The signal was emitted in case the removed connection was managed instead of
for unmanaged connection. Thus the signal had no effect.
That caused incorrect behaviour in case of changing NM_CONTROLLED=no to yes.
That didn't enable the device; only after the file was changed for the second time.
Make sure the dispose won't run twice for the same code and
make sure we never schedule a handler for monitor_cb() more
than once, though it's really hard to see how that could ever
happen anyway.
Another attempt to blindly fix lp:752143
While this should never happen while the PPP manager is alive, modems
can switch their IP method while alive, since the net port is sometimes
discovered after the serial ports have been. This happens for some
devices that have separate drivers for the net and serial sides, like
ZTE Icera-based devices (cdc-ether and cdc-acm) and newer Sierra
devices (sierra and sierra-net). Just be paranoid here and ensure
that the PPP manager gets cleaned up.
Partial attempt at fixing lp:752143
