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.
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.
