summaryrefslogtreecommitdiff
path: root/introspection
Commit message (Collapse)AuthorAgeFilesLines
* libnm-core, libnm, core: add AddressData and RouteData propertiesDan Winship2014-11-072-13/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | 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'.
* core: autoconnect fixes for default-unmanaged devices and property notificationDan Williams2014-10-271-1/+2
| | | | | | | | | | | | | | | | | 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.
* core: add PrimaryConnectionType property to NMManager (bgo #739080)Ryan Lortie2014-10-231-0/+8
| | | | | | | | | | | | | | | | | | | | 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
* libnm-core, core: move NMManagerError to nm-errorsDan Winship2014-10-221-17/+0
| | | | | | | | | | | | | | | | | 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.
* logging: add new logging level "TRACE"Thomas Haller2014-10-051-2/+2
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: add ClearSecrets() D-Bus callJiří Klimeš2014-09-261-0/+8
| | | | It clears all secrets in a connection.
* libnm: port to GDBusDan Winship2014-09-187-0/+99
| | | | | | | | | 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).
* trivial: alphabetize the nm-*.xml files in introspection/Makefile.amDan Winship2014-09-051-22/+21
|
* ppp: add IPv6 supportDan Williams2014-07-231-0/+5
| | | | | | 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.
* device: add a new D-Bus 'Delete' method for removing software devicesJiří Klimeš2014-07-221-0/+9
|
* introspection: fix VPN.Plugin State typeDan Winship2014-07-151-2/+40
| | | | | It was listed as being tp:type="NM_VPN_CONNECTION_STATE", but it's actually NM_VPN_SERVICE_STATE (which wasn't previously documented).
* doc: update documentation to show all logging domainsThomas Haller2014-05-121-5/+6
| | | | | | Also, mention the deprecated alias HW in man/NetworkManager.conf Signed-off-by: Thomas Haller <thaller@redhat.com>
* wwan: disable autoconnect if the given SIM PIN was wrongDan Williams2014-05-061-0/+5
| | | | | | | | | | 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)
* wwan: use modem states instead of enabled/connected propertiesDan Williams2014-05-061-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* introspection: fix Device.Ip4Address typeDan Winship2014-04-251-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=720963
* fix typos in documentation and messagesYuri Chornoivan2014-04-031-1/+1
| | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=727031 Signed-off-by: Thomas Haller <thaller@redhat.com>
* platform, devices: add support for vxlan devicesDan Winship2014-03-062-0/+123
| | | | | | 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.
* core: add 'type' and 'id' property for NMActiveConnection (rh #1061822)Jiří Klimeš2014-03-051-0/+12
| | | | https://bugzilla.redhat.com/show_bug.cgi?id=1061822
* introspection: add PropertiesChanged signal for o.f.N.Settings.ConnectionJiří Klimeš2014-01-271-0/+8
| | | | | Some users, e.g. libnm-glib's NMRemoteConnection, use it to get changes of properties.
* api/settings: expose the ConnectionRemoved signalDan Williams2014-01-232-2/+18
| | | | Helps out bindings.
* api/wimax: add Nsps (Network Service Providers) propertyDan Williams2014-01-231-0/+7
| | | | Helps out bindings.
* api/settings: add Connections propertyDan Williams2014-01-231-0/+6
| | | | Helps out bindings.
* api/wifi: add GetAllAccessPoints() methodDan Williams2014-01-231-2/+18
| | | | | | | 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.
* api/wifi: add AccessPoints propertyDan Williams2014-01-231-0/+8
| | | | Helps other bindings.
* api/core: add Devices property to the ManagerDan Williams2014-01-231-0/+6
|
* core: enforce permissions for SetLoggingDan Williams2014-01-231-0/+1
| | | | | This was always protected by D-Bus policy permissions, but just to be paranoid, ensure it's also protected by explicit checks on the UID.
* settings: return error from GetConnectionByUuid() if caller not in ACLDan Williams2014-01-231-0/+1
| | | | | | | 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.
* core: add PropertiesChanged signals to IP4 and IP6 config objectsDan Williams2014-01-232-0/+16
| | | | | | | | 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)
* logging: allow per-domain log level overridesDan Winship2013-12-201-2/+5
| | | | | Allow specifying log domains like "DEFAULT,WIFI:DEBUG" to override the log level on a per-domain basis.
* device: add 'mtu' propertyJiří Klimeš2013-12-201-0/+5
|
* core: add IP/DHCP config properties to o.fd.NM.Connection.ActiveDan Winship2013-12-191-0/+30
| | | | | | | | | 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.
* introspection: wrap long lines in nm-active-connection.xmlDan Winship2013-12-191-7/+24
|
* introspection: add missing GENERIC and TEAM device types to nm-device.xmlJiří Klimeš2013-12-161-0/+10
|
* Revert "core: add Devices property to Manager"Dan Williams2013-11-251-6/+0
| | | | | | | This reverts commit c1768154c4cfdc394cd175396157e5e4c48359af. Not supposed to be committed yet, see dcbw/dbus-properties for the real patch.
* core: add Devices property to ManagerDan Williams2013-11-251-0/+6
| | | | Helps other bindings.
* core: add o.fd.NM.Settings.LoadConnectionsDan Winship2013-11-151-0/+34
| | | | | | | Add a D-Bus method to reload connection files specified by filename, and implement it in the ifcfg-rh and keyfile backends. https://bugzilla.gnome.org/show_bug.cgi?id=709830
* core: implement update_connection() for TeamDan Williams2013-11-081-0/+5
|
* docs: update for Team and Generic devicesDan Williams2013-11-071-0/+2
|
* core: improve handling of NPAR/SR-IOV devices (rh #804527)Dan Winship2013-11-061-0/+8
| | | | | | 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.
* core: extend ActivateConnection to allow NULL connection pathsDan Williams2013-10-311-3/+8
| | | | | | | | | 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.
* core: set up and tear down DCB/FCoE when DCB is enabledDan Williams2013-10-311-0/+5
|
* vpn: fix VPN plugin D-Bus errorsJiří Klimeš2013-09-271-9/+31
| | | | | | | 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.
* vpn: fix connecting to VPN (bgo #708255)Jiří Klimeš2013-09-272-0/+8
| | | | | | | | | | | | | | 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
* api: clarify lifetime and behavior of ActiveConnection's SpecificObject ↵Dan Williams2013-09-261-1/+5
| | | | | | | | | property (rh #1012309) 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.
* core: update existing IP[46]Config of device instead of replacing it (bgo ↵Thomas Haller2013-09-252-11/+23
| | | | | | | | | | | | | | | | | | | | | | | #707617) 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>
* core: add NMManager:primary-connection and :activating-connectionDan Winship2013-08-281-0/+19
| | | | | | | | | | 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
* core: provide additional network connectivity informationDan Winship2013-08-281-0/+53
| | | | | | | | | | | 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.
* core: add NMManager:startup propertyDan Winship2013-08-161-0/+8
| | | | | | | | | | | 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.
* core: add support for team deviceJiri Pirko2013-08-152-0/+35
| | | | Signed-off-by: Jiri Pirko <jiri@resnulli.us>
* vpn: handle interactive plugin secrets requestsDan Williams2013-07-311-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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
View Lorry Controller Status