summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* tun,vxlan: add the CAP_IS_SOFTWARE capabilityBeniamino Galvani2016-06-272-0/+14
| | | | | | | | Software devices must report the NM_DEVICE_CAP_IS_SOFTWARE capability in order to be properly activated. Add the flag to NMDeviceTun and NMDeviceVxlan. https://bugzilla.gnome.org/show_bug.cgi?id=767846
* nmcli: when adding a vpn store the full service name in vpn-typeFrancesco Giudici2016-06-271-1/+12
| | | | | | When NM looks for vpn plugins, it would expect the full service name otherwise it will not be able to retrieve the correct plugin. Fixes VPN configurations generated with "nmcli connection add".
* cli: autocompletion: add missing log level and domainsBeniamino Galvani2016-06-271-2/+2
| | | | Add KEEP level and DHCP, IP, AUDIT, SYSTEMD, VPN_PLUGIN domains.
* wifi: fix stalls in scanningThomas Haller2016-06-251-0/+10
|\ | | | | | | https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00055.html
| * wifi: clear WiFi requested_scan if suppl exitsTony Espy2016-06-251-0/+5
| | | | | | | | | | | | | | | | It's possible for wpa_supplicant to exit with an outstanding requested_scan pending. This can lead to a stall condition where scanning no longer occurs. https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00117.html
| * wifi: clear WiFi requested_scan if suppl goes INACTIVETony Espy2016-06-251-0/+5
|/ | | | | | | | | | It's possible for wpa_supplicant to transition to INACTIVE state with an outstanding requested_scan pending. This can lead to a stall condition where scanning no longer occurs. [thaller@redhat.com: added break statement to avoid fall-through] https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00116.html
* platform: avoid crash after calling nl_recv() for old libnl3 versionThomas Haller2016-06-241-0/+7
| | | | | | | | | | | nl_recv() in libnl3 before version 3.2.15 would return dangling pointers if nl_recv() fails or has nothing to read [1]. Workaround that by explicitly clearing @buf and @creds. https://bugzilla.gnome.org/show_bug.cgi?id=767986 [1] https://github.com/thom311/libnl/commit/69468517d0de1675d80f24661ff57a5dbac7275c
* nmcli: fix ambiguous properties check for autocompletionFrancesco Giudici2016-06-231-3/+12
| | | | | | | | | | | | Re-enable the check on ambiguos properties but this time manage perfect matches (i.e., the full property name has been typed) that are prefix of other properties. Test case: nmcli --complete-args connection add type wifi wifi. Here "wifi" is a property alias that is also prefix of the property alias "wifi-sec".
* nmcli: manage autocompletion of "nmcli connection add" when no args are passedFrancesco Giudici2016-06-231-2/+6
| | | | This enables back "help" "--help" "-help" in autocompletion.
* po: sync translations from ZanataLubomir Rintel2016-06-2266-137730/+97864
|
* device: clearify behavior of NM_UNMANAGED_USER_SETTINGS in commentThomas Haller2016-06-222-2/+5
|
* nmcli: manage "--ask connection add" with no argsFrancesco Giudici2016-06-221-2/+2
| | | | | | | | | | When parsing arguments of "connection add" we first read the available property-value pairs and then check if the --ask option was passed in order to aid in the fill process of a new connection. Anyway, if there are no property-value tuples at all, we don't even check the --ask option, returning with error. Fix this just checking if any arg is there (argc) before invoking read_connection_properties().
* cli: don't free the completion string when a setting name is unambiguousLubomir Rintel2016-06-221-1/+1
| | | | | | | | | If we found that setting name prefix is in fact unambiguous and return the completion string for that setting we were freeing the string upon the return. That looks like a typo. Fixes "nmcli --complete-args add type wifi wifi." ^^^^ not ambiguous
* merge: branch 'lr/connection-add'fg/temp_oldLubomir Rintel2016-06-2112-5170/+1747
|\ | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=766427
| * cli: use --complete-args for connection add completionlr/connection-addLubomir Rintel2016-06-211-234/+2
| | | | | | | | And make it incredibly slow at the same time.
| * man: update the nmcli manual for new connection add syntaxLubomir Rintel2016-06-213-1279/+435
| | | | | | | | | | | | | | | | | | | | It allows us to clean up the nmcli "c add" section considerably. We list the old-fashioned aliases in a separate section that applies to both "nmcli c add" and "nmcli c modify". The section is now nicely cross-linked with nm-settings in HTML rendering.
| * nmcli: streamline connection additionLubomir Rintel2016-06-212-3621/+1274
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a huge refactoring in attempt to 1.) reduce the horrible redundancy in the connection addition path and 2.) reduce confusion between various sources of property value (command line, properties, interactive mode). * The conversions from the strings was done all over the place: settings.c already does for all sensible properties. The rest is removed. * The validations are done randomly and redundantly: server does some validation, and per-property client validations useful for interactive mode are done in settings.c The rest is removed. * The information about defaults and required options was redundantly scattered in per-type completion functions and interactive mode questionnaries. This is now driven by the option_info[] table. In general, we do our best to just map the command line options to properties and allow mixing them. For the rest there's the check_and_set() callbacks (basically to keep compatibility with previous nmcli versions). This this is now all possible: $ nmcli c add type ethernet ifname '*' This always worked $ nmcli c add type bond-slave save no -- connection.autoconnect no The "save" and "--" still work $ nmcli c add connection.type ethernet ifname eth0 Properties can now be used $ nmcli c add type ethernet ip4 1.2.3.4 mac 80:86:66:77:88:99 con-name whatever There's no implementation mandated order of the properties (the type still must be known to determine which properties make sense) $ nmcli --ask c add type ethernet ip4 1.2.3.4 mac 80:86:66:77:88:99 con-name whatever The interactive mode asks only for properties that weren't specified on command line
| * man: turn the manual page cross-references into linksLubomir Rintel2016-06-219-54/+54
|/ | | | | | | | This improves the HTML rendering. But it also causes a lot of non-resolvable linkends warning when rendering a separate manual pages into roff/mman. The messages are harmless, but still a bit ugly.
* libnm/libnm-glib: use Bluetooth device name as description (bgo #592819)Dan Williams2016-06-212-0/+20
| | | | | | | Abuse the 'name' property for this, for now, so we don't have to grab a free slot from NMDeviceClass. https://bugzilla.gnome.org/show_bug.cgi?id=592819
* nmlci merge branch 'fg/autocomplete_fix_rh1301226_with_LR_patches'Francesco Giudici2016-06-214-141/+331
|\ | | | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=724860 https://bugzilla.redhat.com/show_bug.cgi?id=1301226
| * nmcli: add support to shortnames for connection properties autocompletionfg/autocomplete_fix_rh1301226_with_LR_patchesFrancesco Giudici2016-06-211-26/+73
| |
| * nmcli: improve connection autocompletion (2/2)Lubomir Rintel2016-06-213-91/+158
| | | | | | | | | | | | | | | | Complete the property as we parse the list of properties. This makes it possible to actually complete an unfinished property. E.g: $ nmcli --complete c modify enp0s25 +ipv6.addr +ipv6.addresses +ipv6.addr-gen-mode
| * nmcli: improve connection autocompletion (1/2)Lubomir Rintel2016-06-211-5/+22
| | | | | | | | | | | | | | Make property autocompletion take a prefix and modifier flags. This will make it easier to complete an unfinished property name (possibly accompanied by a modifier) without shell trickery.
| * cli: streamline complete_connection_by_type() argumentsLubomir Rintel2016-06-211-74/+70
| | | | | | | | Will be useful to pass around the complete flag.
| * nmcli: enable connection autocompletion for 802.1x propertiesFrancesco Giudici2016-06-214-3/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | nmcli bash autocompletion leveraged on "nmcli connection edit", "print" to retrieve the specific properties of a connection. Anyway, the interactive editor is smart and just prints the used components, so in a connection where 802.1x is not enabled we had no autocompletion. Solved adding an "hidden" command "nmcli --complete connection modify" as suggested in bgo #724860 in order to retrieve ALL the available properties for use in autocompletion. Here patch from L.Rintel has been merged to make che --complete option global to nmcli (first version was local to "connection modify"). https://bugzilla.gnome.org/show_bug.cgi?id=724860 https://bugzilla.redhat.com/show_bug.cgi?id=1301226
| * nmcli autocompletion cleanupsFrancesco Giudici2016-06-211-15/+11
|/ | | | | | | | | | | * no need to check HELP_ONLY_AS_FIRST var as when --help option is passed _nmcli_compl_OPTIONS will return 0, falling in the general case that will trigger end of autocompletion * clanup local var declaration in _nmcli func: - remove dupliated OPTIONS_MANDATORY declaration - init HELP_ONLY_AS_FIRST on declaration - order vars for common prefix
* team: check return value of g_dbus_connection_call_sync()Beniamino Galvani2016-06-211-3/+11
| | | | | | | The call can fail; in such case assume that an existing teamd died and our instance will be able to continue. https://bugzilla.redhat.com/show_bug.cgi?id=1347015
* clients,vpn/trivial: rename argument of nm_vpn_get_secret_names()Thomas Haller2016-06-202-6/+6
|
* clients,vpn: only accept full service-types in nm_vpn_get_secret_names()Thomas Haller2016-06-201-4/+6
| | | | | | | | | | nm_vpn_get_secret_names() has only one caller, which passes nm_setting_vpn_get_service_type() as @vpn_type argument. That argument is not a short-name or abbreviation, it must be the full service-type. For our well-known, hard-coded list of service-types, all must start with the same prefix.
* clients: fix wrong assertion _assert_format_int()Thomas Haller2016-06-181-1/+1
| | | | Fixes: 2822f92434e19ebd25b69672bc996fc8311ae929
* all: merge branch 'th/g_strv_contrains'Thomas Haller2016-06-1720-92/+98
|\
| * all: replace _nm_utils_string_in_list() with g_strv_contains()Thomas Haller2016-06-1718-77/+60
| |
| * nm-glib: implement compatibility macro for g_strv_contains() differentlyThomas Haller2016-06-171-14/+7
| | | | | | | | | | | | Otherwise, deprecation warnings are not properly suppressed for g_return_if_fail (g_strv_contains (strv, str));
| * nm-glib: remove G_GNUC_EXTENSIONThomas Haller2016-06-172-17/+17
| | | | | | | | | | | | | | We use statement expressions all over the place without explicitly marking them. If that would be a problem, we'd have to change a *lot* of code. We simply require that as a mandatory feature from our compiler.
| * shared: backport g_strv_contains()Lubomir Rintel2016-06-171-0/+30
|/
* wwan: check at runtime whether to start ModemManagerDidier Raboud2016-06-173-10/+16
| | | | | | | | | | | | | This makes NetworkManager use runtime detection to manage the ModemManager lifecycle when not run by systemd. Under systemd, we expect the ModemManager service to be started by systemd, under non-systemd, we use the dbus activation feature to start ModemManager. [thaller@redhat.com: original patch heavily modified to check for available libsystemd library] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770871 https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00086.html
* platform: recognize rmnet and ccmni interfaces as WWAN network devicesDan Williams2016-06-171-0/+9
| | | | https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00087.html
* platform/trivial: rename NM_LINK_TYPE_WWAN_ETHERNET to NM_LINK_TYPE_WWAN_NETDan Williams2016-06-174-5/+5
| | | | | Some newer WWAN netdev types are "rawip" which don't bother with ethernet framing.
* logging: enable logging domain VPN_PLUGIN up to level <info>Thomas Haller2016-06-173-11/+25
| | | | | | | | | | | | | | | | | | | | | | | | The logging domain VPN_PLUGIN controlls logging of the VPN plugins. Especially at verbose levels <debug> and <trace>, the plugins might reveal sensitive information in the logging. Thus, this level should not be enabled by a $ nmcli logging general level DEBUG domains ALL It should only be enabled when requested explicitly. $ nmcli logging general level DEBUG domains ALL,VPN_PLUGIN:DEBUG Previously, the special level VPN_PLUGIN was entirely excluded from ALL and DEFAULT domains and it was entirely disabled by default. That is however to strict, as it completely silences the VPN plugins by defult. Now, enable them by default up to level INFO. VPN plugins should take care that they don't reveal sensitive information at levels <info> (LOG_NOTICE) and higher (less verbose). For more verbose levels they may print passwords, but that should still be avoided as far as possible.
* shared: add also "shared/nm-utils/nm-vpn-plugin-macros.h"Thomas Haller2016-06-162-0/+44
| | | | | It has the very similar purpose as "nm-utils/nm-vpn-plugin-utils.[ch]", except that is is header-only.
* tests: fix checking NM_ASSERT_NO_MSG define in "nm-test-utils.h"Thomas Haller2016-06-161-1/+1
| | | | | "nm-test-utils.h" may also be used by the VPN plugins, there we have no NM_ASSERT_NO_MSG define.
* shared: merge branch 'th/shared-bgo767697'Thomas Haller2016-06-1635-37/+238
|\ | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=767697
| * shared/tests: build "nm-utils/nm-vpn-plugin-utils.c"th/shared-bgo767697Thomas Haller2016-06-161-0/+24
| | | | | | | | For testing, add a build target to build those files too.
| * shared: include "nm-glib.h" from "nm-macros-internal.h"Thomas Haller2016-06-162-2/+3
| | | | | | | | | | "nm-glib.h" is our most basic header. "nm-macros-internal.h" extends on that. Thus, let "nm-macros-internal.h" include "nm-glib.h".
| * shared: include "gsystem-local-alloc.h" from "nm-glib.h"Thomas Haller2016-06-163-2/+2
| | | | | | | | | | | | | | | | | | "nm-glib.h" is the most basic header, the one we cannot do without. ("nm-default.h", is already more generic, the one which every common source file in NetworkManager repository should include). Let "gsystem-local-alloc.h" be included by "nm-glib.h" and nowhere else.
| * shared: add "nm-utils/nm-vpn-plugin-utils.h"Thomas Haller2016-06-164-0/+175
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This file is only used by plugins and copied between them. It's purpose is to contain general utility functions that are only relevant for implementing NetworkManager's VPN plugins. In principle the utility functions could be part of libnm, however, there are a few problems with that: - if they are part of libnm, adding and using a new utility function requires the plugin to bump the required libnm version. Since you usally can work around/reimplement utility functions, this results in not using the API from libnm, not adding the API to libnm, and reimplementing it over and over in the plugin. - plugins compile both against libnm and libnm-glib. Thus, either the utility function would also be needed in libnm-glib, or again, it is not usable by the plugin. We must avoid that the utility functions diverge and no local modifications to these files should be made in the plugin. Instead, one special location of the utility functions shall be extended and re-imported (copied) to the plugin as needed. Add the files to NetworkManager's repository. Although they are not needed for NetworkManager itself, they are a different API provided by NetworkManager. An API that is reused and shared by copying the files around.
| * shared: move shared files to subdirectory "shared/nm-utils/"Thomas Haller2016-06-1632-36/+37
|/ | | | | | | | | | | | | The "shared" directory contains files that are possibly used by all components of NetworkManager repository. Some of these files are even copied as-is to other projects (VPN plugins, nm-applet) and used there without modification. Move those files to a separate directory. By moving them to a common directory, it is clearer that they belong together. Also, you can easier compare the copied versions to their original via $ diff -r ./shared/nm-utils/ /path/to/nm-vpn-plugin/shared/nm-utils/
* libnm/vpn,cli: merge branch 'th/vpn-service-info-bgo767197'Thomas Haller2016-06-1516-147/+668
|\ | | | | | | https://bugzilla.gnome.org/show_bug.cgi?id=767197
| * libnm/vpn: add nm_vpn_editor_plugin_load_vt()Thomas Haller2016-06-157-1/+260
| | | | | | | | | | | | | | | | | | | | Let VPN plugins return a virtual function table to extend the API while bypassing libnm. This allows to add and use new functionality to VPN plugins without updating libnm. The actual definitions are in a header-only file "nm-vpn-editor-plugin-call.h", which can be copied to the caller/plugin.
| * libnm/vpn: pass NMVpnPluginInfo to the NMVpnEditorPlugin instanceThomas Haller2016-06-155-1/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The NMVpnPluginInfo is essentially the .name file, that is, a configuration file about the plugin itself. Via NMVpnPluginInfo instance, the NMVpnEditorPlugin can be created. Usually, one would create a NMVpnPluginInfo (that is, reading the .name file) and then create a NMVpnEditorPlugin instance from there. In this case, usually the editor-plugin is owned by the plugin-info instance (although the API allows for creating the editor-plugin independently). Now, pass the NMVpnPluginInfo to the editor-plugin too. This is useful, because then the editor-plugin can look at the .name file. The .name file is not user configuration. Instead it is configuration about the plugin itself. Although the .name file is part of the plugin build artefacts, it is useful to allow the plugin to access the .name file. The reason is, that this can allow the user to easily change a configuration knob of the plugin without requiring to patch or the plugin.
View Lorry Controller Status