'ssid' can repeat when more SSIDs should be scanned, e.g.
$ nmcli dev wifi rescan ssid "hidden cafe" ssid AP12 ssid "my home Wi-Fi"
Bash completion fixed by thaller@redhat.com
(cherry picked from commit e247567d87)
We have a hack to extend GKeyFile to support specifying an 'option+'
key. Also add support for 'option-'.
Options that make use of these modifiers can only be string lists.
So do the concatenation not based on plain strings, but by treating
the values as string lists. Also, don't add duplicates.
(cherry picked from commit fab5c6a372)
We support the "NetworkManager.conf" sections '[connection]' and
'[connection.\+]' (with arbitrary suffix).
Fix the order of how we evaluate these section.
Note that the literal '[connection]' section is always evaluated lastly
after any other '[connection.\+]' section.
Within one file, we want to evaluate the sections in top-to-bottom
order. But accross multiple files, we want to order them
later-files-first. That gives a reasonable behavior if the user
looks at one file, and also if he wants to overwrite configuration
via configuration snippets like "conf.d/99-last.conf".
Note that if a later file extends/overwrites a section defined in an
earlier file, the section is still considered with lower priority
This is intentional, because the user ~extends~ a lower priority
section. If he wants to add a higher priority section, he should
choose a new suffix.
Fixes: dc0193ac02
(cherry picked from commit f8c9863d55)
Since introduction for support of ip6-privacy (use_tempaddr,
RFC4941) with commit d376270bfe,
the sysctl value from /etc was always read first.
This is problematic, because an explicit setting in the
connection should not be ignored over a global configuration.
Drop that old behavior. It was also problematic, because we did
not read any files under /etc/sysctl.d (except for sysctl.conf).
Also, we did not honor per-interface configurations.
Now we also use as last fallback the value from
/proc/sys/net/ipv6/conf/default/use_tempaddr
That has the advantage of falling back to the system default value
so that NM doesn't need to have it's own default policy
(Related: https://bugzilla.redhat.com/show_bug.cgi?id=1187525).
This is a change in behavior.
(cherry picked from commit f3c61f8141)
Support default value for setting 'ipv6.ip6-privacy' in
NetworkManager.conf.
If the global value is unset, preserve old behavior of looking into
/etc/sycctl.conf first. That behavior was introduced with commit
d376270bfe, since we support ip6-privacy
setting.
If the global value is set to "unknown", add a new fallback
that instead reads the runtime value from
"/proc/sys/net/ipv6/conf/default/use_tempaddr"
This seems more sensible behavior because we fallback to sysctl,
but instead of looking at static files in /etc, read /proc.
But to preserve the old behavior, we only do that when a global
value is configured at all.
https://bugzilla.gnome.org/show_bug.cgi?id=721200
(cherry picked from commit e729dd70ae)
The route-metric can be configured per connection via the
ipv4.route-metric and ipv6.route-metric fields. When the
value is left at -1 (the default), we would determine the
route-metric based on the device type (nm_device_get_priority()).
Extend that scheme by making the default value overwritable in
NetworkManager.conf.
(cherry picked from commit 59a991725a)
Add support for a new section [connection] in NetworkManager.conf.
If the connection leaves an option at "unknown"/"default", we can
support overwriting the value from global configuration.
We also support other sections that are named with "connection"
as a prefix, such as [connection2], [connection-wifi]. This is
to support multiple default values that can be applied depending
on the used device.
I think this has great potential. Only downside is that when
the user looks at a connection value, it will see that it is
unspecified. But the actually used value depends on the device
type and might not be obvious.
https://bugzilla.gnome.org/show_bug.cgi?id=695383https://bugzilla.redhat.com/show_bug.cgi?id=1164677
(cherry picked from commit dc0193ac02)
Support a device-spec to match by device-type.
This matches on the value as shown by
nmcli -f GENERAL.TYPE device show
(cherry picked from commit 3fb60edf9f)
Some out of tree drivers add Ethernet devices that are supposed to be managed
by other their tooling, e.g. VirtualBox or VMWare.
Rather than hardcoding their drivers (at least VirtualBox doesn't even set a
"driver" property in sysfs) or hardcoding a logic that identifies such devices
let's just add a possibility to blacklist them in udev. This makes it possible
for whoever who ships such a driver to ship rules that prevent NetworkManager
from managing the device itself.
Furthermore it makes it possible for the user with special needs leverage the
flexibility of udev rules to override the defaults. In the end the user can
decide to let NetworkManager manage default-unmanaged interfaces such as VEth
or turn on default-unmanaged for devices on a particular bus.
An udev rule for VirtualBox would look like this:
SUBSYSTEM=="net", ENV{INTERFACE}=="vboxnet[0-9]*", ENV{NM_UNMANAGED}="1"
(cherry picked from commit 85ee1f4a9c)
NetworkManager only responds to the last D-Bus call when called delete/down
for the same connection in quick succession. (It should be fixed later).
So do not issue the call multiple times to prevent that. Otherwise nmcli would
stall waiting for the response.
https://bugzilla.redhat.com/show_bug.cgi?id=1168657
(cherry picked from commit f52e6bbdda)
Add the new configuration option 'assume-ipv6ll-only' which specifies
the devices for which NM will try to assume an existing IPv6LL-only
configuration.
The new default behavior is to ignore such configurations since IPv6LL
addresses are automatically assigned by the kernel when the device is
brought up and thus the presence of an IPv6LL address doesn't mean
that the device was configured by the administrator.
The previous behavior was to always assume IPv6LL-only configurations
but this often had the unwanted effect of preventing other on-disk
configurations to be activated. To preserve the old behavior the
option must be set to '*'.
https://bugzilla.redhat.com/show_bug.cgi?id=1138426
(cherry picked from commit 3bc097b084)
NM already understands the command line argument --g-fatal-warnings
which causes setting of g_log_set_always_fatal().
Also interpret the "fatal-warnings" token in NM_DEBUG environment
variable and in main.debug configuration setting.
Usage hint: either set
$ export NM_DEBUG=RLIMIT_CORE,fatal-warnings
or add the following section to NetworkManager.conf
[main]
debug=RLIMIT_CORE,fatal-warnings
https://mail.gnome.org/archives/networkmanager-list/2015-March/msg00093.html
(cherry picked from commit 10cde91f10)
If we have ENABLE_GTK_DOCS, but not BUILD_SETTING_DOCS, nm-settings.5
nm-settings-keyfile.5 and nm-settings-ifcfg-rh.5 would not be installed.
(It happened on RHEL 7 build, due to missing BuildRequires: pygobject3-base)
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.
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.)
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
Synopsis:
nmcli agent { secret | polkit | all }
The command runs separate NetworkManager secret agent or session polkit agent, or both.
It is useful when
- no other secret agent is available (such as GUI nm-applet, gnome-shell, KDE applet)
- no other polkit agent is available (such as polkit-gnome-authentication-agent-1,
polkit-kde-authentication-agent-1 or lxpolkit)
https://bugzilla.gnome.org/show_bug.cgi?id=739568
It is useful for running nmcli without --ask option, i.e. non-interactively.
Example contents of the file:
wifi.psk: s e c r e t 12345
802-1x.password:kili manjaro
802-1x.pin:987654321
It can be used to display connection secrets (passwords). When used, it will
get secrets for the connection profile and merge it into the connection's
settings before displaying it.
Example:
nmcli con show -s hotel-wifi
Only default (infrastructure) mode connections can be created and as it's not
possible to write mode=ap connections with ifcfg-rh plugins, they can't be
switched to mode=ap.
This makes NetworkManager independent of <polkit/polkit.h>
development headers and libpolkit-gobject-1.so library.
Instead communicate directly with polkit using its DBUS
interface.
PolicyKit support is now always compiled in. You can control
polkit authorization with the configuration option
[main]
auth-polkit=yes|no
If the configure option is omitted, a build time default
value is used. This default value can be set with the
configure option --enable-polkit.
This commit adds a new class NMAuthManager that reimplements the
relevant DBUS client parts. It takes source code from the polkit
library.
https://bugzilla.gnome.org/show_bug.cgi?id=734146
Signed-off-by: Thomas Haller <thaller@redhat.com>
man/nm-settings-keyfile.xml is generated via an XSLT stylesheet applied to
libnm-util/nm-keyfile-docs.xml. Then a manual page is generated from the XML.
