summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* cli: add IPv{4,6} setting for all new non-slave connections in editorjk/rh997958-nmcli-editor-compareJiří Klimeš2013-10-211-0/+9
|
* cli: copy remote connection to local one on 'save' (rh #997958)Jiří Klimeš2013-10-211-1/+15
| | | | | | | | | | | | | | Plugins may have problems with preserving some properties on write/read cycle, may add ipv{4,6} settings when they are not present in the connection, etc. That makes local and remote connection differ. So we copy remote connection into the local to get rid of such problems. Note: 68f12b4e9c134d41e42cc8a1986cad6bb3c07b7a and f03635e5ac829d4fc896573f2f3c6969b9d5a2e2 commits ensure that all connection (except slaves) have IPv{4,6} settings. https://bugzilla.redhat.com/show_bug.cgi?id=997958
* cli: properly initialize new team-slave connections in editorJiří Klimeš2013-10-211-6/+5
|
* device: remove unused 'dev_state' variablePavel Šimerda2013-10-201-6/+0
| | | | Reported-by: Julien Nabet <serval2412@yahoo.fr>
* platform: use translated VLAN flagsPavel Šimerda2013-10-201-1/+1
| | | | | | | The internal VLAN flags were translated into the kernel VLAN flags but finally the internal ones were passed to the kernel instead. Reported-by: Julien Nabet <serval2412@yahoo.fr>
* Fix typosYuri Chornoivan2013-10-1915-22/+22
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=710505
* bluez: remove created NAP connection together with NMBluezDeviceThomas Haller2013-10-181-6/+30
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* bluez: merge rework of BlueZ to detect BlueZ 4 vs. 5 at runtime (bgo #709412)Thomas Haller2013-10-1814-753/+1322
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before, you had to select at compile time to run BlueZ4 or BlueZ5. Now, both versions are enabled together and NM detects the actual version at runtime. The configure option --enable-bluez4 got removed. The advantage is now, that you can switch between the two versions of BlueZ without rebuilding NetworkManager. Note however, that you still must restart NetworkManager, because once a version is detected, it will not switch again as long as the process runs. Another advantage is that before not all code was build, and you had to build two configurations for testing. https://bugzilla.gnome.org/show_bug.cgi?id=709412 Signed-off-by: Thomas Haller <thaller@redhat.com>
| * bluez: fix calling of bdaddr added/removed signals in nm-bluez4-adapterThomas Haller2013-10-181-24/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix several issues with emitting the BDADDR_ADDED/BDADDR_REMOVED signals: - when removing a device, the handlers were never disconnected from the device's notify::usable and initialized signals. - ensure that the signals BDADDR_ADDED/BDADDR_REMOVED only get emitted in a consistent way (toggeling). Before, there was a bug, that the signal BDADDR_REMOVED was emitted for devices that were never added and never usable. Co-Authored-By: Dan Williams <dcbw@redhat.com> Signed-off-by: Thomas Haller <thaller@redhat.com>
| * bluez: use GDBus instead of dbus-glib in nm-bluez-device.cThomas Haller2013-10-182-255/+206
| | | | | | | | | | | | | | | | | | | | | | Refactor nm-bluez-device.c to use GDBus both to connect to BlueZ 4 and BlueZ 4. Also remove the unused property RSSI. Also prefix every logline with the dbus path of the device. Signed-off-by: Thomas Haller <thaller@redhat.com>
| * bluez: enable both BlueZ4 and 5 and select it dynamically at runtimeThomas Haller2013-10-189-180/+725
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NMBluezManager is now a proxy and only delegates to either NMBluez4Manager or NMBluez5Manager. It detects the running BlueZ version at runtime, and once it decides for one version, it cannot be changed anymore as long NetworkManager is running. This means, when switching from BlueZ4 to BlueZ5 or vice versa you have to restart NetworkManager. This should be acceptable, because it is not a common use case (most systems won't have both versions installed anyway) and it greatly simplifies implementation. Also note that NMBluez4Manager and NMBluez5Manager do not implement a common interface. NMBluezManager delegates to the correct manager. Having them share an common interface or base class would not simplify the code, because NMBluezManager not only delegates, but it also acts as a proxy until it is decided which BlueZ version is running. So, this proxy-like behaviour would still be needed. The alternative would be to merge the functionality of all three NMBluez*Manager classes into one. This also removes the --enable-bluez4 configure switch, because both versions are now always enabled. https://bugzilla.gnome.org/show_bug.cgi?id=709412 Signed-off-by: Thomas Haller <thaller@redhat.com>
| * bluez: copy bluez-manager file for version 4 and 5Thomas Haller2013-10-186-6/+80
| | | | | | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
| * bluez: rename BlueZ 4 adapter to make the BlueZ version explicitThomas Haller2013-10-184-85/+85
| | | | | | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
| * bluez: support BlueZ 4 and 5 together in nm-bluez-device.cThomas Haller2013-10-184-110/+90
| | | | | | | | | | | | | | Do no longer separate nm-bluez-device at compile time with the WITH_BLUEZ4 preprocessor flag. Signed-off-by: Thomas Haller <thaller@redhat.com>
| * bluez: rename variables in nm-bluez-common.h for BlueZ 4 vs. 5Thomas Haller2013-10-185-27/+27
|/ | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: make callback argument in ↵Thomas Haller2013-10-182-16/+9
| | | | | | nm_settings_connection_commit_changes/_delete optional Signed-off-by: Thomas Haller <thaller@redhat.com>
* platform: don't treat unrecognized WiMAX devices as EthernetDan Williams2013-10-183-0/+9
| | | | | | | | | If the WiMAX plugin isn't installed, or the WiMAX device isn't recognized, NetworkManager shouldn't treat the interface as regular ethernet since the device requires specific setup to be ready for IP configuration, which of course NetworkManager can't do because the WiMAX plugin isn't loaded. Ignore them instead.
* trivial: fix indentation in nm_manager_activate_connection()Jiří Klimeš2013-10-181-8/+8
|
* settings: document nm_settings_add_connection()Dan Williams2013-10-171-0/+14
|
* settings: clarify ownership of objects returned from plugin's ↵Dan Williams2013-10-173-1/+32
| | | | | | | | | add_connection() hook Plugin owns the object and callers must reference it if they wish to use it outside of the function they called "add" from. Likewise, callers of the ConnectionProvider's add_connection method must also reference the returned object if they wish to continue using it.
* dhcp: don't crash when no DHCP client is available (rh #1015809)Jiří Klimeš2013-10-171-1/+9
| | | | | | Print a warning instead. https://bugzilla.redhat.com/show_bug.cgi?id=1015809
* core: announce device removal even for udev events with no ifindex propertyThomas Haller2013-10-171-0/+1
| | | | | | | | Actually, this case should no longer happen, but just to be sure: when a udev remove event without ifindex comes, get the ifindex from the cache and announce the device removal. Signed-off-by: Thomas Haller <thaller@redhat.com>
* platform: fix srcdir != builddir build after last changeDan Winship2013-10-161-0/+1
|
* platform: detect non-mac80211 WiFi devices as WiFi (rh #1015598)Dan Williams2013-10-161-2/+5
| | | | | | | | | | | | | Before NMPlatform landed, the old NMManager code looked at either DEVTYPE=wlan or asked the internal wifi utilities whether the device was WiFi or not. This got lost when moving to NMPlatform. It turns out that only mac80211-based drivers set the DEVTYPE=wlan flag in sysfs, while older WEXT, out-of-tree, and staging drivers often do not (though they should). To avoid breaking recognition of these crappy drivers that used to work, re-add the wifi utils checks.
* settings: normalize and verify connections on updateDan Winship2013-10-161-0/+4
| | | | | When a connection is updated (either by its plugin or via D-Bus), we need to normalize and verify it before accepting the changes.
* platform: fix getting "ifindex" for devices on 'remove' udev actionJiří Klimeš2013-10-162-15/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have to get IFINDEX using g_udev_device_get_property() instead of g_udev_device_get_sysfs_attr(). On removal the IFINDEX in sysfs may not be available - this didn't caused problems because such an event was ignored. But sometimes the sysfs IFINDEX in 'remove' action was present, but *wrong*. It contained IFINDEX of a newly created device of the same name, and thus it triggered removal of the new device instead of the old one. Logs (grepped): ... NetworkManager[30628]: <info> Auto-activating connection 'b1'. NetworkManager[30628]: <debug> [1381930187.149545] [platform/nm-platform.c:1777] log_link(): signal: link added: bb (328) NetworkManager[30628]: <debug> [1381930187.937222] [platform/nm-linux-platform.c:2568] handle_udev_event(): UDEV event: action 'add' subsys 'net' device 'bb' (328) NetworkManager[30628]: <debug> [1381930187.937662] [platform/nm-platform.c:1777] log_link(): signal: link added: bb (328) NetworkManager[30628]: <info> (bb): deactivating device (reason 'user-requested') [39] NetworkManager[30628]: <debug> [1381930193.266097] [platform/nm-platform.c:397] nm_platform_link_delete(): link: deleting 'bb' (328) NetworkManager[30628]: <debug> [1381930193.279324] [platform/nm-platform.c:1777] log_link(): signal: link removed: bb (328) NetworkManager[30628]: <debug> [1381930193.348167] [platform/nm-linux-platform.c:2568] handle_udev_event(): UDEV event: action 'remove' subsys 'net' device 'bb' (unknown) NetworkManager[30628]: <info> Auto-activating connection 'b1'. NetworkManager[30628]: <debug> [1381930193.561106] [platform/nm-platform.c:1777] log_link(): signal: link added: bb (330) NetworkManager[30628]: <debug> [1381930194.217300] [platform/nm-linux-platform.c:2568] handle_udev_event(): UDEV event: action 'add' subsys 'net' device 'bb' (330) NetworkManager[30628]: <debug> [1381930194.217548] [platform/nm-platform.c:1777] log_link(): signal: link added: bb (330) NetworkManager[30628]: <info> (bb): deactivating device (reason 'user-requested') [39] NetworkManager[30628]: <debug> [1381930216.329118] [platform/nm-platform.c:397] nm_platform_link_delete(): link: deleting 'bb' (330) NetworkManager[30628]: <debug> [1381930216.344442] [platform/nm-platform.c:1777] log_link(): signal: link removed: bb (330) NetworkManager[30628]: <info> Auto-activating connection 'b1'. NetworkManager[30628]: <debug> [1381930216.598636] [platform/nm-platform.c:1777] log_link(): signal: link added: bb (332) This line is bad: NetworkManager[30628]: <debug> [1381930217.79182] [platform/nm-linux-platform.c:2568] handle_udev_event(): UDEV event: action 'remove' subsys 'net' device 'bb' (332) NetworkManager[30628]: <debug> [1381930217.81009] [platform/nm-platform.c:1777] log_link(): signal: link removed: bb (332) NetworkManager[30628]: <info> (bb): deactivating device (reason 'removed') [36] NetworkManager[30628]: <debug> [1381930217.95192] [platform/nm-linux-platform.c:2568] handle_udev_event(): UDEV event: action 'add' subsys 'net' device 'bb' (332) NetworkManager[30628]: <debug> [1381930217.95492] [platform/nm-platform.c:1777] log_link(): signal: link added: bb (332) NetworkManager[30628]: <info> Auto-activating connection 'b1'. ...
* platform: log links in event_notification() in debug modeJiří Klimeš2013-10-161-1/+8
|
* libndp: update to git masterDan Williams2013-10-151-0/+0
|
* libnm-glib: remove bogus warningDan Williams2013-10-151-1/+0
| | | | | | | When connecting to a hidden SSID, the Access Point object that NetworkManager creates will have no frequency, because the frequency is unknown until the connection succeeds. The warning has no use; if the AP doesn't have a frequency then it even match a connection with a specified frequency.
* core: print ifindex when logging UDEV eventThomas Haller2013-10-152-4/+11
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: don't have IP4 and IP6 configs on slavesDan Winship2013-10-145-97/+126
| | | | | | | | | | | | | | | Although it's convenient in some places to have IP configs on all connections, it makes more sense in other places to not have IP configs on slaves. (eg, it's confusing for nmcli, etc, to report a full NMSettingIP4Config on a slave device). So revert parts of the earlier patch. However, it's still safe to assume that s_ip4 != NULL if method != DISABLED, so some of the earlier simplifications can stay. Also, add nm_utils_get_ip_config_method(), which returns the correct IP config method for a connection, whether the connection has IP4 and IP6 settings objects or not, and use that to keep some more of the simplifications from the earlier patch.
* trivial: whitespace fixThomas Haller2013-10-141-17/+17
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* nm-online: check return value of nm_client_new()Jiří Klimeš2013-10-141-1/+6
|
* libnm-glib: fix a crash in nm_client_new() (rh #1010288)Jiří Klimeš2013-10-141-5/+30
| | | | | | | | We have to check if 'client' is valid when calling _nm_object_ensure_inited(). Creation of NMClient object can fail, because its parent NMObject's constructor() returns NULL for D-Bus errors. https://bugzilla.redhat.com/show_bug.cgi?id=1010288
* core: fix crash for bridge-slave with missing NMSettingBridgePort settingThomas Haller2013-10-111-11/+18
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* ifcfg-rh: fix handling of minimal ifcfg filesDan Winship2013-10-112-71/+50
| | | | | | | | | ifcfg-rh had the rule that if an ifcfg file had no BOOTPROTO and no IPv4 addresses, then it should be treated as method=auto for compatibility. But in fact, current ifup treats it as method=disabled, so we should too. https://bugzilla.gnome.org/show_bug.cgi?id=708875
* settings: make connections always have s_ip4 and s_ip6Dan Winship2013-10-1112-189/+302
| | | | | | | | | | | | | | | | Make sure that all connections returned from NMSettings or created via AddAndActivateConnection have an NMSettingIP4Config and an NMSettingIP6Config, with non-NULL methods, and get rid of now-unnecessary checks for those. Also move the slaves-can't-have-IP-config checks into the platform-independent code as well. This also gets rid of spurious "ignoring IP4/IP6 configuration" warnings in ifcfg-rh when reading a slave ifcfg file. Partly based on a patch from Pavel. https://bugzilla.gnome.org/show_bug.cgi?id=708875
* libnm-util: remove reference to non-existent "Posix" namespaceDan Winship2013-10-111-4/+1
| | | | | There's no way in gobject-introspection to annotate something as returning an arbitrary C struct type, so don't try.
* libnm-util, libnm-glib: fix up some gtk-doc commentsDan Winship2013-10-1110-46/+49
| | | | | | | | | gtk-doc recognizes that #NMFoos is the plural of #NMFoo now, so you don't need to put an empty comment between the type name and the "s" to make it work. (Unfortunately, it's not smart enough to realize that "NMIP4Addresses" is the plural of "NMIP4Address".) Also, add some missing "#"s noticed along the way.
* core: fix PropertiesChanged signals for IP-related propertiesDan Williams2013-10-091-16/+30
| | | | | | | | | | | | | | | | | | To present a consistent API to clients, the IP-related properties are only valid when the device has finished IP configuration. But they are set before that happens, and their change notifications were emitted before the IP configuration was considered valid. Re-emit the change notifications when the device enters the IP_CHECK state (and thus has IP configuration) and also when the device deactivates to enusre clients have up-to-date IP-related property information. For the changes to has_ip_config(), the priv->ipX_state checks are not necessary since the device will have valid IP configuration when it enters the IP_CHECK state. The other checks can be consolidated into a single statement. Acked-by: Dan Winship
* trivial: remove unnecessary warningDan Williams2013-10-091-1/+0
|
* core: avoid use-after-free in libnm-util/bond.verify()Thomas Haller2013-10-081-2/+2
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* po: updated Brazilian Portuguese (pt_BR) translation (bgo #709675)Enrico Nicoletto2013-10-081-355/+505
| | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=709675 Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: allow IPv4 to proceed if IPv6 is globally disabled but set to "auto" ↵Dan Williams2013-10-071-2/+2
| | | | | | | | | | (rh #1012151) If the user disabled IPv6 support in the kernel with "ipv6.disable=1" on the kernel boot line, then any attempts to open IPv6 sockets (which libndp does) will fail. This failed the entire connection, even if IPv6's "may-fail" property was TRUE. Instead, just fail IPv6 and allow IPv4 to proceed. If IPv4 fails or is disabled, then other logic will fail the entire connection.
* ifcfg-rh: ignore default routes in route6 file (rh #991807)Jiří Klimeš2013-10-072-4/+13
| | | | | | | Base on patch from Francesco Prelz <Francesco Prelz mi infn it>: https://mail.gnome.org/archives/networkmanager-list/2013-January/msg00095.html https://bugzilla.redhat.com/show_bug.cgi?id=991807
* ifcfg-rh: fix ignoring updates that don't change anythingDan Williams2013-10-041-8/+3
| | | | | | | | | | connection_from_file() requires the 'error' parameter. Not passing a valid 'error' parameter causes the function to fail and return NULL, which mean that commit_changes() would always re-write the connection instead of ignoring commits where nothing has actually changed. connection_from_file() no longer requires the unmanaged, keyfile, or routefile parameters, so remove them.
* test: launch dbus for test-remote-settings-clientThomas Haller2013-10-041-1/+5
| | | | | | | | | | | | | | | | Running `make check` on systems without running dbus failed in test-remote-settings-client.c:383 make[4]: Entering directory `/tmp/NetworkManager/libnm-glib/tests' /tmp/NetworkManager/libnm-glib/tests/test-remote-settings-client /tmp/NetworkManager/libnm-glib/tests test-remote-settings-service.py ** (/tmp/NetworkManager/libnm-glib/tests/.libs/lt-test-remote-settings-client:26983): WARNING **: Error connecting to D-Bus: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11 make[4]: *** [check-local] Trace/breakpoint trap (core dumped) Modify the Makefile to start the dbus-daemon, if it is not yet running. Signed-off-by: Thomas Haller <thaller@redhat.com>
* bluez: fix leak of NMBluezDevice in bluez_connect_cbThomas Haller2013-10-031-1/+3
| | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* core: fix nm_ip6_config_replace() nameserver address comparisonDan Williams2013-10-031-2/+2
|
* trivial: print route prefix when printing RA discovered routesDan Williams2013-10-031-1/+1
|
View Lorry Controller Status