summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* core: connection live reconfiguration upon nm-platform signalsdcbw/live-reconfigPavel Šimerda2013-11-071-0/+22
|
* trivial: make nm_connection_dump more forgiving when passing NULLThomas Haller2013-11-071-1/+2
| | | | | | | | nm_connection_dump is mainly used for printf debugging, so no need about being overly critical about not accepting NULL. Just don't dump anything. Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: fix assumed active connection exporting after ff7e47a4 (core: kill ↵Dan Williams2013-11-071-0/+1
| | | | | | | PendingActivation and move authorization to NMActiveConnection) Assumed active connections never got a D-Bus path and were never exported to D-Bus.
* core: fix bridge port sysfs directory determination after f5507633 ↵Dan Williams2013-11-071-1/+1
| | | | | | | | (platform: bridging and bonding options) The device is not a slave if it *doesn't* have a master. Code previously returned an error if the slave did have a master, which is wrong.
* core: fix 'hairpin_mode' after 9e19c3db (core: use nm_platform_*_*_option() ↵Dan Williams2013-11-071-1/+1
| | | | for bridges)
* trivial: quiet log message about failing to determine virtual interface nameDan Williams2013-11-071-2/+2
| | | | | | | | | | | In the case of autoconnect VLANs or IB partitions, if the parent interface hasn't been detected yet at startup, then the get_virtual_interface_name() won't be able to find the parent yet. That's normal, and when the parent is found, system_create_virtual_device() will be run again and the parent will be found, and the autoconnect VLAN/IB partition will be created. But we shouldn't warn that the parent can't be found when that might be a normal occurance.
* core: add nm_ip6_config_dump functionThomas Haller2013-11-073-20/+68
| | | | | | | | | Also improve nm_ip4_config_dump to print all properties and make use of nm_platform_*_to_string. Also, ensure that never_default is set to gboolean 1 or 0. Signed-off-by: Thomas Haller <thaller@redhat.com>
* cli: fix 'nmcli con up bad_name' or 'nmcli con up'Jiří Klimeš2013-11-071-2/+1
| | | | | | | ** (process:25157): CRITICAL **: nmc_activate_connection: assertion `NM_IS_CONNECTION (connection) || ifname' failed Error: unknown error. Regression caused by 42c7ea85a17a7e7459942f356399e36308011c86.
* settings: validate hostnames from D-Bus (bgo #711179)Dan Williams2013-11-072-0/+36
| | | | | | Do some minimal verification of hostnames that come in via D-Bus, for length and content. Otherwise we'd get as far as asking glibc to set the system hostname, which would reject us.
* core: fix ignore-carrier behavior (bgo #710216)Dan Williams2013-11-068-157/+162
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, ignore-carrier devices were always in the unavailable state until they were activated. This required some complicated code to keep track of whether the device was available or not based on what connections existed, whether those connections were static-IP, and whether the device was ignore-carrier. This had the side-effect of auto-activating DHCP connections on ignore-carrier devices that didn't have a carrier, if that device had at least one static IP connection available. Not good. Remove that complexity and confusion by making ignore-carrier devices always move to DISCONNECTED state, and simply refuse to activate connections that require connectivity, but allow connections that don't require connectivity. Also, when the device has no carrier, don't add connections that require connectivity to the AvailableConnections device property. https://bugzilla.gnome.org/show_bug.cgi?id=710216
| * core: compatible connections are always available on master devicesDan Williams2013-11-063-0/+36
| | | | | | | | | | | | | | Master devices depend on their slaves/ports for carrier status, so the carrier can't factor into whether a connection is available on that device or not. If it did, then no connections could be activated because the device doesn't have a carrier until slaves are attached.
| * core: add device-generated connection to settingsPavel Šimerda2013-11-061-1/+15
| | | | | | | | | | | | | | | | | | | | | | Only NMSettingsConnections can be activated on device, and get_connection() wasn't doing that. So the generated connection must be added to NMSettings. That also triggers the ConnectionProvider's 'connection-added' signal with the happy result of adding the new connection to the device's AvailableConnections list. Acked-by: Dan Williams <dcbw@redhat.com>
| * core: rework ignore-carrier device behaviorDan Williams2013-11-064-149/+111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, ignore-carrier devices were always in the unavailable state until they were activated. This required some complicated code to keep track of whether the device was available or not based on what connections existed, whether those connections were static-IP, and whether the device was ignore-carrier. Various bits of the code used nm_device_can_activate() for two different purposes: (1) to determine if the device was available on an L2 basis, which nm_device_can_activate() wasn't well-suited to, and (2) whether a specific connection could be activated at a given time based on ignore-carrier and whether the connection was static IP or not. Remove that complexity and confusion by making ignore-carrier devices always move to DISCONNECTED state, and simply refuse to activate connections that require connectivity, but allow connections that don't require connectivity. Also, when the device has no carrier, don't add connections that require connectivity to the AvailableConnections device property.
| * core: use carrier for determining when generic devices are availableDan Williams2013-11-061-7/+0
|/
* libnm-glib: add NMDevice:physical-port-id propertyDan Winship2013-11-063-0/+58
| | | | | Add the physical-port-id property to NMDevice so that clients can recognize NPAR/SR-IOV devices.
* core: improve handling of NPAR/SR-IOV devices (rh #804527)Dan Winship2013-11-0610-1/+142
| | | | | | 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: fix the reporting of failed slavesDan Winship2013-11-062-60/+77
| | | | | | If nm_device_enslave_slave() failed, the slave would log that it was waiting for the master to activate (even if the master was already active). Fix it to log an error and fail its activation instead.
* core: don't allow activating the same connection twice (rh #997998)Dan Winship2013-11-063-5/+66
| | | | | | Change the rules for connection activation so that a given NMConnection can only be used by a single NMActiveConnection at any given time.
* ifcfg-rh: clear DCB values when DCB is disabledDan Williams2013-11-053-21/+73
|
* po: updated Brazilian Portuguese (pt_BR) translation (bgo #711439)Enrico Nicoletto2013-11-051-461/+650
| | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=711439 Signed-off-by: Thomas Haller <thaller@redhat.com>
* gsystem: update libgsystem to current upstream masterThomas Haller2013-11-051-0/+0
| | | | | | This includes fixes for Coverity scans Signed-off-by: Thomas Haller <thaller@redhat.com>
* po: updated Ukrainian (uk) translation (bgo #711358)Yuri Chornoivan2013-11-041-506/+701
| | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=711358 Signed-off-by: Thomas Haller <thaller@redhat.com>
* ifcfg-rh: fix crash when reading connection (assert in ↵Thomas Haller2013-11-011-1/+1
| | | | | | | | | | | | | | | | | | | | connection_new_or_changed) rh #1025007 reports a crash on g_assert_no_error() in connection_new_or_changed() of src/settings/plugins/ifcfg-rh/plugin.c. From the back trace I am not 100% sure, what the problem was, but I think that nm_settings_connection_replace_settings failed because of nm_connection_update_secrets. Apparently such a situation can happen and it should simply be accepted as valid. What might have happened, is that the connection used to have secrets (maybe it had 802.1x configured?) and then it got changed, so update_secrets() fails because the connection no longer has a setting to which the secrets would apply. https://bugzilla.redhat.com/show_bug.cgi?id=1025007 Signed-off-by: Thomas Haller <thaller@redhat.com>
* settings: add unrecognized-specs, implement in ifcfg-rhDan Winship2013-11-0111-117/+288
| | | | | | | | | | | | | | | | | | | | In Fedora, OVS ports are now identified in ifcfg files as "TYPE=OVSPort", which NM doesn't recognize, and so it would ignore those ifcfg files. Unfortunately, this meant that if auto-default wasn't disabled, and there was no other configuration defined for the device, then NM would create an NMDefaultWiredConnection for it and screw things up. So, add an "unrecognized-specs" settings plugin property, which allows a plugin to indicate to NetworkManager that it knows of some non-NetworkManager-supported connection defined for a device. This will suppress default-wired connection creation for that device, similar to the "no-auto-default" config file option, but determined by the plugin instead of by manual configuration. Devices listed in unrecognized-specs may still be managed by NetworkManager, unless they are also listed in unmanaged-specs. https://bugzilla.redhat.com/show_bug.cgi?id=1022256
* ifcfg-rh: centralize unmanaged-spec handling in the readerDan Winship2013-11-014-154/+116
| | | | | | | | | | | Rather than having each connection-parsing function do its own unmanaged-spec handling, just do it all directly from connection_from_file(), and don't bother trying to fully parse the file if it is unmanaged, since it won't ever be seen outside of the plugin in that case anyway. This also makes it possible to have an ifcfg file of an unrecognized type be unmanaged.
* libnm-util: belatedly export nm_setting_generic_new()Dan Winship2013-11-011-0/+1
|
* ifcfg-rh: add a missing monitor-connection-files checkDan Williams2013-11-011-12/+11
| | | | | NMIfcfgConnection was still watching for hard link changes even if monitor-connection-files was off.
* ifcfg-rh: fix handling of runtime NM_CONTROLLED=yes -> no changesDan Winship2013-11-011-1/+8
| | | | | | We were accidentally removing the connection from priv->connections (and thus from unmanaged-specs) when NM_CONTROLLED changed to no when rereading a changed connection file.
* ifcfg-rh: handle change from one unmanaged-spec to anotherDan Winship2013-11-011-23/+5
| | | | | | | | | | | | | | If an ifcfg file changed from one non-NULL unmanaged-spec to another (eg, if it previously had an interface-name: unmanaged-spec, and then you add a HWADDR line, switching it to a mac: unmanaged-spec), we were not updating the connection's unmanaged property, or emitting unmanaged-specs-changed. Also, remove the notify::unmanaged handler, since only plugin.c ever changes an existing NMIfcfgConnection's unmanaged property, and it always emits the signal itself afterward (and it needs to manually emit the signal in other cases anyway, like when a connection is removed).
* core: again allow calling AddAndActivateConnection() without a connectionJiří Klimeš2013-11-012-9/+11
| | | | | | | | | | | When settings are NULL or empty in impl_manager_add_and_activate_connection(), the connection is created and completed by nm_utils_complete_generic() or nm_device_complete_connection(). Also, do not assert in nm_connection_is_type(). Returning FALSE there is sufficient. Related commit a878cd814564e9d349eb8fd4f7d7d5d81d4aecaf
* keyfile: replace g_str_equal() with g_strcmp0()Jiří Klimeš2013-11-011-1/+1
| | | | It fixes crash when nm_keyfile_connection_get_path() returns NULL.
* libnm-util: do not assert valid connection type in nm_connection_is_type()Jiří Klimeš2013-11-011-2/+1
| | | | That is not useful, simply return FALSE.
* core: fix crash when reading routes from VPN Ip6Config (bgo #706332)Thomas Haller2013-11-011-1/+1
| | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=706332 Reported-by: Nicolas Iooss <nicolas.iooss.2010_nm@m4x.org> Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: fix crash on an activation errorJiří Klimeš2013-11-011-1/+1
| | | | Reported by Oleksii Shevchuk (alxchk) on IRC
* core/cli: allow activations with only one of [ device, connection ] (bgo ↵Dan Williams2013-10-3112-67/+387
|\ | | | | | | | | | | | | | | | | | | | | | | #707427) (rh #961543) If a connection is given but no device, the correct device will be automatically determined. If a device is given but not a connection, a connection will be automatically chose from among that device's available connections. Adds the cli command "nmcli dev connect <ifname>".
| * cli: add support for 'nmcli dev connect ifname XXX'Dan Williams2013-10-313-19/+171
| |
| * cli: add support for 'nmcli con up ifname XXX'Dan Williams2013-10-313-33/+57
| | | | | | | | | | Passes a NULL connection to nm_client_activate_connection() allowing NetworkManager to pick the best available connection for the interface.
| * libnm-glib: add support for NULL connections to nm_client_activate_connection()Dan Williams2013-10-311-3/+7
| | | | | | | | | | Pass along to NetworkManager, which picks the best available connection for the device and activates it.
| * core: extend ActivateConnection to allow NULL connection pathsDan Williams2013-10-312-3/+63
| | | | | | | | | | | | | | | | | | 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: also check specific object when determining available connectionsDan Williams2013-10-315-9/+89
|/
* core: removal of PendingActivation object from nm-manager.c (bgo #707335)Dan Williams2013-10-3131-1344/+2097
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | This branch decouples NMActiveConnection creation from device activation so that the NMActiveConnection object tracks the entire activation request (either internally-requested by the Policy or externally via D-Bus) from start to finish, instead of the previous situation where the PendingActivation handled D-Bus requests separately. This also will allow implementation of the DEACTIVATING state in the future. The NMActiveConnection object tracking the activation is not actually exported to D-Bus until the device or VPN activation is completely authorized and actually begins. It also encapsulates all the details needed to authorize a request into a new NMAuthSubject class, replacing various "dbus_sender" and "user_requested" arguments throughout the code.
| * trivial: add logging for ActiveConnection master-ready trackingDan Williams2013-10-311-3/+41
| |
| * core: kill PendingActivation and move authorization to NMActiveConnectionDan Williams2013-10-312-512/+436
| | | | | | | | | | | | | | | | Besides killing PendingActivation, this patch decouples ActiveConnection creation from actually activating that connection. This allows the ActiveConnection to complete authorization asynchronously. This will also be used in the future for handling the DEACTIVATING state of devices (for "pre-down" functionality).
| * policy: track secondary activations by ActiveConnection not pathDan Williams2013-10-311-43/+38
| | | | | | | | | | | | | | ActiveConnections will (soon) not have a D-Bus path on creation, but only when they are exported after authorization is complete. That means we can't rely on their dbus path in the secondaries code. Instead, track them directly since the path may be NULL.
| * policy: only clean up VPN DNS/routing configuration if the VPN got connectedDan Williams2013-10-311-17/+35
| | | | | | | | | | It's pointless and wrong to try to clean up DNS and routing configuration if the VPN never got to the point of retrieving that from the server.
| * core: allow ActiveConnections to be created without a deviceDan Williams2013-10-313-23/+41
| | | | | | | | | | | | | | The device may not be created yet (in the case of software devices) when the ActiveConnection is created; in that case we still want to proceed with authorization for the connection, but we'll create the device when authorization is complete.
| * core: have ActiveConnection track device state instead of subclassesDan Williams2013-10-316-96/+101
| | | | | | | | | | | | Both NMActRequest and NMVPNConnection need to track their device's state, so instead of both subclasses having to do so, consolidate that code into the superclass.
| * core: add slave to master in stage1_prepare, not nm_device_activate()Dan Williams2013-10-311-18/+59
| | | | | | | | | | | | | | When ActiveConnections take over authentication, it may mean that the master active connection is still handling authentication when the slave starts to activate. Thus the master device may still be in DISCONNECTED state and not ready to enslave the slave.
| * core: ensure all devices chain up to parent act_stage1_prepareDan Williams2013-10-314-1/+21
| | | | | | | | | | We'll be moving some code into the NMDevice implementation soon, which currently does nothing other than return success.
| * core: indicate via a property when master connections are ready for slavesDan Williams2013-10-312-0/+69
| | | | | | | | | | | | | | | | | | Add a 'master-ready' property to NMActiveConnection that NMDevice can watch for to indicate that the master connection/device is ready to accept slaves. Since the slave device's ActiveConnection is already tracking its master connection, and since ActiveConnections don't enter the ACTIVATING state until their device is ready for slaves, it's pretty trivial to implement this property.
View Lorry Controller Status