NM_STATE_CONNECTED_SITE doesn't distinguish between "behind a captive
portal" and "limited network connectivity" (ie, connected to a router
that has lost its upstream connection). Add a new NMManager
:connectivity property to provide this information.
Also add a CheckConnectivity method, which can be used to force NM to
re-check the connectivity state, which could be called by a client
after it completed a portal login, or fixed a network problem.
Add a property on NMManager indicating that it is currently starting
up and activating startup-time/boot-time network connections.
"startup" is initially TRUE, and becomes FALSE once all NMDevices
report that they have no pending activity (eg, trying to activate,
waiting for a wifi scan to complete, etc). This is tracked via a new
NMDevice:has-pending-activity property, which is maintained partially
by the device itself, and partially by other parts of the code.
If all agents can handle VPN hints, then we'll try to use
ConnectInteractive() to let the VPN plugin ask for secrets
interactively via the SecretsRequired signal. These hints
are then passed to agents during the connection process if
the plugin needs more secrets or different secrets, and when
the new secrets are returned, they are passed back to the VPN
plugin.
If at least one agent does not have the VPN hints capability,
we can't use ConnectInteractive(), but fall back to the old
Connect call, because that agent won't be able to send the
hints to the VPN plugin's authentication dialog, and thus
we won't get back the secrets the VPN plugin is looking for.
So, for interactive secrets to work correctly, you need:
1) A VPN plugin updated for interactive secrets requests
2) NM updated for interactive secrets requests
3) all agents to set the VPN_HINTS capability when
registering with NetworkManager and to pass hints
along to the VPN authentication dialog
4) a VPN authentication dialog updated to look for hints
and only return secrets corresponding to the hints
requested by the plugin
There are three additions to the D-Bus interface for VPN plugins as
part of this patch:
1) ConnectInteractive(): called by NM instead of Connect() to let
the plugin know that it can request additional secrets during the
connection process using SecretsRequired
2) SecretsRequired: a new signal emitted by the plugin to indicate
to NetworkManager that additional secrets are required to connect;
can only be called if NetworkManager initiated the connection by
calling the ConnectInteractive() method
3) NewSecrets(): a new method of the plugin that NetworkManager calls
when new secrets requested by the SecretsRequired signal have been
retrieved from secret agents
We need new methods because agents need to be aware of the hints that
the VPN plugins may send with the SecretsRequired signal (detailing
the specific secrets that are required) and at this time, not all
agents support passing those hints to the VPN plugin authentication
dialogs.
Add a "monitor-connection-files" config option, which can be set to
"false" to disable automatic reloading of connections on file change.
To go with this, add a new ReloadConnections method on
o.fd.NM.Settings that can be used to manually reload connections, and
add an nm-cli command to call it.
This requires a very recent kernel to even compile, and the kernel
code is still rapidly changing (eg, adding IPv6 support). So take it
out for now, until it stabilizes.
This reverts commit 7f0f04d106.
We don't always want to immediately write new connections to disk, to
facilitate "runtime" or "temporary" connections where an interface's
runtime config isn't backed by on-disk config. Also, just because
an interface's configuration is changed doesn't necessarily mean
that new configuration should be written to disk either.
Add D-Bus methods for adding new connections and for updating existing
connections that don't immediately save the connection to disk.
Also add infrastructure to indicate to plugins that the new connection
shouldn't be immediately saved if the connection was added with the
new method.
Use the new NMConnection 'changed' signal to mark connections
as dirty/unsaved, and reset that when they get flushed to disk.
Previously, the 'Updated' signal was emitted only when the
connection was changed and flushed to disk, but now we have
more granular needs, and the signal is emitted whenever the
connection actually *is* changed, regardless of whether its
flushed to disk or not.
Add NMDeviceGeneric, to provide generic support for unknown device
types, and create NMDeviceGenerics for those devices that NM
previously was ignoring. Allow NMSettingGeneric connections to be
activated on (managed) NMDeviceGenerics.
Agents are expected to save any new/updated secrets returned to
NetworkManager from a GetSecrets call, as it would be silly to return
those same secrets right back to the agent via SaveSecrets when the
agent is perfectly capable of saving the secrets itself without
round-tripping to NetworkManager and back.
Some wireless devices don't support Ad-Hoc mode. Expose this fact in
the wireless capabilities so that clients can disable the hot-spot
option if neither CAP_ADHOC nor CAP_AP is available.
https://bugzilla.gnome.org/show_bug.cgi?id=692869
This reverts commit 2ad6dcf215.
org.freedesktop.NetworkManager.PPP is a private interface between
NM and nm-ppp-plugin and we don't want it in the documentation.
A new value for NM80211Mode is introduced (NM_802_11_MODE_AP) and the
new mode is passed to wpa_supplicant analogous to adhoc-mode.
The places which need to know the interface mode have been extended to
handle the new mode.
If the configuration does not contain a fixed frequency, a channel is
selected the same way as with adhoc-mode before.
When the supplicant starts connecting, or gets disconnected, track
whether it ever starts talking to an AP. Then if the connection fails
as a result of an initial connection timeout or a link timeout, we
can use SSID_NOT_FOUND when we're reasonably sure the AP doesn't
exist. Clients can use this to show better error messages.
Note that SSID_NOT_FOUND may only be reported when using nl80211
drivers, as WEXT drivers don't provide the status necessary to
determine whether the network exists or not.
Implements a new property that provides a list of currently
available connections a device could connect to. For example
if a connection for a particular wireless connection exists and
that wireless network appears in the scan list it would show in the
AvailableConnections property of the device.
(dcbw: found a slightly cleaner way to do this; it's a lot like the
check_connection_compatible class method, except it deals with
live network data too. So convert the subclass methods to
just check additional live network data, and have the base
device class handle adding the connection to the hash and all
the associated signalling. Also fix a bug where the available
connections were not updated when a device moved from UNAVAILABLE
to available, its available connections were not updated)
Allows agents to provide different behavior depending on whether the
secrets request was initiated by a user (eg by picking a connection
from a UI menu or by 'nmcli con up') or was automatically started by
NetworkManager.
See https://bugzilla.gnome.org/show_bug.cgi?id=660293
The info is extracted via SIOCETHTOOL ioctl() syscall using ETHTOOL_GDRVINFO.
This works for most drivers but not all, e.g. for modems. We may figure out how
to get the info for specific devices, and enhance the solution by implementing
specific functions for particular device types later.
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
It is bound to autoconnect_inhibit private variable (has opposite meaning).
While 'Autoconnect' is TRUE (default value) the device can automatically
activate a connection. If it is changed to FALSE, the device will not
auto-activate until 'Autoconnect' is TRUE again.
Disconnect() method sets 'Autoconnect' to FALSE. NMPolicy monitors the property
and schedules auto activation when FALSE->TRUE transition is made.
This patch adds the settings code (NMSettingAdsl) and the initial
"scaffolding" i.e., a tiny stub version of NMDeviceAdsl and the
udev handler code to get the device detected.
With this patch you should be able to see an atm device being detected
by networkmanager in the logs, although of course it doesn't
do anything useful yet.
Extract from the logs:
[1304668252.341354] [nm-udev-manager.c:562] adsl_add(): adsl_add: ATM Device detected from udev. Adding ..
(ueagle-atm0): failed to look up interface index
(ueagle-atm0): new ADSL device (driver: 'ueagle-atm' ifindex: -1)
(ueagle-atm0): exported as /org/freedesktop/NetworkManager/Devices/2
(ueagle-atm0): now managed
(ueagle-atm0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
(ueagle-atm0): deactivating device (reason: 2).
[1304668252.345102] [nm-system.c:1349] flush_routes(): (ueagle-atm0) failed to lookup interface index
[1304668252.347821] [nm-device.c:3912] nm_device_state_changed(): (ueagle-atm0): device is available,
In this version, we hack the nm-device.c:nm_device_get_priority() to get better priority
instead of changing the DeviceType enum.
Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com>
