According to the D-Bus API specification we return CLOCK_BOOTTIME only.
We don't support kernels too old to have it -- the fall back to
CLOCK_MONOTONIC is only there to be able to run unit tests on RHEL 6
kernel and will eventually go away.
Currently, nmcli does not sort the list of available connections
for display. Instead, it shows them in the order as NetworkManager
exposes them on D-Bus.
Previously, test-networkmanager-service.py, would generate the list
of available connections by iterating the connections dictionary.
In Python (at least until Python 3.6), the order when iterating over
dictionaries is undefined. This inconsistancy lets tests behave
differently depending on the python version. Possibly with Python
3.4 and 3.5, tests might even behave differently between individual
runs (since Python there uses siphash with a randomized hash seed).
It is safer to enable send-sci by default because, at the cost of
8-byte overhead, it makes MACsec work over bridges (note that kernel
also enables it by default). While at it, also make the option
configurable.
https://bugzilla.redhat.com/show_bug.cgi?id=1588041
We set the metric to the routes as we receive them from the PPP plugin. We
ought to let the modem know before it starts IPv4 configuration, not right
before the commit.
https://bugzilla.redhat.com/show_bug.cgi?id=1585611
Check the wpa_flags and rsn_flags values to see if the network needs the
password added to the 802-11-wireless-security settings. The current
ap_flags check alone would only trigger the password to be sent for WEP
networks. Also remove unneeded initialization of the three variables.
In a lot of cases, we don't require the GBytes out-argument. This
is the case when called from NMSettingIP6Config's verify().
Avoid allocating the GBytes instance and also don't heap allocate
the temporary buffer in that case.
Also, being called from NMSettingIP6Config's verify(), at which
point the string value contains untrusted data. Of course, we
do very badly in general protecting against the user creating
huge settings, which could trick NetworkManage to allocate
large amounts of memory (and being killed by glib's out of memory
handling). We should handle such cases better in general, but
just avoid it here.
Since we know that the buffer must hold at most 128+2 bytes,
we can stack allocate it. Later, in case we really need to
return the value, we can create a GBytes instance of the right
size.
For better or worse, the logging done for ipv4.dhcp-client-id
is prefixed with ipv4.dhcp-client-id. Let ipv6.dhcp-duid follow
that pattern.
Also, generate_duid_from_machine_id() would log at two places,
it should use the same logging prefix.
Also, it logs the value of "duid" variable. Ensure, that "duid"
is not %NULL at that point.
Also, fix leak of nm_dhcp_utils_duid_to_string() value during logging.
Previously, there were two blocks
if (NM_IN_SET (duid, "ll", "llt")
preprocess_hwaddr()
else if (NM_IN_SET (duid, "stable-ll", "stable-llt", "stable-uuid"))
preprecess_stable_id()
if (nm_streq (duid, "ll")
generate_ll()
else if (nm_streq (duid, "llt"))
generate_llt()
else if (nm_streq (duid, "stable-ll")
generate_stable_ll()
...
That is, the latter block depends on the execution of the previous
block, while the previous block is guarded by a particular condition,
slighlty different than the condition in the later block.
It is confusing to follow. Instead, check for our cases one by one, and
when we determined a particular DUID type, process it within the same block
of code. Now the code consists of individual blocks, that all end with a "goto
out*". That means, it's easier to understand the flow of the code.
Also, don't initialize duid_error variable and separate between
"out_error" and "out_good". This allows that the compiler gives
a warning if we missed ot initialize duid_error.
dhcp6_get_duid() already handles failure to generate the DUID in a
sensible manner. No reason to duplicate the error handling in
generate_duid_from_machine_id().
Especially, because generate_duid_from_machine_id() used to cache the
random DUID in memory and reuse it from then on. There is no reason to do
that, /etc/machine-id must be available to NetworkManager. We still
handle such a grave error gracefully by generating a random DUID.
First of all, generating the client-id is not expected to fail. If it fails,
something is already very wrong. Maybe, a failure to generate a client-id
should result in failing the activation. However, let's not go full
measure in this question.
Instead:
- ensure that we log a warning and a reason why the client-id could not
be generated.
- fallback to a random client id. Clearly, we were unable to generate
the requested client-id, hence, we should fallback to a default value
which does not make the host easily identifyable. Of course, that means
that the generated DHCP client-id is not at all stable. But note that
something is already very wrong, so when handling the error we should do
something conservative (that is, protecting the users privacy).
This is also what happens for a failure to generate the ipv6.dhcp-duid.
In practice, there should be no difference between peeking into
the platform cache, or using the cached value from nm_device_get_hw_address().
Prefer the hardware address from the platform, because:
- we also pass the current MAC address to nm_dhcp_manager_start_ip4().
For not particularly strong reason, it uses the MAC address obtained
from platform. At the least, it makes sense that we use the same
addresses for the client-id as well.
- ipv6.dhcp-duid also gets the address from platform. Again,
no strong reason either way, but they should behave similar
in this regard.
Commands that fail with G_DEBUG=fatal-warnings produce unstable
output like
(process:10743): GLib-CRITICAL **: 16:29:13.635: g_ptr_array_add: assertion 'rarray' failed
To workaround that, add a new option for marking the output as unstable.
An alternative might be to extend the replace_stdout, replace_stderr
arguments to support more powerful matching, like by specifying regular
expression for replacing. However, it's just too complicated. Add a simpler
workaround by passing _UNSTABLE_OUTPUT.
Unless the initscripts package too old to allow alternatives is present,
install nmcli as an alternative implementation of ifup and ifdown.
The triggerin scriptlet allow us to do the right thing regardless of
which initscripts version is installed or even when it's upgraded.
The initscripts patch was included in Fedora 29:
https://github.com/fedora-sysv/initscripts/pull/197
They're intended to be used via update-alternatives(8) as compatibility
shims for Red Hat systems without the legacy network control scripts.
While they're not strictly parts of the settings plugin, they're best
just installed along with it, since they're supposed to be available on
systems that use the ifcfg files.
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.
