If the spec specifies only negative matches (and none of them matches),
then the result shall be positive.
Meaning:
[connection*] match-device=except:dhcp-plugin:dhclient
[connection*] match-device=except:interface-name:eth0
[.config] enabled=except:nm-version:1.14
should be the same as:
[connection*] match-device=*,except:dhcp-plugin:dhclient
[connection*] match-device=*,except:interface-name:eth0
[.config] enabled=*,except:nm-version:1.14
and match by default. Previously, such specs would never yield a
positive match, which seems wrong.
Note that "except:" already has a special meaning. It is not merely
"not:". That is because we don't support "and:" nor grouping, but all
matches are combined by an implicit "or:". With such a meaning, having
a "not:" would be unclear to define. Instead it is defined that any
"except:" match always wins and makes the entire condition to explicitly
not match. As such, it makes sense to treat a match that only consists
of "except:" matches special.
This is a change in behavior, but the alternative meaning makes
little sense.
If the user disabled systemd-resolved, two things seem apparent:
- the user does not want us to use systemd-resolved
- NetworkManager is not pushing the DNS configuration to
systemd-resoved.
It seems to me, we should not consult systemd-resolved in that case.
Try to locate an existing connection before creating a new one when
handling "nmcli device wifi connect". This allows WPA-Enterprise
networks to be activated this way, consistent with the comment that this
command is equivalent to clicking on an SSID in a GUI client.
Add a new CON_DEFAULT() macro that places a property name into a
special section used at runtime to check whether it is a supported
connection default.
Unfortunately, this mechanism doesn't work for plugins so we have to
enumerate the connection defaults from plugins in the daemon using
another CON_DEFAULT_NOP() macro.
Correct the spelling across the *entire* tree, including translations,
comments, etc. It's easier that way.
Even the places where it's not exposed to the user, such as tests, so
that we learn how is it spelled correctly.
Manually disconnecting a profile of course blocks autoconnect of the
same profile. Otherwise, the profile would likely re-activate right
away, which is clearly against the users intention. If the users just
want to re-activate the profile, they should issue `nmcli connection up`
instead, with does a full down and up cycle.
This is more interesting for profiles that have 'connection.multi-connect'
set to 'multiple'. Would you expect that manually deactivating such a
profile blocks autoconnect of the profile on all devices? Maybe
yes, maybe not. Currently that is indeed the case and autoconnect gets
blocked regardless of multi-connect.
The need for this is the following:
"ipv4.dhcp-client-id" can be specified via global connection defaults.
In absence of any configuration in NetworkManager, the default depends
on the DHCP client plugin. In case of "dhclient", the default further
depends on /etc/dhcp.
For "internal" plugin, we may very well want to change the default
client-id to "mac" by universally installing a configuration
snippet
[connection-use-mac-client-id]
ipv4.dhcp-client-id=mac
However, if we the user happens to enable "dhclient" plugin, this also
forces the client-id and overrules configuration from /etc/dhcp. The real
problem is, that dhclient can be configured via means outside of NetworkManager,
so our defaults shall not overwrite defaults from /etc/dhcp.
With the new device spec, we can avoid this issue:
[connection-dhcp-client-id]
match-device=except:dhcp-plugin:dhclient
ipv4.dhcp-client-id=mac
This will be part of the solution for rh#1640494. Note that merely
dropping a configuration snippet is not yet enough. More fixes for
DHCP will follow. Also, bug rh#1640494 may have alternative solutions
as well. The nice part of this new feature is that it is generally
useful for configuring connection defaults and not specifically for
the client-id issue.
Note that this match spec is per-device, although the plugin is selected
globally. That makes some sense, because in the future we may or may not
configure the DHCP plugin per-device or per address family.
https://bugzilla.redhat.com/show_bug.cgi?id=1640494
Quote from `man NetworkManager.conf`:
When the default wired connection is deleted or saved to a new
persistent connection by a plugin, the device is added to a list in the
file /run/NetworkManager/no-auto-default.state to prevent creating
the default connection for that device again.
"/run" is obviously wrong. Fix it.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/33
Already since 1.0.0 release and commit "3784678177 cli: create a connection
if none exist in 'nmcli dev connect' (rh #1113941)", device-connect can
also create a profile.
That is useful, in particular as opposed to
$ nmcli connection up ifname "$DEVICE"
which wouldn't create a profile (ever).
Document it.
We need to copy all introspection files to the same directory when
building the documentation.
Note that we only require Meson 0.44, but for the documentation at
least 0.46 is needed because of a new functionality of
gnome.gdbus_codegen(). In this way we can still build on Travis CI
(without documentation).
Even when the system resolver is configured to something else that
systemd-resolved, it still is a good idea to keep systemd-resolved up to
date. If not anything else, it does a good job at doing per-interface
resolving for connectivity checks.
If for whatever reasons don't want NetworkManager to push the DNS data
it discovers to systemd-resolved, the functionality can be disabled
with:
[main]
systemd-resolved=false
When a DNS plugin is enabled (like "main.dns=dnsmasq" or "main.dns=systemd-resolved"),
the name servers announced to the rc-manager are coerced to be 127.0.0.1
or 127.0.0.53.
Depending on the "main.rc-manager" setting, also "/etc/resolv.conf"
contains only this coerced name server to the local caching service.
The same is true for "/var/run/NetworkManager/resolv.conf" file, which
contains what we would write to "/etc/resolv.conf" (depending on
the "main.rc-manager" configuration).
Write a new file "/var/run/NetworkManager/no-stub-resolv.conf", which contains
the original name servers, uncoerced. Like "/var/run/NetworkManager/resolv.conf",
this file is always written.
The effect is, when one enables "main.dns=systemd-resolved", then there
is still a file "no-stub-resolv.conf" with the same content as with
"main.dns=default".
The no-stub-resolv.conf may be a possible solution, when a user wants
NetworkManager to update systemd-resolved, but still have a regular
/etc/resolv.conf [1]. For that, the user could configure
[main]
dns=systemd-resolved
rc-manager=unmanaged
and symlink "/etc/resolv.conf" to "/var/run/NetworkManager/no-stub-resolv.conf".
This is not necessarily the only solution for the problem and does not preclude
options for updating systemd-resolved in combination with other DNS plugins.
[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/20
nm-initrd-generator scans the command line for options relevant to network
configuration and creates configuration files for an early instance of
NetworkManager run from the initial ramdisk during early boot.
"debug" was documentation in `man NetworkManager.conf` as a valid
logging backend. However, it was completely ignored by
nm_logging_syslog_openlog().
In fact, it makes not sense. Passing debug = TRUE to
nm_logging_syslog_openlog(), means that all messages will be
printed to stderr in addition to syslog/journal. However, when
NetworkManager is daemonizing, stderr is closed.
Whether NetworkManager is daemonizing depends entirely on command
line options --no-daemon and --debug. Hence, the logging backend "debug"
from the configuration file either conflicts or is redundant.
Also, adjust logging backend description in `man NetworkManager.conf`.
Also, log a warning about invalid/unsupported logging backend.
Previously, the action was only passed as the first command line
argument to the dispatcher scripts. Now, also set it via the
"$NM_DISPATCHER_ACTION" environment variable.
The main purpose is to have a particular, nm-dispatcher specific
variable that is always set inside the dispatcher scripts.
For example, imagine you have a script that can be either called by
dispatcher or some other means (manually, or spawned via
/etc/NetworkManager/dispatcher.d/11-dhclient). Then it might make
sense to differenciate from inside the script whether you are called
by nm-dispatcher. But previously, there was no specific environment
variable that was always set inside the dispatcher event. For example,
with the "hostname" action there are no other environment variables.
Now (with version 1.12), you can check for `test -n "$NM_DISPATCHER_ACTION"`.
allow to specify the DUID to be used int the DHCPv6 client identifier
option: the dhcp-duid property accepts either a hex string or the
special values "lease", "llt", "ll", "stable-llt", "stable-ll" and
"stable-uuid".
"lease": give priority to the DUID available in the lease file if any,
otherwise fallback to a global default dependant on the dhcp
client used. This is the default and reflects how the DUID
was managed previously.
"ll": enforce generation and use of LL type DUID based on the current
hardware address.
"llt": enforce generation and use of LLT type DUID based on the current
hardware address and a stable time field.
"stable-ll": enforce generation and use of LL type DUID based on a
link layer address derived from the stable id.
"stable-llt": enforce generation and use of LLT type DUID based on
a link layer address and a timestamp both derived from the
stable id.
"stable-uuid": enforce generation and use of a UUID type DUID based on a
uuid generated from the stable id.
With "main.rc-manager=file", if /etc/resolv.conf is a symlink, NetworkManager
would follow the symlink and update the file instead.
However, note that realpath() only returns a target, if the file actually
exists. That means, if /etc/resolv.conf is a dangling symlink, NetworkManager
would replace the symlink with a file.
This was the only case in which NetworkManager would every change a symlink
resolv.conf to a file. I think this is undesired behavior.
This is a change in long established behavior. Although note that there were several
changes regarding rc-manager settings in the past. See for example commit [1] and [2].
Now, first still try using realpath() as before. Only if that fails, try
to resolve /etc/resolv.conf as a symlink with readlink().
Following the dangling symlink is likely not a problem for the user, it
probably is even desired. The part that most likely can cause problems
is if the destination file is not writable. That happens for example, if
the destination's parent directories are missing. In this case, NetworkManager
will now fail to write resolv.conf and log a warning. This has the potential of
breaking existing setups, but it really is a mis-configuration from the user's
side.
This fixes for example the problem, if the user configures
/etc/resolv.conf as symlink to /tmp/my-resolv.conf. At boot, the file
would not exist, and NetworkManager would previously always replace the
link with a plain file. Instead, it should follow the symlink and create
the file.
[1] 718fd22436
[2] 15177a34behttps://github.com/NetworkManager/NetworkManager/pull/127
It's not clear whether this was desired behavior. However, it was
behavior for a long time, so we probably should not change it.
Just document what happens with dangling symlinks.
The present version of the specification is somewhat unclear at times,
Unclear points were discussed with the maintainers [1] and probably
some new version will address those.
https://www.spinics.net/lists/util-linux-ng/msg15222.html
Until then here's how the implementation copes with ambiguities
(after the discussion with util-linux maintainers):
1.) It is unclear whether multiple .schem files should override each
other or be merged. We use the overriding behavior -- take the
highest priority one and ignore the rest.
2.) We assume "name.schem" is more specific than "@term.schem".
3.) We assume the "Color name" are to be used as aliases for the color
sequences and translate them to ANSI escape sequences.
4.) The "Escape sequences" are of no use since the specification
pretty much assumes an ANSI terminal and none of the sequences make
any sense in ANSI color codes. We don't support them.
accept that.
5.) We don't implement TERMINAL_COLORS_DEBUG because it's unspecified
what should it do.
The connection.mdns setting is a per-connection setting,
so one might expect that one activated device can only have
one MDNS setting at a time.
However, with certain VPN plugins (those that don't have their
own IP interface, like libreswan), the VPN configuration is merged
into the configuration of the device. So, in this case, there
might be multiple settings for one device that must be merged.
We already have a mechanism for that. It's NMIP4Config. Let NMIP4Config
track this piece of information. Although, stricitly speaking this
is not tied to IPv4, the alternative would be to introduce a new
object to track such data, which would be a tremendous effort
and more complicated then this.
Luckily, NMDnsManager and NMDnsPlugin are already equipped to
handle multiple NMIPConfig instances per device (IPv4 vs. IPv6,
and Device vs. VPN).
Also make "connection.mdns" configurable via global defaults in
NetworkManager.conf.
Even Gentoo disables this plugin since before 0.9.8 release
of NetworkManager. Time to say goodbye.
If somebody happens to show up to maintain it, we may resurrect it
later.
If "$distro_plugins=ifnet" was set, configure.ac would use that
to autodetect --with-hostname-persist=gentoo. Replace that autodetect
part by checking for /etc/gentoo-release file.
The number of authentication retires is useful also for passwords aside
802-1x settings. For example, src/devices/wifi/nm-device-wifi.c also has
a retry counter and uses a hard-coded value of 3.
Move the setting, so that it can be used in general. Although it is still
not implemented for other settings.
This is an API and ABI break.
We added "ipv4.route-table-sync" and "ipv6.route-table-sync" to not change
behavior for users that configured policy routing outside of NetworkManager,
for example, via a dispatcher script. Users had to explicitly opt-in
for NetworkManager to fully manage all routing tables.
These settings were awkward. Replace them with new settings "ipv4.route-table"
and "ipv6.route-table". Note that this commit breaks API/ABI on the unstable
development branch by removing recently added API.
As before, a connection will have no route-table set by default. This
has the meaning that policy-routing is not enabled and only the main table
will be fully synced. Once the user sets a table, we recognize that and
NetworkManager manages all routing tables.
The new route-table setting has other important uses: analog to
"ipv4.route-metric", it is the default that applies to all routes.
Currently it only works for static routes, not DHCP, SLAAC,
default-route, etc. That will be implemented later.
For static routes, each route still can explicitly set a table, and
overwrite the per-connection setting in "ipv4.route-table" and
"ipv6.route-table".
- clearify in the manual page that setting retry to 1 means to try
once, without retry.
- log the initially set retry value in nm_settings_connection_get_autoconnect_retries().
- use nm_settings_connection_get_autoconnect_retries() in
nm_settings_connection_can_autoconnect().
We already have various ways to mark a device as unmanaged.
1) via udev-rule ENV{NM_UNMANAGED}. This can be overwritten via D-Bus
at runtime.
2) via settings plugin. That is NM_CONTROLLED=no for ifcfg-rh and
keyfile.unmanaged-devices in NetworkManager.conf.
3) at runtime, via D-Bus. This is persisted in the run state file
and persists restarts (but not reboot).
This adds another way via NetworkManager.conf file. Note that the
existing keyfile.unmanaged-devices (above 2) is also a configuration
optin in NetworkManager.conf. However it has various downsides:
- it cannot be overwritten at runtime (see commit
c210134bd5).
- you can only explicitly mark a device as unmanaged. That means,
you cannot use it to manage a device which is unmanaged due to
a udev rule.
- the name "keyfile.*" sounds like it's only relevant for the keyfile settings
plugin. Nowadays the keyfile plugin is always loaded, so the option applies
to NetworkManager in general.
https://github.com/NetworkManager/NetworkManager/pull/29
We currently don't support marking a device a managed/unmanaged via
the [device] section. Eventually, I think we should, because the
existing "keyfile.unmanaged-devices" looks keyfile specific (which
it isn't). But more importantly, "keyfile.unmanaged-devices" sets the
unmanaged flag NM_UNMANAGED_USER_SETTINGS, which cannot be overruled
via D-Bus (see commit c210134bd5).
A device.managed flag would make sense for a more sensible way to
express configuration in NetworkManager.conf, which still can be
overwritten via D-Bus.
Anyway, it's not yet implemented. Fix the example.
- cleanup data type and use guint32 consistently. We might want to
introduce a new "infinity" value. But since libnm's
NM_SETTING_IP_CONFIG_DHCP_TIMEOUT asserts against the range
0 - G_MAXINT32, we cannot express it as -1 anyway. So, infinity
will have the numerical value G_MAXINT32, hence guint32 is just
fine.
- make use of existing ipv6.dhcp-timeout setting and add global
default configuration in NetworkManager.conf
- instead of having subclasses call nm_device_set_dhcp_timeout(),
add a virtual function get_dhcp_timeout().
For master devices, instead of ignoring loss of carrier entirely,
handle it.
First of all, master devices are now by default ignore-carrier=yes.
That means, without explict user configuration in NetworkManager.conf,
the previous behavior in carrier_changed() does not change.
If the user decides to configure the master device like
[device-with-carrier]
match-device=type:bond,type:bridge,type:team
ignore-carrier=no
then, master device will disconnect on carrier loss like
regular devices.
https://github.com/NetworkManager/NetworkManager/pull/18
Co-authored-by: Thomas Haller <thaller@redhat.com>
Since commit 2b51d3967 "device: merge branch 'th/device-mtu-bgo777251'",
we always set the MTU for certain device types during activation. Even
if the MTU is neither specified via the connection nor other means, like
DHCP.
Revert that change. On activation, if nothing explicitly configures the
MTU, leave it unchanged. This is like what we do with ethernet's
cloned-mac-address, which has a default value "preserve".
So, as last resort the default value for MTU is now 0 (don't change),
instead of depending on the device type.
Note that you also can override the default value in global
configuration via NetworkManager.conf.
This behavior makes sense, because whenever NM actively resets the MTU,
it remembers the previous value and restores it when deactivating
the connection. That wasn't implemented before 2b51d3967, and the
MTU would depend on which connection was previously active. That
is no longer an issue as the MTU gets reset when deactivating.
https://bugzilla.redhat.com/show_bug.cgi?id=1460760
Commits 39d0559d9a ("platform: sort links by name instead of
ifindex") and 529a0a1a7f ("manager: sort slaves to be autoconnected
by device name") changed the order of activation of slaves. Introduce
a system-wide configuration property to preserve the old behavior.
https://bugzilla.redhat.com/show_bug.cgi?id=1452585
Now that we have a PMF connection property, get rid of the previous
code to globally enable/disable PMF and use the 'ieee80211w'
configuration option for each configured network when the supplicant
supports it.
Otherwise, substitions are not properly expanded.
For example
- "AC_SUBST(nmrundir, '${runstatedir}'/$PACKAGE, [NetworkManager runtime state directory])"
gives ${runstatedir}/NetworkManager/resolv.conf
- "AC_SUBST(nmrundir, "${runstatedir}/$PACKAGE", [NetworkManager runtime state directory])"
gives ${prefix}/var/run/NetworkManager/resolv.conf
The purpose of "rc-manager=symlink" is so that the administrator can point
the "/etc/resolv.conf" as a symlink to a certain file, and thus indicating
that a certain component is responsible to manage resolv.conf, while others
should stay away from it.
For example, systemd-resolved never touches "/etc/resolv.conf", but
expects the admin to setup the symlink appropriately. It also recognizes
whether the symlink points to it's own resolv.conf in /run or to another
component.
Previously, "rc-manager=symlink" would always replace a regular file
with a symlink to "/var/run/NetworkManager/resolv.conf". Only if
"/etc/resolv.conf" is already a symlink somewhere else, NM would not
touch it. This with the exception that if "/etc/resolv.conf" points to
"/var/run/NetworkManager/resolv.conf", it would replace the symlink
with the same link to raise inotify events.
Change behavior so if "/etc/resolv.conf" is already a regular file, keep
it as file.
This means, if you have multiple components that don't care, everybody
can write the "/etc/resolv.conf" (as file) and there is no clear
expressed responsibility.
It was wrong that NetworkManager would convert the file to a symlink,
this should be reserved to the admin. Instead, NetworkManager should
accept that the intent is unspecified and preserve the regular file.
It's up to the admin to replace the symlink to somewhere else (to keep
NM off), or to point it to "/var/run/NetworkManager/resolv.conf", to show
the explicit intent.
The wrong behavior causes dangling symlinks when somebody disables
NetworkManager for good.
https://bugzilla.redhat.com/show_bug.cgi?id=1367551
This allows a user to restore the previous behavior where NetworkManager
would not reconfigure the MTU during device activation, if no MTU is
available (commit "22e8af6 device: set a per-device default MTU on
activation").
Well, not exactly. The previous behavior was to use per-connection
configuration, then DHCP provided value, or finally leave the MTU
unspecified.
Now, we prefer a per-connection configuration, followed by a global
connection default. If "ethernet.mtu=0", the MTU is left unspecified.
In absense of a global connection default, the value from DHCP is used
or finally a per-device-type default. That is effectively 1500 for most
types, except for infiniband where the MTU is still left unspecified.
Usecase: when connecting to a public Wi-Fi with MAC address randomization
("wifi.cloned-mac-address=random") you get on every re-connect a new
IP address due to the changing MAC address.
"wifi.cloned-mac-address=stable" is the solution for that. But that
means, every time when reconnecting to this network, the same ID will
be reused. We want an ID that is stable for a while, but at a later
point a new ID should e generated when revisiting the Wi-Fi network.
Extend the stable-id to become dynamic and support templates/substitutions.
Currently supported is "${CONNECTION}", "${BOOT}" and "${RANDOM}".
Any unrecognized pattern is treated verbaim/untranslated.
"$$" is treated special to allow escaping the '$' character. This allows
the user to still embed verbatim '$' characters with the guarantee that
future versions of NetworkManager will still generate the same ID.
Of course, a user could just avoid '$' in the stable-id unless using
it for dynamic substitutions.
Later we might want to add more recognized substitutions. For example, it
could be useful to generate new IDs based on the current time. The ${} syntax
is extendable to support arguments like "${PERIODIC:weekly}".
Also allow "connection.stable-id" to be set as global default value.
Previously that made no sense because the stable-id was static
and is anyway strongly tied to the identity of the connection profile.
Now, with dynamic stable-ids it gets much more useful to specify
a global default.
Note that pre-existing stable-ids don't change and still generate
the same addresses -- unless they contain one of the new ${} patterns.
nmcli has a heuristic when setting the team-config to accepting both
a filename or the plain json text.
Add support for two schemes "file://" and "json://" to explicitly
determine whether to read from file or from json.
Also, no longer silently ignore an all-whitespace word. That is an
error (unless you have a file named " ").
Also, no longer replace newlines with space. Don't mangle the input
text at all.
It's potentially unexpected by user that dnsmasq works differently
from the libc resolver and doesn't try the servers in order. Add a
paragraph to explain that and how to tweak the resolution order.
Long ago before commit 1b49f94, NetworkManager did not touch the
MAC address at all. Since 0.8.2 NetworkManager would modify the
MAC address, and eventually it would reset the permanent MAC address
of the device.
This prevents a user from externally setting the MAC address via tools
like macchanger and rely on NetworkManager not to reset it to the
permanent MAC address. This is considered a security regression in
bgo#708820.
This only changed with commit 9a354cd and 1.4.0. Since then it is possible
to configure "cloned-mac-address=preserve", which instead uses the "initial"
MAC address when the device activates.
That also changed that the "initial" MAC address is the address which was
externally configured on the device as last. In other words, the
"initial" MAC address is picked up from external changes, unless it
was NetworkManager itself who configured the address when activating a
connection.
However, in absence of an explicit configuration the default for
"cloned-mac-address" is still "permanent". Meaning, the user has to
explicitly configure that NetworkManager should not touch the MAC address.
It makes sense to change the upstream default to "preserve". Although this
is a change in behavior since 0.8.2, it seems a better default.
This change has the drastic effect that all the existing connections
out there with "cloned-mac-address=$(nil)" change behavior after upgrade.
I think most users won't notice, because their devices have the permanent
address set by default anyway. I would think that there are few users
who intentionally configured "cloned-mac-address=" to have NetworkManager
restore the permanent address.
https://bugzilla.gnome.org/show_bug.cgi?id=770611
Without this, it reads:
See the section called “Sections” for details.
but there are multiple sections called “Sections” and it should
explicitly refer to the one from the other top-level section.
With this change, it reads:
See “Sections” under the section called “CONNECTION SECTION” for details.
For the per-connection settings "ethernet.cloned-mac-address"
and "wifi.cloned-mac-address", and for the per-device setting
"wifi.scan-rand-mac-address", we may generate MAC addresses using
either the "random" or "stable" algorithm.
Add new properties "generate-mac-address-mask" that allow to configure
which bits of the MAC address will be scrambled.
By default, the "random" and "stable" algorithms scamble all bits
of the MAC address, including the OUI part and generate a locally-
administered, unicast address.
By specifying a MAC address mask, we can now configure to perserve
parts of the current MAC address of the device. For example, setting
"FF:FF:FF:00:00:00" will preserve the first 3 octects of the current
MAC address.
One can also explicitly specify a MAC address to use instead of the
current MAC address. For example, "FF:FF:FF:00:00:00 68:F7:28:00:00:00"
sets the OUI part of the MAC address to "68:F7:28" while scrambling
the last 3 octects.
Similarly, "02:00:00:00:00:00 00:00:00:00:00:00" will scamble
all bits of the MAC address, except clearing the second-least
significant bit. Thus, creating a burned-in address, globally
administered.
One can also supply a list of MAC addresses like
"FF:FF:FF:00:00:00 68:F7:28:00:00:00 00:0C:29:00:00:00 ..." in which
case a MAC address is choosen randomly.
To fully scamble the MAC address one can configure
"02:00:00:00:00:00 00:00:00:00:00:00 02:00:00:00:00:00".
which also randomly creates either a locally or globally administered
address.
With this, the following macchanger options can be implemented:
`macchanger --random`
This is the default if no mask is configured.
-> ""
while is the same as:
-> "00:00:00:00:00:00"
-> "02:00:00:00:00:00 02:00:00:00:00:00"
`macchanger --random --bia`
-> "02:00:00:00:00:00 00:00:00:00:00:00"
`macchanger --ending`
This option cannot be fully implemented, because macchanger
uses the current MAC address but also implies --bia.
-> "FF:FF:FF:00:00:00"
This would yields the same result only if the current MAC address
is already a burned-in address too. Otherwise, it has not the same
effect as --ending.
-> "FF:FF:FF:00:00:00 <MAC_ADDR>"
Alternatively, instead of using the current MAC address,
spell the OUI part out. But again, that is not really the
same as macchanger does because you explictly have to name
the OUI part to use.
`machanger --another`
`machanger --another_any`
-> "FF:FF:FF:00:00:00 <MAC_ADDR> <MAC_ADDR> ..."
"$(printf "FF:FF:FF:00:00:00 %s\n" "$(sed -n 's/^\([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) \([0-9a-fA-F][0-9a-fA-F]\) .*/\1:\2:\3:00:00:00/p' /usr/share/macchanger/wireless.list | xargs)")"
This allows the user to disable MAC address randomization during
scanning for Wi-Fi networks, which is done by default.
For one, this allows the user to disable the randomization for whatever
reason.
Also, together with configuring the per-connection setting
wifi.cloned-mac-address=preserve, this allows to disable NetworkManager
to modify the MAC address of the interface. This may allow the user
to set the MAC address outside of NetworkManager without NetworkManager
interfering.
'wireless.mac-address-randomization' broke 'wireless.cloned-mac-address',
because we would always set 'PreassocMacAddr=1'. The reason is that
supplicant would set 'wpa_s->mac_addr_changed' during scanning, and
later during association it would either set a random MAC address or
reset the permanent MAC address [1].
Anyway, 'wireless.mac-address-randomization' conflicts with
'wireless.cloned-mac-address'. Instead of letting supplicant set the
MAC address, manage the MAC addresses entirely from NetworkManager.
Supplicant should not touch it.
[1] https://w1.fi/cgit/hostap/tree/wpa_supplicant/wpa_supplicant.c?id=f885b8e97cf39b56fe7ca6577890f2d20df7ae08#n1663
Extend the "ethernet.cloned-mac-address" and "wifi.cloned-mac-address"
settings. Instead of specifying an explicit MAC address, the additional
special values "permanent", "preserve", "random", "random-bia", "stable" and
"stable-bia" are supported.
"permanent" means to use the permanent hardware address. Previously that
was the default if no explict cloned-mac-address was set. The default is
thus still "permanent", but it can be overwritten by global
configuration.
"preserve" means not to configure the MAC address when activating the
device. That was actually the default behavior before introducing MAC
address handling with commit 1b49f941a6.
"random" and "random-bia" use a randomized MAC address for each
connection. "stable" and "stable-bia" use a generated, stable
address based on some token. The "bia" suffix says to generate a
burned-in address. The stable method by default uses as token the
connection UUID, but the token can be explicitly choosen via
"stable:<TOKEN>" and "stable-bia:<TOKEN>".
On a D-Bus level, the "cloned-mac-address" is a bytestring and thus
cannot express the new forms. It is replaced by the new
"assigned-mac-address" field. For the GObject property, libnm's API,
nmcli, keyfile, etc. the old name "cloned-mac-address" is still used.
Deprecating the old field seems more complicated then just extending
the use of the existing "cloned-mac-address" field, although the name
doesn't match well with the extended meaning.
There is some overlap with the "wifi.mac-address-randomization" setting.
https://bugzilla.gnome.org/show_bug.cgi?id=705545https://bugzilla.gnome.org/show_bug.cgi?id=708820https://bugzilla.gnome.org/show_bug.cgi?id=758301
`man nm-settings` says about ethernet.mac-address:
If specified, this connection will only apply to the Ethernet device
whose permanent MAC address matches.
Using the current, possibly non-permanent MAC address doesn't really
make sense.
Also, NM_DEVICE_HW_ADDRESS used to be writable and was set by NMDeviceBt
to the bdaddr. That is wrong, because bdaddr should not be the current
address, but the permanent one.
NetworkManager.conf already contains several per-device settings,
that is, settings that have a device-spec as argument.
main.ignore-carrier
main.no-auto-default
main.assume-ipv6ll-only
keyfile.unmanged-devices
Optimally, these settings should be moved to the new [device*]
section.
For now, only move main.ignore-carrier there. For the others
it may not make sense to do so:
- main.no-auto-default: is already merged with internal state
from /var/lib/NetworkManager/no-auto-default.state. While
NMConfig's write API would be fine to also persist and merge
the no-auto-default setting, we'd still have to read the old
file too. Thus, deprecating this setting gets quite cumbersome
to still handle the old state file.
Also, it seems a less useful setting to configure in the
global configuration aside setting main.no-auto-default=*.
- main.assume-ipv6ll-only: one day, I hope that we no longer
assume connections at all, and this setting becomes entirely
obsolete.
- keyfile.unmanged-devices: this sets NM_UNMANAGED_USER_SETTINGS,
which cannot be overruled via D-Bus. For a future device.managed
setting we want it it to be overwritable via D-Bus by an explicit
user action. Thus, a device.managed property should have a different
semantic, this should be more like a device.unmanaged-force setting,
which could be done.
Add a new [device*] section to NetworkManager.conf. This works similar
like the default connection settings in [connection*].
This will allow us to express per-device configuration in NetworkManager.conf
in our familar style.
Later, via NMConfig's write API it will be possible to make settings
accessible via D-Bus and persist them in NetworkManager-intern.conf.
This way, the user can both edit configuration snippets and modify
them via D-Bus, and also support installing default configuration
from the package.
In a way, a [device*] setting is similar to networkd's link files.
The match options is all encoded in the match-device specs.
One difference is, that the resulting setting can be merged together
by multiple section by partially overwriting them. This makes it
more flexible and allows for example to drop a configuration snippet
that only sets one property, while the rest can be merged from different
snippets.
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.
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.
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.
Until before 1.2.0, NetworkManager would always write resolv.conf as file, but
if /etc/resolv.conf was a symlink, it would follow the link instead of
replacing it with a file ([1], [2]).
With 1.2.0, we initially dropped that behavior and added a new 'rc-manager=none'
which writes resolv.conf to /var/run/NetworkManager and symlinks resolv.conf [3].
In case resolv.conf being already a symlink to another target, it would
not be replaced [4].
Later, we added 'rc-manager=file', which always writes /etc/resolv.conf as
file [5].
With 1.4.0, we will rename 'rc-manager=none' to 'rc-manager=symlink' [6].
This commit now fixes 'rc-manager=file' to restores the pre-1.2 behavior
and follow symlinks.
[1] 5761e328b8
[2] https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/324233
[3] 4805be2ed2
[4] 583568e12f
[5] 288799713d
[6] cd6a469668https://github.com/NetworkManager/NetworkManager/pull/7
Support 3 new flags for Reload:
- 0x01 (CONF): reload the configuration from disk
- 0x02 (DNS_RC): write DNS configuration to resolv.conf
- 0x04 (DNS_FULL): restart DNS plugin
Omitting all flags is the same as reloading everything, thus SIGHUP.
Add new Reload D-Bus command to reload NetworkManager configuration.
For now, this is like sending SIGHUP to the process. There are several
advantages here:
- it is guarded via PolicyKit authentication while signals
can only be sent by root.
- the user can wait for the reload to be complete instead of sending
an asynchronous signal. For now, we operation completes after
nm_config_reload() returns, but later we could delay the response
further until specific parts are fully reloaded.
- SIGHUP reloads everything including re-reading configuration from
disk while SIGUSR1 reloads just certain parts such as writing out DNS
configuration anew.
Now, the Reload command has a flags argument which is more granular
in selecting parts which are to be reloaded. For example, via
signals the user can:
1) send SIGUSR1: this writes out the DNS configuration to
resolv.conf and possibly reloads other parts without
re-reading configuration and without restarting the DNS plugin.
2) send SIGHUP: this reloads configuration from disk,
writes out resolv.conf and restarts the DNS plugin.
There is no way, to only restart the DNS plugin without also reloading
everything else.
This logging domain will be used to enable debugging of the VPN plugins.
However, the plugins might expose sensitive data in this mode, so exclude
the new domain from "LOGD_ALL".
Downstream might want to choose a different default value for
main.rc-manager setting (and it can does so, by compiling with
explicit resolvconf or netconfig support).
Make the default configurable at build-time and also embed it into
the manual page of "NetworkManager.conf".
https://bugzilla.redhat.com/show_bug.cgi?id=1337222
When performing NM package upgrade the new version of nmcli will be immediately
available while NM daemon will not, as it would not restart in order to avoid
to disrupt connectivity. This could create issues with tools leveraging
on nmcli output (till reboot). As apart from this case it is very unlikely
that a user can have this nmcli / NM daemon version mismatch situation,
the check could cause more harm than benefit in real user case
scenarios.
https://bugzilla.redhat.com/show_bug.cgi?id=1291785
The following settings are effectively identical:
dns=none,rc-manager=*any*
dns=none,rc-manager=unmanaged
dns=default,rc-manager=unmanaged
The new setting is only there for completeness and only
makes sense for a dns plugin.
We already have "rc-manager=file", rename "rc-manager=none" to "symlink"
because that better describes what it is actually doing. Of course, the
old name is still accepted.
Otherwise we fail since they don't exist. We have to carefully
implement an "or" condition for the cases of having prebuilt manpages
in a tarball, vs actually building them from source.
This way it's consistently used across all manual page without a need
for XSL templating.
Also, the entities file could in future possibly be used to template the
build-time configurables such as filesystem paths or bug tracker URL.
It's injected from the makefile, but not even used consistently or included in
the resulting render of manual page. Which is good, otherwise we'd have a
non-reproducible build with possible multilib conflicts if rendered around
midnight.
No functional change, just a readability improvement. No need to prefix
the variables with docbook_ and docbook_generated -- all manual pages
are generated from docbook.
The synopsis tag is not appropriate and doesn't look well in HTML and
inserts unnecessary line breaks in roff.
The <userinput> in <screen> suits this perfectly on the other hand.
We actually don't want to understand these options unless the legacy
*-slave types are used. The properties should be used directly instead.
https://bugzilla.gnome.org/show_bug.cgi?id=748302
This basically undoes most of what has been done in commit 00e0fffea2.
Bump NM version number to 1.2 and add the project name to non-XML
pages. Also, update the dates to the date of the last non-trivial
change and update their format to YYYY-MM-DD, as specified by 'man
man-pages'.
Until now the internal DHCP client could start a DHCPv6 transaction
but was not able to parse the lease and pass the information back to
the core. Add the missing glue code to make this work.
https://bugzilla.gnome.org/show_bug.cgi?id=762432
Choose a new logging format.
- the logging format must not be configurable and it must be the
same for all backends. It is neat that journal supports additional
fields, but an average user still posts the output of plain
journalctl, without "--output verbose" (which would also be hard
to read).
Also, we get used to a certain logging format, so having different
formats is confusing. If one format is better then another, it should
be used for all backends: syslog, journal and debug.
The only question is, what is the best format.
- the timestamp: I find it useful to see how much time between two
events passed. The timestamp printed by syslog doesn't have sufficient
granularity, and the internal journal fields are not readily available.
We used to print the timestamps for <error>, <debug> and <trace>,
but ommited them for <info> and <warn> levels. We now print them for
all levels, which has a uniform alignment.
- the location: the "[file:line] func():" part is mostly redundant
and results in wide lines. It also causes a misalignment of the
logging lines, or -- as I recently added alignment of the location --
it results in awkward whitespace and truncation.
But the location is really just necessary because our logging messages
are bad:
"<debug> [1456397604.038226] (9) 11-dhclient succeeded"
The solution to this is not
"<debug> [1456397604.038226] [nm-dispatcher.c:358] dispatcher_results_process(): (9) 11-dhclient succeeded"
but a properly worded message:
"<debug> [1456397604.038226] dispatcher: request #9, script 11-dhclient succeeded"
- logging-message: we need to write better logging messages.
I like some form of "tags" that are easy to grep:
"platform: signal: link changed: 4: ..."
Downside is, that this is not nice to read as a full sentence.
So, especially for <info> and <warn> logging, more human readable
messages are better.
We should find a compromise, where the log message explains what
happens, but is still concise and contains patterns that are easy
to grep and identify visually.
https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00077.html
Some drivers (or things outside NM like 'powertop') may turn powersave
on, so don't touch it unless explicitly configured by user.
To achieve this, add new 'default' and 'ignore' options; the former
can be used to fall back to a globally configured setting, while the
latter tells NM not to touch the current setting.
When 'default' is specified, a missing global default configuration is
equivalent to 'ignore'.
It is possible to enable Wi-Fi power saving for all connections by
dropping a file in /etc/NetworkManager/conf.d with the following
content:
[connection]
wifi.powersave=3
https://bugzilla.gnome.org/show_bug.cgi?id=760125
Only install nm-settings-ifcfg-rh.5 man page if the ifcfg-rh
configuration plugin has been enabled.
But still add them to EXTRA_DIST so that the source tarball
contains the generated man-file, but it isn't installed.
https://bugzilla.gnome.org/show_bug.cgi?id=759823
- it controls echoing passwords input on terminal
- it replaces --show-secrets in 'nmcli connection show', which is deprecated now
- it replaces --show-password in 'nmcli device wifi hotspot', which is deprecated now
If the supplicant supports it and the connection requests it, tell
the supplicant to randomize the MAC address for the association.
In addition, like both iOS, Android, and other OSs always randomize
the MAC address when performing a WiFi scan.
Synopsis:
nmcli connection clone [--temporary] [id|uuid|path] <ID> <new name>
It copies the <ID> connection as <new name>. The command is very useful
if there is a connection, but another one is needed for a related
configuration. One can copy the existing profile and modify it for the
new situation.
For example:
$ nmcli con clone main-eth second-eth
$ nmcli con modify second-eth connection.interface-name em4
https://bugzilla.gnome.org/show_bug.cgi?id=757627
The list of LLDP neighbors is available through the D-Bus interface
and libnm already provides functions to retrieve it; make the list
available through nmcli as well. Sample output:
$ nmcli device lldp
NEIGHBOR[0].DEVICE: eth0
NEIGHBOR[0].CHASSIS-ID: 00:13:21:58:CA:42
NEIGHBOR[0].PORT-ID: 1
NEIGHBOR[0].PORT-DESCRIPTION: 1
NEIGHBOR[0].SYSTEM-NAME: ProCurve Switch 2600-8-PWR
NEIGHBOR[0].SYSTEM-DESCRIPTION: ProCurve J8762A Switch 2600-8-PWR, revision H.08.89
NEIGHBOR[0].SYSTEM-CAPABILITIES: 20 (mac-bridge,router)
NEIGHBOR[1].DEVICE: eth2
NEIGHBOR[1].CHASSIS-ID: 00:01:30:F8:AD:A2
NEIGHBOR[1].PORT-ID: 1/1
NEIGHBOR[1].PORT-DESCRIPTION: Summit300-48-Port 1001
NEIGHBOR[1].SYSTEM-NAME: Summit300-48
NEIGHBOR[1].SYSTEM-DESCRIPTION: Summit300-48 - Version 7.4e.1 (Build 5)
NEIGHBOR[1].SYSTEM-CAPABILITIES: 20 (mac-bridge,router)
https://bugzilla.gnome.org/show_bug.cgi?id=757307
It is useful to show nmcli-generated hotspot password (if a user does not
provide his own password). Without the option the user would have to look into
the generated profile in order to find out the password.
Add the 'lldp' property to NMSettingConnection, which specifies
whether the reception and parsing of LLDP frames to discover neighbor
devices should be enabled.
No longer support disabling the global-dns configuration via the
"enable" option.
Instead, the user can put the entire dns-configuration in one separate
snippet, and disable it altogether with ".config.enable".
Support a new configuration option
[.config]
enable=<ENABLED>
for configuration snippets.
This new [.config] section is only relevant within the snippet itself
and it is not merged into the combined configuration.
Currently only the "enable" key is supported. If the "enable" key is
missing, it obviously defaults to being enabled. It allows snippets
to be skipped from loading. The main configuration "NetworkManager.conf"
cannot be skipped.
<ENABLED> can be a boolean value (false), to skip a configuration
snippet from loading.
It can also be a string to match against the NetworkManager version,
like "enable=nm-version-min:1.1,nm-version-min:1.0.6"
There are several motivations for this:
- the user can disable an entire configuration snippet by toggeling
one entry.
This generalizes the functionality of the global-dns.enable
setting, but in a way that applies to configuration on a per-file
basis.
- for developing, we often switch between different versions of
NetworkManager. Thus, we might want to use different configuration.
E.g. before global-dns options, I want to use "dns=none" and manage
resolv.conf myself. Now, I can use global-dns setting to do that.
That can be achieved with something like the following (not exactly,
it's an example only):
[.config]
enable=nm-version-min:1.1
[main]
dns=default
[global-dns-domain-*]
nameserver=127.0.0.1
Arguably, this would be more awesome, if we would bump our micro devel
version (1.1.0) more often while developing 1.2.0 (*hint*).
- in principle, packages could drop configuration snippets and enable
them based on the NetworkManager version.
- with the "env:" spec, you can enable/disable snippets by configuring
an environment variable. Again, useful for testing and developing.
When a script is a symbolic link to the 'no-wait.d' subdirectory, the
dispatcher now schedules it immediately and in parallel with other
no-wait scripts.
https://bugzilla.gnome.org/show_bug.cgi?id=746703
'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
Previously, when compiling NetworkManager with libaudit support, it
was disabled by default and only used after setting logging.audit=true.
Turn that around. If we compile NetworkManager with audit support, we also
enable it by default. The user can then explicitly disable it by
configuring logging.audit in NetworkManager.conf.
But also, add a configure option 'yes-disabled-by-default' to compile
with audit support, but have it disabled by default. This would be the
previous behavior, but it must be enabled explicitly.
Fixes: be49a59fb6
The only way to disable logging for a domain entirely is to
omit the domain from the "domains" list. For example:
"level=INFO, domains=PLATFORM,..."
Now add an explicit level "OFF" to facilitate configuration like:
"level=INFO, domains=ALL,WIFI_SCAN:OFF"
It also supports
"level=OFF, domains=PLATFORM:INFO"
but this is for the most part equivalent to
"level=INFO, domains=PLATFORM"
Introduce some primitives to deliver messages about relevant
configuration changes to the Linux audit subsystem through libaudit
(if enabled at build time) and to the logging system.
Internal configuration is written as keyfile to
NMSTATEDIR"/NetworkManager-intern.conf"
Basically, the content of this file is merged with user
configuration from "NetworkManager.conf" files. After loading
the configuration, NMConfig exposes a merged view of user-provided
settings and internal overwrites.
All sections/groups named [.intern*] are reserved for internal
configuration values. They can be written by API, but are ignored
when the user sets them via "NetworkManager.conf". For these
internal sections, no conflicts can arise.
We can also overwrite individual properties from user configuration.
In this case, we store the value we want to set, but also remember
the value that the user configuration had, at the time of setting.
If on a later reload the user configuration changed, we ignore our
internal value -- as we assume that the user modified the value
afterwards.
We can also hide/delete value from user configuration.
This works on a per-setting basis.
