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"`.
(cherry picked from commit ce9619047c)
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"`.
clients/tests only uses Polish locale for testing localized output.
No need to generate the Germane locale as well.
(cherry picked from commit 3a58c956c5)
Tests might just take longer than 20 seconds.
Also, we already watch stdin to determine whether the service
should exit.
(cherry picked from commit 4e18ef49bf)
Now that nmcli initiates a scan before displaying Wi-Fi networks,
the stub service must properly support that as well.
For the moment, the stub service chooses "now" as LastScan timestamp.
This causes nmcli not to trigger a new scan, because nmcli gives
unstable output if multiple nmcli processes in parallel race to
trigger a Wi-Fi scan. That should be fixed.
(cherry picked from commit 56a0488bba)
This opens the tests up to races. If we want to change the strength, we
need to do it in a controlled, race-free manner. This is especially the
case, because clients/tests run a large number of nmcli instances in
parallel, and it's thus racy which signal the nmcli processes will
see.
This also fixes a bug at
self._dbus_property_set(IFACE_WIFI_AP, PRP_WIFI_AP_STRENGTH, strength)
@strength must be a D-Bus type, so that python-dbus knows the correct
type for serialization.
(cherry picked from commit 7e118c0091)
Now that nmcli initiates a scan before displaying Wi-Fi networks,
the stub service must properly support that as well.
For the moment, the stub service chooses "now" as LastScan timestamp.
This causes nmcli not to trigger a new scan, because nmcli gives
unstable output if multiple nmcli processes in parallel race to
trigger a Wi-Fi scan. That should be fixed.
This opens the tests up to races. If we want to change the strength, we
need to do it in a controlled, race-free manner. This is especially the
case, because clients/tests run a large number of nmcli instances in
parallel, and it's thus racy which signal the nmcli processes will
see.
This also fixes a bug at
self._dbus_property_set(IFACE_WIFI_AP, PRP_WIFI_AP_STRENGTH, strength)
@strength must be a D-Bus type, so that python-dbus knows the correct
type for serialization.
When link auto-negotiation is enabled, by default the network device
advertises all the supported speed and duplex modes in order to
negotiate the fastest link speed with the remote endpoint.
It is possible anyway to configure the device to just advertise and
accept a subset of supported modes.
This could be useful to properly enforce gigabit speeds on Ethernet:
as stated in IEEE 802.3 specification, auto-negotiation is mandatory
for 1000Base-T and 10GBase-T standards.
Allow specific values to 802-3-ethernet.speed and 802-3-ethernet.duplex
properties also when 802-3-ethernet.auto-negotiate=yes: this will
result in link auto-negotiation advertising the specified speed/duplex
mode as the only one available.
It's deprecated and has been replaced by libnm for 6 major releases now.
Its use in modern distributions has faded to the point it can probably
be safely removed.
It's not libnm's responsibility to hide the banner
depending on the VPN state. libnm should cache and expose
NetworkManager's state, and if the VPN connection has
a banner there, it should be returned.
The previous behavior was since ever in libnm, and in libnm-glib since
the banner was introduced in commit e5b834c1f9.
I think it's wrong if libnm tries too hard putting additional logic
on top of what is on D-Bus.
When a property getter returns an empty/missing strv-array, in multi-line
mode we should not print any lines.
To get that right, we must mark the cell as STRV type, even if there is no value
provided.
Previously, with text_out_flags having NM_META_ACCESSOR_GET_OUT_FLAGS_STRV
and value being NULL, we would not set
cell->text_format = PRINT_DATA_CELL_FORMAT_TYPE_STRV;
and thus, later on the value would be treated as a missing (plain)
string.
The property getter for certain properties tries to return
a strv array.
In this case, the result should be identical, whether an
empty strv array or NULL is returned.
Let _ip_config_get_routes() return %NULL if there are no routes.
This should have no practical difference, but it actually exposes
a bug in "cli/common/utils.c", which was previously hidden by
not commonly returning %NULL. This bug will be fixed in the
next commit.
_LOGD() is preferred, because it includes a common prefix depending
on the device. This macro requires, that we have a suitable @self
variable in the local scope.
This is to support the S5 case, where usually the NM process is
stopped. If we are stopping and WoWLAN is set for the interface,
we do not deconfigure it and keep the connection alive so we
can receive packages that will potentially wake up the system.
Note that for this work, wpa_supplicant needs to be modified too
so it does not deconfigure the wireless interface either when
stopped. The needed patches for wpa_supplicant can be found in
http://lists.infradead.org/pipermail/hostap/2018-June/038644.html
