summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* man, docs: add the secret flags notes non-hackishlydanw/setting-docs-bgo740224Dan Winship2014-11-165-3/+9
| | | | | | | | Since libnm-core secret-flags properties are now enum-typed rather than just being uints, we can now actually recognize them when generating docs, rather than just assuming that every property whose name ends in '-flags', but isn't in NMSettingDcb, is a secret-flags property.
* cli, libnm: don't use D-Bus-specific documentation in nmcliDan Winship2014-11-164-3/+16
| | | | | | | Now that nm-setting-docs.xml is more D-Bus-specific, it's less appropriate for nmcli's internal documentation. So generate a second copy of the docs without using the overrides file, and use that one for nmcli's documentation.
* libnm: Override parts of nm-setting-docs.xmlDan Winship2014-11-1612-15/+207
| | | | | | | | | | | Add "---dbus---" sections to the NMSetting property docs, in the same style as the plugin docs, parse them out into a file "nm-setting-docs-overrides.xml", and use them to override the GObject property docs in nm-setting-docs.xml. This lets us put more D-Bus-specific information in the setting docs, without cluttering up the property docs, and it also lets us document dbus-only properties.
* libnm: fix nm-setting-docs.xml property typesDan Winship2014-11-164-20/+62
| | | | | | | | | Add nm_setting_get_dbus_property_type(), and use this to get the correct type for properties in nm-seting-docs.xml, in situations where the D-Bus and GObject property types don't match. In the case of enum/flags-valued properties, give both the enum name and the underlying D-Bus type.
* libnm-core: make GBytes D-Bus marshalling be built-in to NMSettingDan Winship2014-11-164-36/+4
| | | | | | | Each GBytes-valued property was using _nm_setting_class_transform_property() to register a GBytes<->'ay' transform. So just build that rule into the generic machinery in nm-setting.c.
* libnm, libnm-util: move settings doc generation to libnm-coreDan Winship2014-11-1642-1369/+1242
| | | | | | | | | | | | | | | | | | | | | Move the settings/plugins doc generation from libnm-util to libnm-core, since libnm-util isn't being updated for all new properties. With this commit, the keyfile and ifcfg-rh documentation is basically unchanged, except that deprecated properties are now gone, and new properties have been added, and the sections are in a different order. (generate-plugin-docs.pl just outputs the settings in Makefile order, and they were unsorted in libnm-util, but are sorted in libnm-core). The settings documentation used for nm-settings.5, the D-Bus API docs, and the nmcli help is changed a bit more at this point, and mostly for the worse, since the libnm-core setting properties don't match up with the D-Bus API as well as the libnm-util ones do. To be fixed... (I also removed the "plugins docs" line in each plugin docs comment block while moving them, since those blocks will be used for more than just plugins soon, and it's sort of obvious anyway.)
* libnm-core: change how new and legacy properties are serialized (bgo 740140)Dan Winship2014-11-159-48/+248
|\
| * libnm-core: change how new and legacy properties are serializedDan Winship2014-11-157-48/+243
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although libnm filters out properties received from the daemon that it doesn't understand, there may be other clients that do not. In particular, a client might call GetSettings() on a connection, update the ipv4.addresses property in the returned dictionary, and then pass the dictionary to Update(). In that case, the updated dictionary would contain ipv4.address-data, but it would not reflect the changes the client intended to make. Fix this by changing the daemon side to prefer the legacy properties to the new ones if both are set, and changing the client side to not send the legacy properties (since we don't support new clients talking to old servers anyway).
| * libnm-core: add _nm_utils_is_manager_processDan Winship2014-11-152-0/+5
|/ | | | | Add a variable indicating whether the process is the NetworkManager daemon.
* libnm, examples: fix some annotations and update python examples (bgo 740145)Dan Winship2014-11-1519-177/+275
|\
| * examples: update python examplesDan Winship2014-11-1512-137/+227
| | | | | | | | | | | | | | | | | | | | Update the raw D-Bus python examples to use newer APIs where appropriate (and split the add-connection example into 1.0-only and 0.9-compatible versions). Update the gi-based python examples for the various API changes since they were last updated. Also add a comment to the ruby add-connection example pointing out that it's still using the old settings APIs.
| * libnm-core: add some missing array length annotationsDan Winship2014-11-151-23/+23
| | | | | | | | | | A bunch of nm-utils methods that used to take GByteArray now take array+length, but weren't annotated to indicate that.
| * libnm: add some missing (transfer) annotationsDan Winship2014-11-156-17/+25
|/ | | | | | | | | | All the old "const GByteArray" methods got changed to return a GBytes instead, but since they aren't declared "const" any more, we need to explicitly annotate them "(transfer none)". Also, the scanner apparently doesn't recognize that an (out) "const char **" is "(transfer none)", so annotate that in two places too
* merge: nmcli device activation behavior fixes (bgo #740136)Dan Williams2014-11-142-26/+15
|\
| * cli: Finish waiting for the device activation when it disconnectsLubomir Rintel2014-11-141-26/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The device status alone is uninteresting as its changes can be due to deactivation of previously active connection. We should monitor the active connection changes instead of device state changes. However the device state changes is still interesting, as it contains the reason for the change, let's just ignore them while the connection is activating. Lastly, we need to handle failures as well. It should be noted that it's not sufficient to deal with NM_DEVICE_STATE_FAILED as the device will quickly draverse to NM_DEVICE_STATE_DISCONNECTED. This happens in case of a failure due to NM_DEVICE_STATE_REASON_NO_SECRETS as soon as the server makes sure it won't reconnect automatically.
| * libnm: Watch for AC removal in case of AddAndActivateConnection() as wellLubomir Rintel2014-11-141-0/+3
|/ | | | This does the very same thing as 42b9e8283 does for plain ActivateConnection().
* core: fix return type of addrconf6_start()Dan Williams2014-11-141-1/+1
| | | | | It returned a boolean and the caller expected a boolean, but the return type was NMActStageReturn.
* docs: make the settings docs work from tarball buildsDan Winship2014-11-145-14/+21
| | | | | | | | | | | | | | | | | | | | | | | | docs/api/settings-spec.xml was accidentally not getting disted, because gtk-doc.make explicitly removes all DISTCLEANFILES from distdir. However, it doesn't actually make sense for the settings docs files to be in DISTCLEANFILES anyway; they were put there rather than CLEANFILES (IIRC) so that "make clean" in a tarball build wouldn't delete them and break things. But the right fix is to just make them only be in CLEANFILES when BUILD_SETTING_DOCS is true, and not ever get deleted otherwise. Also adjust the build rules to ensure that the generated docs don't get rebuilt in tarball builds, since that can cause problems when building from a read-only source tree, etc. Meanwhile, in an unrelated but also fatal bug, configure.ac's check for if the generated docs were already present never got updated for the cli/src -> clients/cli move, and so even if we had been disting settings-spec.xml, configure would still think that the tarball didn't have all of the generated docs in it, so SETTING_DOCS_AVAILABLE would be set false and none of the generated docs would get used. https://bugzilla.gnome.org/show_bug.cgi?id=740035
* core: fix a spurious warning with non-kernel network devicesDan Winship2014-11-147-14/+36
| | | | | | | NMDevice was warning about not being able to set ifindex even on devices that we know don't have an ifindex. https://bugzilla.gnome.org/show_bug.cgi?id=739889
* Revert "cli: Finish waiting for device activation when they disconnect"Lubomir Rintel2014-11-141-2/+1
| | | | | | | In case there's already a connection on the device, it traverses to DISCONNECTED. We shouldn't cease waiting then. This reverts commit 94a57d5e07b9e3d7f52b4ea3c8b86da9eed28baa.
* dhcp: Fix the DHCP client lookup by gtypeLubomir Rintel2014-11-141-1/+1
|
* libnm*: fix library gettext usage (bgo 740071)Dan Winship2014-11-13341-176/+729
|\
| * libnm*: fix library gettext usageDan Winship2014-11-1384-80/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Libraries need to include <gi18n-lib.h>, not <gi18n.h>, so that _() will get defined to "dgettext (GETTEXT_DOMAIN, string)" rather than "gettext (string)" (which will use the program's default domain, which works fine for programs in the NetworkManager tree, but not for external users). Likewise, we need to call bindtextdomain() so that gettext can find the translations if the library is installed in a different prefix from the program using it (and bind_textdomain_codeset(), so it will know the translations are in UTF-8 even if the locale isn't). (The fact that no one noticed this was broken before is because the libraries didn't really start returning useful translated strings much until 0.9.10, and none of the out-of-tree clients have been updated to actually show those strings to users yet.)
| * all: consistently include config.hDan Winship2014-11-13333-96/+639
|/ | | | | | | | | | | config.h should be included from every .c file, and it should be included before any other include. Fix that. (As a side effect of how I did this, this also changes us to consistently use "config.h" rather than <config.h>. To the extent that it matters [which is not much], quotes are more correct anyway, since we're talking about a file in our own build tree, not a system include.)
* dhcp: log the configured DHCP clientThomas Haller2014-11-131-8/+10
| | | | | | | Also move enumerating the installed DHCP plugins to the beginning of nm_dhcp_manager_init(). Signed-off-by: Thomas Haller <thaller@redhat.com>
* contrib: Enable PolicyKit agent in RPMLubomir Rintel2014-11-131-0/+2
|
* contrib: Require libselinux for RPM buildLubomir Rintel2014-11-131-0/+2
| | | | It ensures ifcfg-rh doesn't mess up the labels.
* cli: Finish waiting for device activation when they disconnectLubomir Rintel2014-11-131-1/+2
| | | | | | | | | | When wifi secrets are missing, NM_DEVICE_STATE_FAILED due to NM_DEVICE_STATE_REASON_NO_SECRETS is immediately followed by traversal to NM_DEVICE_STATE_DISCONNECTED as soon as the server makes sure it won't reconnect automatically. We sometimes aren't quick to handle the first signal and only get the latter one. Let's treat all states that aren't ordinarily reached upon activation as bad.
* tui: fix unsetting Gateway (rh #1163896)Dan Winship2014-11-131-1/+1
| | | | | When the Gateway field is empty, we need to set the property to NULL, not "".
* merge: wifi bssid handling fixesLubomir Rintel2014-11-132-13/+10
|\ | | | | | | | | | | | | Avoid passing NULL bssid where it does not make sense, fix a couple of bad asserts. https://bugzilla.gnome.org/show_bug.cgi?id=739258
| * wifi: Empty AP BSSID is NULL, not an invalid addressth/bgo739258_wifi_bssid_fixesLubomir Rintel2014-10-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | Since 3a54d050 the AP address is not a gbyte[], but a char *. The fake AP BSSID fixup could trigger an assertion failure: Oct 26 11:14:45 goatlord.localdomain NetworkManager[540]: nm_ethernet_address_is_valid: assertion 'addr != NULL' failed https://bugzilla.gnome.org/show_bug.cgi?id=739258 Fixes: 3a54d050985d6ef2067b025571910a8ccd3cbd57
| * wifi: avoid assertion in nm_ap_check_compatible() when comparing AP with ↵Thomas Haller2014-10-271-1/+1
| | | | | | | | | | | | missing BSSID Signed-off-by: Thomas Haller <thaller@redhat.com>
| * wifi: ensure not passing NULL bssid as string to printf logging functionsThomas Haller2014-10-272-11/+8
| | | | | | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* | libnm-util: fix typos in libnm-util documentationJiří Klimeš2014-11-131-2/+2
| |
* | tui: fix alignment of pop-up menusDan Winship2014-11-121-2/+17
| | | | | | | | | | | | | | | | Pop-up menus were slightly mis-aligned in the main window, and even more mis-aligned in slave-editing windows. Fix that. Also add a bit of padding to the pop-up window, because it just looks better that way.
* | build: fix configure formatting of IN6_ADDR_GEN_MODE checkDan Williams2014-11-121-4/+8
| | | | | | | | | | Print the result, and make the m4 formatting consistent with the other kernel checks.
* | tui: fix gateway editingDan Winship2014-11-124-6/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since adding NMSettingIPConfig:gateway, we were just binding that property to the Gateway entry as a string. But this caused two different problems: first, we were trying to set the :gateway property from the entry even when the IP address in the entry was incomplete (causing warnings), and second, we were no longer enforcing the rule that the gateway can only be set when there are static addresses configured. Fix this by adding back nm_editor_bind_ip_gateway_to_string(), but with new semantics reflecting the new way NMSettingIPConfig:addresses and :gateway work. (Besides just fixing the new bugs, this also makes the Gateway entry insensitive when there are no addresses; before, nmtui would allow you to type there, but the value would not be saved.) Fixes: Test263_nmtui_ipv4_addresses_delete_ip_and_back_to_auto https://bugzilla.gnome.org/show_bug.cgi?id=740017
* | man: fix `make uninstall` to remove the nmtui manual pagesThomas Haller2014-11-121-0/+4
| | | | | | | | | | Fixes: 1e8b681d4f10c2b5e9478ec4972cad64aa1f8e7c Signed-off-by: Thomas Haller <thaller@redhat.com>
* | bluez: Another bluez5 build fixLubomir Rintel2014-11-121-5/+10
| | | | | | | | | | | | | | Fixes the "unused declaration" warning with -Werror and no bluez-libs. Fixes: f1c9595311f52d8b79e8d2032e006005613a8fb1 Fixes: 751b52e50be049b53a0b998638a22d4e28a59135
* | bluez: fix build without bluez5-dunThomas Haller2014-11-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | make[5]: Entering directory `./NetworkManager/_build/src/devices/bluetooth' CC nm-bluez-device.lo ../../../../src/devices/bluetooth/nm-bluez-device.c: In function 'nm_bluez_device_disconnect': ../../../../src/devices/bluetooth/nm-bluez-device.c:430:5: error: "WITH_BLUEZ5_DUN" is not defined [-Werror=undef] #if WITH_BLUEZ5_DUN Fixes: f1c9595311f52d8b79e8d2032e006005613a8fb1 Fixes: 751b52e50be049b53a0b998638a22d4e28a59135 Signed-off-by: Thomas Haller <thaller@redhat.com>
* | bluetooth: Don't call into bluez5 DUN code when it's not enabledLubomir Rintel2014-11-121-0/+12
| | | | | | | | | | | | | | | | | | It is conditionally compiled depending on presence of bluez-libs. Results in undefined symbols: NetworkManager[19346]: <warn> (/libnm-device-plugin-bluetooth.so): failed to load plugin: /usr/lib64/NetworkManager/libnm-device-plugin-bluetooth.so: undefined symbol: nm_bluez5_dun_cleanup
* | platform: assert against expected lifetime values of NMPlatformIPAddressThomas Haller2014-11-121-0/+5
| | | | | | | | Signed-off-by: Thomas Haller <thaller@redhat.com>
* | trivial: fix description of route-metricJiří Klimeš2014-11-121-2/+2
| |
* | clients: only handle secret requests for connection being explicitly activatedJiří Klimeš2014-11-125-8/+28
| | | | | | | | | | | | | | | | | | | | | | When a connection is being activated, nmcli could ask for secrets for another connection, which might confuse users. We check the request now and only ask for secrets of connection being activated. Test case: $ nmcli con up my-ethernet0 Passwords or encryption keys are required to access the wireless network 'Red Hat'. Warning: password for '802-1x.identity' not given in 'passwd-file' and nmcli cannot ask without '--ask' option.
* | glib-compat: sync local definition of g_clear_pointer() with upstream glib ↵Thomas Haller2014-11-121-17/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and remove atomic operations Upstream glib changed g_clear_pointer() not to use atomic functions. Update or local definition to b1dd594a22e3499caafdeccd7fa223a032b9e177 glib/gmem.h (glib 2.41.3). (fixup whitespace to match our style). See also the related bug https://bugzilla.gnome.org/show_bug.cgi?id=733969 from glib. Signed-off-by: Thomas Haller <thaller@redhat.com>
* | core: remove unused variableDan Williams2014-11-111-4/+0
| |
* | vpn: update DefaultRouteManager before sending state change signalDan Williams2014-11-111-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The DRM now affects DNS too, since it determines the "best" IPv4 and IPv6 configs based on it's idea of the default route. The Policy is also still updating DNS from a state-change handler for VPN connections. This led to a situation where the Policy would remove the VPN's IP config from the DNS manager in vpn_connection_deactivated() and call update_ip4_dns(), whereupon get_best_ip4_config() returned the just-removed VPN IPv4 config as "best" because the VPN connection hadn't yet told the DefaultRouteManager to remove it. Which meant VPN nameservers stuck around in resolv.conf for a long time after the VPN was disconnected. Fixes: a39a3ae4cd72d695f1b5d10eaa79544f2020a54e
* | tui: fix generated new connection namesDan Winship2014-11-111-1/+1
| | | | | | | | | | | | Now that "i" is being used in the first loop over all connections, we need to reset it before using it again in the loop to find an available name.
* | dhcp: fix adapter for sd logging macros to show file locationThomas Haller2014-11-111-2/+5
| | | | | | | | | | | | | | Previously we were logging: <debug> [1415715440.639086] [__FILE__:__LINE__] client_set_lease_timeouts(): DHCP CLIENT (0xcf221f86): T1 expires in 11h 59min 53.566147s Signed-off-by: Thomas Haller <thaller@redhat.com>
* | cli: show gateway as a separate item in active connection data (bgo #739958)Jiří Klimeš2014-11-111-26/+24
| | | | | | | | | | | | | | | | | | | | | | | | Example (for active connection ethernet-13) $ nmcli -f active con show ethernet-13 ... IP4.ADDRESS[1]: 10.34.25.205/23 IP4.GATEWAY: 10.34.25.254 IP4.ROUTE[1]: dst = 10.38.5.26/32, nh = 0.0.0.0, mt = 20 ... https://bugzilla.gnome.org/show_bug.cgi?id=739958
View Lorry Controller Status