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>
"InfiniBand" has a capital "B". Fix that everywhere it's being used as
a human-readable string.
In particular, the RH initscripts recognize "TYPE=infiniband" and
"TYPE=InfiniBand", but not "TYPE=Infiniband", which is what we were
writing before.
We already have the master device kept in the active connection, so
we can just use that instead of having the Policy determine and set
it manually. This also should allow slaves to auto-activate their
master connections if the master is able to activate.
Many different interface types can support VLANs, including
Infiniband, WiFi, etc. So we have to create a new device class
for them instead of keeping the support in NMDeviceEthernet.
Allows clients to retrieve the reason a device changed to
the given state along with the state itself, preventing
race conditions if the state were retrieved separately
from the reason. Reason codes were not previously
accessible without listening to the StateChanged signal.
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>
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.
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.
At some point we'll be passing other info like whether we need
the 802.1x identity too, or unknown CA certificate data for the
Agent to accept, etc. Basically state that instead of only
hints from the setting, we can pass other stuff as well.
These days more and more devices are showing up that support a
number of different access technology families in the same hardware,
like Qualcomm Gobi (CDMA and GSM), Pantech UM190 (CDMA and GSM),
Pantech UML290 (CDMA and LTE), LG VL600 (CDMA and LTE), Sierra
320U (GSM and LTE), etc. The previous scheme of having device
classes based on access technology family simply cannot handle
this hardware and attempting to add LTE to both the CDMA and GSM
device classes would result in a bunch of code duplication that
we don't want. There's a better way...
Instead, combine both CDMA and GSM device classes into a generic
"Modem" device class that provides capabilities indicating what
access technology families a modem supports, and what families
it supports immediately without a firmware reload. (Gobi devices
for example require a firmware reload before they can switch
between GSM and CDMA). This provides the necessary flexibility
to the client and allows us to keep the API stable when the
same consolidation change is made in ModemManager.
The current code doesn't yet allow multi-mode operation internally,
but the API is now what we want it to be and won't need to be
changed.
Will be used for things like activating a VPN connection before
signaling that the device is activated, or maybe for bridges and
bonds, to ensure that applications don't think the system has
connectivity before everything is set up.
DISCONNECTING: the only active network connection is now being disconnected
LOCAL, SITE, GLOBAL: one-stop items for level of connectivity, which
we'll use to show when we think we're actually connected to the internet
or behind a captive portal or something
sleep, wake, StateChange, all deprecated in 0.8, are now removed.
sleep & wake are replaced with the Sleep() method, while
StateChange is replaced with the StateChanged signal which has
the same arguments.
We'll use IP_CHECK for detecting whether we're behind a captive
portal or on a network that does not have access to the Internet.
We'll probably run some variety of plugins during this stage to
help detect this, and possibly handle it for us (auto-login to
captive portal for example).
DEACTIVATING will be used for tearing down network shares or
cleanly closing network sessions when we're able to clean up
an activation. ie, "pre-down" for Debian.
If we can authenticate the agent for 'modify' permission, then send
any existing system secrets to it as the user has permission to change
those secrets. This means the agent doesn't have to call GetSecrets()
itself, which means simpler code on the agent side for a slight LoC
hit in NM itself.
This also moves the permissions checking into the NMAgentManager to
check each agent, which is sub-optimal since now the agent manager
has to do PolicyKit stuff, but hey that's life. Agents need secrets,
and we do need to authenticate every agent before we send secrets to
them, and the NMSettingsConnection doesn't know about individual
agents at all.
The Settings.Connection interface is now only provided by NetworkManager
itself since there is only one settings service. NM can validate
requests for secrets internally and thus there's no need to lock down
GetSecrets using a separate D-Bus interface, since PolicyKit provides
that functionality on systems where this is desirable (ie multi-user).
Single-user systems that do not have PolicyKit will inherently trust
the user already, or if not D-Bus auth is flexible enough to lock
down the GetSecrets method individually even if it's not on a separate
D-Bus interface.
Second, since only clients like connection editors or applets will be
calling the GetSecrets method, there's no need for 'hints' or
'request_new' arguments here since this method should never trigger
an interactive secrets request. Only NM should send those requests
when it knows it needs to ask the user, either during connection or
after validating the incoming GetSecrets request. A connection editor
type application should never be able to trigger the normal
"What's your passphrase" dialog thats provided by the secret agent
for that user's session.
