Add AddressData and RouteData properties to NMSettingIPConfig and
NMIP[46]Config. These are like the existing "addresses" and "routes"
properties, but using strings and containing additional attributes,
like NMIPAddress and NMIPRoute.
This only affects the D-Bus representations; there are no API changes
to NMSettingIP{,4,6}Config or NMIP{4,6}Config as a result of this; the
additional information is just added to the existing 'addresses' and
'routes' properties.
NMSettingIP4Config and NMSettingIP6Config now always generate both
old-style data ('addresses', 'address-labels', 'routes') and new-style
data ('address-data', 'gateway', 'route-data') when serializing to
D-Bus, for backward compatibility. When deserializing, they will fill
in the 'addresses' and 'routes' properties from the new-style data if
it is present (ignoring the old-style data), or from the old-style
data if the new-style isn't present.
The daemon-side NMIP4Config and NMIP6Config always emit changes for
both 'Addresses'/'Routes' and 'AddressData'/'RouteData'. The
libnm-side classes initially listen for changes on both properties,
but start ignoring the 'Addresses' and 'Routes' properties once they
know the daemon is also providing 'AddressData' and 'RouteData'.
Previously the only thing preventing default-unmanaged devices from
being auto-activated was luck and the fact that they didn't have any
available connections when in the UNMANAGED state. That's no longer
true, so we must be more explicit about their behavior.
Furthermore it makes no sense to allow default-unmanaged devices
to set priv->autoconnect=TRUE since that is never supposed to
happen, so enforce that both in NM itself and if the change
request comes in over the D-Bus interface.
Lastly, internal priv->autoconnect=TRUE changes never emitted a
property change notification, meaning the NMPolicy would never
schedule an autoconnect check if the device's priv->autoconnect
was set to TRUE as a result of re-activating or waking from sleep.
This will provide an extremely easy way for applications to find out
what type of connection the system is currently using. They might want
to do this to avoid using data if a phone is on a 3G connection, for
example.
Having this as a separate property provides at least two advantages:
1) it reduces code complexity for those wanting only this one simple
piece of information
2) we could allow access to this property (but nothing else) to
privilege-separated applications in the future
This patch adds the missing nm_active_connection_get_connection_type()
which was in the header file but never actually implemented.
https://bugzilla.gnome.org/show_bug.cgi?id=739080
Move the definition of NMManagerError to nm-errors, register it with
D-Bus, and verify in the tests that it maps correctly.
NM_MANAGER_ERROR_INTERNAL gets renamed to NM_MANAGER_ERROR_FAILED for
consistency. NM_MANAGER_ERROR_UNMANAGED_DEVICE is dropped since that
name doesn't really describe the one place it was previously used in.
NM_MANAGER_ERROR_SYSTEM_CONNECTION is dropped because it was't being
used. NM_MANAGER_ERROR_UNSUPPORTED_CONNECTION_TYPE is dropped because
it can be replaced with an NM_CONNECTION_ERROR.
NM_MANAGER_ERROR_AUTOCONNECT_NOT_ALLOWED is turned into the more
generic NM_MANAGER_ERROR_CONNECTION_NOT_AVAILABLE.
Also, remove the <tp:possible-errors> sections from nm-manager.xml,
since they were completely out of date.
Port libnm-core/libnm to GDBus.
The NetworkManager daemon continues to use dbus-glib; the
previously-added connection hash/variant conversion methods are now
moved to NetworkManagerUtils (along with a few other utilities that
are now only needed by the daemon code).
Add support for IPv6 to the pppd plugin and return the interface identifiers
to NetworkManager. Use those to construct the IPv6LL addresses for the
PPP interface and the peer.
If the given PIN was wrong, we really don't want to try that PIN
again automatically because it might lock the SIM. To ensure that
doesn't happen, disable autoconnect so that the user must manually
request reconnection.
(this doesn't fix auto-connect-with-a-wrong-PIN completely, as
autoconnect is reset when resuming from sleep, but it's a start)
Determining when the NMDeviceModem is available and when different
connections are available is easier if the modem's state is tracked,
instead of using the separate Enabled and Connected properties.
These properties could not accurately represent the SIM lock state
and prevented NetworkManager from making the modem available for
auto-activation when locked, even if a PIN was available.
In this new scheme, the NMDeviceModem is UNAVAILABLE when the
ModemManager modem state is FAILED, UNKNOWN, or INITIALIZING. It
transitions to the NM DISCONNECTED state when the modem has finished
initializing and has not failed.
Once the NMDeviceModem is in DISCONNECTED state it can be activated
even if the SIM is locked and a PIN is required; the PIN will be
requested when starting activation, either from the connection itself
or via a secrets request. This makes auto-activation of WWAN
connections possible.
This also allows us to consolidate code dealing with modem enable/disable
into the base NMModem class using the modem state, and to log more modem
information for debugging purposes.
Since vxlan is new-ish, and vxlan IPv6 support in particular has only
been in the kernel since 3.11, we include our own copy of the vxlan
netlink constants rather than depending on the installed headers.
The original GetAccessPoints() method call never returned hidden SSID
access points. That's useful though, and the new AccessPoints
property returns all of them too, so add this new method to return
all access points, including hidden SSID ones.
While this function only returns the path of the requested connection
(the actual settings are always protected), callers that aren't in
the connection's ACL still probably shouldn't get that, if only to
be pedantic.
Now that the objects get replaced when IP configuration changes
instead of being destroyed and a new one created, they need
PropertiesChanged signals.
(noticed as a result of auditing all exported D-Bus objects)
Add IP and DHCP config properties to the D-Bus ActiveConnection
objects.
For device connections, this is redundant with the properties already
on the Device object, but for VPN connections, this information was
not previously available.
Use the new kernel physical_port_id interface property to recognize
when two devices are just virtual devices sharing the same physical
port, and refuse to bond/team multiple slaves on the same port.
When called with a connection path, activates that connection.
When called without a connection path, picks the best available
connection to activate for that device.
Doesn't work with VPN connections because they don't have devices.
The errors were documented as org.freedesktop.NetworkManager.VPN.Error.*,
but the actual values were org.freedesktop.NetworkManager.VPN.Plugin.*
Also update the errors documentation.
The ConnectInteractive() -> Connect() fallback code doesn't work, because
_connect_internal() changes the state to NM_VPN_SERVICE_STATE_STARTING before
checking if it can implement ConnectInteractive(), and then when the Connect()
call comes in, the VPN is not in STOPPED or INIT, so it returns an error.
The commit moves setting state to STARTING after the ConnectInteractive() check
availability, in the plugin. We introduce new plugin error and set it when the
the plugin does not implement ConnectInteractive(). NetworkManager uses this
error for ConnectInteractive() -> Connect() fallback.
https://bugzilla.gnome.org/show_bug.cgi?id=708255
It doesn't change once it's set, and it reflects the original
specific object used during activation. It will not, for example,
switch to the currently active WiFi access point even if the
original access point that was used as the specific object disappears.
When the IP[46]Config changes, a new configuration gets assembled.
Before, whenever the new configuration was different than the current
one, the IP[46]Config of the device was completely replaced. This also
meant, that the old dbus IP[46]Config object was removed and the new one
was exported.
Now instead of recreating a new configuration, it updates the existing
(already exported) configuration in-place.
Also, add new gobject properties 'gateway' and 'searches' to the config class,
they will be exported over dbus.
Also, whenever any of the exported properties changes, make sure that a
notify signal gets emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=707617
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add properties to track the "primary" connection (ie, the active
connection with either the default route, or the route to the VPN with
the default route), and the active connection that is currently
activating, and likely to become the :primary-connection when it
completes.
https://bugzilla.gnome.org/show_bug.cgi?id=704841
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.