This allows implementing some convenience features in nmcli -- listing
the backing store for the connection in "nmcli c show", and using the
filename for specifying connection in "nmcli c up/down".
Eventually, paired with ReloadConnections(), this could be used to
implement something similar to what "systemctl edit" does for units
(though we'd need to pick another command name as we aready use
"nmcli c edit" for something different).
How does `nmcli -f ALL dev show $DEV` look, if it references
a connection that is invisible to the user?
Note in the output:
CONNECTIONS.AVAILABLE-CONNECTIONS[1]: (null) | (null)
At several places, "test-networkmanager-service.py" uses generated numbers
with a defined seed. For example, generated connection's UUID is
generated in a predictable, but randomized way (if you forgive the
inprecise use of the word "random" in context of using a deterministic
seed).
Aside the connection's UUID, this becomes more interesting in the next commit
where the stub server generates a list of IP and DHCP settings in a predictable
randomized way.
For "clients/tests" we spawn the test service multiple times, but also
create similar environments by calling init_001(). This is done for
convenience, where out of lazyness all the tests share one setup. But it's
still a good idea that these tests generate slightly different setups,
wherever applicable. this increases the possible setups which get tested.
For example, the number of static IPv4 addresses (the following commit) is
interested to explicitly test for zero or a non-zero number of
addresses. If all tests happen to use the same seed, the tests are expected
to also generate the same number of addresses, and we miss an opportunity to
hit interesting test cases.
There is still no guarantee that all interesting cases are hit, the chances are just
better. The approach of generating the setup randomly, does not preclude that
the stub-server allows to explicitly configure the setup. However, due to the
sheer number of combinations that might be interesting to test, it's much simpler
to rely on some randomization and have the justifid hope we catch interesting cases.
Also in terms of runtime of the test, the cli unit tests should complete within
few seconds. Testing every combination would result in huge tests and long runtimes.
Also, the patch refactors generating random numbers in
"test-networkmanager-service.py". For example, it introduces
Util.RandomSeed(), which can be used to generate a sequence of different
random numbers. It works by having an internal state and a counter which is
combined to chain the seed and generate different numbers on each call.
There's a couple of places where compose the output using nmc_print().
However, most of them (such as connectivity status or logging level) are
mostly one-line outputs where pager wouldn't make sense. These two stand
out.
When the used client is dhclient we were used to search for DUID not
only in the specific lease files generated by NetworkManager, but also
in the global lease file generated outside NetworkManager.
Keep this capability but allow to just search in the NM lease files if
a value different from the default one is specified in dhcp-duid.
This commit centralizes the DUID generation in nm-device.c.
As a consequence, a DUID is always provided when starting a
DHCPv6 client. The DHCP client can override the passed DUID
with the value contained in the client-specific lease file.
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.
We will soon introduce a property to set a custom DUID and we want
to enforce that the provided value is used.
Note that this commit does not cause any change in behavior in current
code.
The nm_dhcp_dhclient_save_duid() function will save a newly generated
DUID to a previously existing lease file. The function will only save
the DUID if not present in the lease file: in this case, should preserve
the other contents of the lease file.
A dhclient lease file for IPv6 generated by NetworkManager will always
add the DUID as a first item: so in practice finding a lease file
without DUID will never happen.
This has hidden a bug in the function: the loop that is meant to append
the non-duid lines in the lease file would strip all the newlines,
mangling the lease file.
Fix the function allowing to keep the original lines and add a test to
check this functionality is kept well functioning.
FIXME: the new test and the other duid ones already there store the file
in the current working-directory. Tests should not do that.
Just to give it some variety. Also, note how the message from the
server cannot be translated. Which is the case with real NetworkManager
as well, and is a major usability issue.
The real NetworkManager service has a clear understanding how a valid
connection looks like. This is what nm_connection_verify() returns.
Let also our stub-service verify connections the same way.
Note that this is cumbersome, because the stub service uses python's
dbus module, while libnm only accepts creating NMConnection instances
from GVariant. Thus, we need to a cumbersome conversion first.
It would be better if test-networkmanager-service.py would also expose
normalized connections on D-Bus. But that requires the inverse converion
from GVariant to python dbus.
lso, the name "connection" and "con" is overused.
Use "con_inst" where we mean an instance of a "Connection" class,
that is, the object exposed on D-Bus.
- don't use "hash" for a local variable in python.
The editor highlights it like a special python name.
- don't use "settings" for Connection.settings. Name it
Connection.con_hash. The name "settings" is over-used already.
"con_hash" really is the nested dictionary that we expose/receive
from D-Bus. If we would use libnm for it, it would be an
NMSimpleConnection instance, but we don't.
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
We can't use g_steal_pointer(&active) in the argument list if another
argument uses @active because the order of evaluation is not defined.
This fixes the following bug:
src/nm-manager.c:511:_async_op_complete_ac_auth_cb: assertion failed: (active == async_op_data->ac_auth.active)
Fixes: f4fc62bad8https://bugzilla.redhat.com/show_bug.cgi?id=1585494
The NMSettings instance can't be disposed while there is any exported
connection. Ideally we should unexport all connections on NMSettings'
disposal, but for now leak @self on termination when there are
connections alive.
This fixes the following bug on shutdown:
assertion failed: (c_list_is_empty (&priv->connections_lst_head))
#0 raise () from target:/lib64/libc.so.6
#1 abort () from target:/lib64/libc.so.6
#2 g_assertion_message (domain=0x66cab2 "NetworkManager", file=0x6a5e48 "src/settings/nm-settings.c", line=1929)
#3 g_assertion_message_expr () at gtestutils.c:2555
#4 finalize (object=0x1dab170) at src/settings/nm-settings.c:1929
#5 g_object_unref (_object=0x1dab170) at gobject.c:3340
#6 dispose (object=0x1de50b0) at src/nm-manager.c:7139
#7 g_object_unref (_object=0x1de50b0) at gobject.c:3303
#8 _nm_singleton_instance_destroy () at src/nm-core-utils.c:138
#9 _dl_fini () from target:/lib64/ld-linux-x86-64.so.2
#10 __run_exit_handlers () from target:/lib64/libc.so.6
#11 exit () from target:/lib64/libc.so.6
#12 main (argc=<optimized out>, argv=<optimized out>) at src/main.c:460
https://bugzilla.redhat.com/show_bug.cgi?id=1579858
DHCPv4 can fail for two reasons:
(a) the client failed to contact server and to get an initial lease
(b) the client failed to renew the lease after it was successfully
acquired
For (a) the client generates a TIMEOUT event, for (b) an EXPIRED
event. Currently we fail the IP method immediately after (a), but
this doesn't work well when the carrier flickers and we restart the
client because if the server goes temporarily down, the IP method
fails and DHCP is never restarted.
Let's change this, and determine whether to fail IP configuration only
by looking at the current IP state: when it's IP_CONF then we are
getting the initial lease and a failure means that IP configuration
must fail; otherwise any other state means that the lease expired or
could not be renewed and thus we keep the client running for the grace
period.
https://bugzilla.redhat.com/show_bug.cgi?id=1573780
ip_config_merge_and_apply() can be called without an applied
connection, but then it calls nm_device_set_ip_config() and tries to
retrieve the configured MTU, throwing an assertion if the applied
connection is NULL.
src/devices/nm-device.c: line 8080 (nm_device_get_configured_mtu_for_wired): should not be reached
Since it doesn't make sense apply a MTU from the connection when there
is no connection, add a check against this.
use nmc_print() for the job.
Also, localize non-terse output.
Also, fix bug with
$ nmcli c s /org/freedesktop/NetworkManager/ActiveConnection/1
if active connection #1 is invisible to the user.
Also, previously, fill_output_active_connection() wrongly tries to
write to a field that doesn't exist:
set_val_strc (arr, 13-idx_start, s_con ? nm_setting_connection_get_slave_type (s_con) : NULL);
The output of `nmcli connection show` contains also information about
whether the profile is currently active, for example the device and
the current (activation) state.
Even when a profile can be activated only once (without supporting
mutiple activations at the same time), there are moments when a
connection is activating and still deactivating on another device.
NetworkManager ensures in the case with single activations that
a profile cannot be in state "activated" multiple times. But that
doesn't mean, that one profile cannot have multiple active connection
which reference it. That was already handled wrongly before, because
`nmcli connection show` would only search the first matching
active-connection. That is, it would arbitrarily pick an active
connection in case there were multiple and only show activation
state about one.
Furthermore, we will soon also add the possibility, that a profile can be
active multiple times (at the same time). Especially then, we need to
extend the output format to show all the devices on which the profile is
currently active.
Rework printing the connection list to use nmc_print(), and fix various
issues.
- as discussed, a profile may have multiple active connections at each time.
There are only two possibilities: if a profile is active multiple
times, show a line for each activation, or otherwise, show the
information about multiple activations combined in one line, e.g. by
printing "DEVICE eth0,eth1". This patch, does the former.
We will now print a line for each active connection, to show
all the devices and activation states in multiple lines.
Yes, this may result in the same profile being printed multiple times.
That is a change in behavior, and inconvenient if you do something
like
for UUID in $(nmcli connection show | awk '{print$2}'); do ...
However, above is anyway wrong because it assumes that there are no
spaces in the connection name. The proper way to do this is like
for UUID in $(nmcli -g UUID connection show); do ...
In the latter case, whenever a user selects a subset of fields
(--fields, --get) which don't print information about active connections,
these multiple lines are combined. So, above still works as expected,
never returning duplicate UUIDs.
- if a user has no permissions to see a connection, we previously
would print "<invisible> $NAME". No longer do this but just print
the ID was it is reported by the active-connection. If the goal
of this was to prevent users from accidentally access the non-existing
connection by $NAME, then this was a bad solution, because a script
would instead try to access "<invisible> $NAME". This is now solved
better by hiding the active connection if the user selects "-g NAME".
- the --order option now sorts according to how the fields are shown.
For example, with --terse mode, it will evaluate type "802-11-wireless"
but with pretty mode it will consider "wifi". This may change the
ordering in which connections are shown. Also, for sorting the name,
we use g_utf8_collate() because it's unicode.
