We make an effort to get a better fallback case with
_bad_random_bytes().
Also make an effort to get good randomness in the first place. Even if
we compile against libc headers that don't provide getrandom(). Also,
this isn't really ugly, because for a long time glibc was reluctant to
add getrandom() wrapper and using syscall() was the way to go.
nm_utils_random_bytes() tries to get good randomness. If it fails, we still
try our own approach, but also signal that the returned numbers are bad.
In practice, none of the callers cares about the return value, because they
wouldn't know what to do in case of bad randomness (abort() is not an
option and retry is not expected to help and sending an email to the
admin isn't gonna help either). So the fallback case really should try
its best.
The fallback case depends on a good random seed and a good pseudorandom
number generator.
Getting a good seed is in reality impossible, after kernel let us down.
That is part of the problem, but we try our best.
The other part is to use a cryptographic pseudorandom number generator.
GRand uses a Mersenne Twister, so that is not good enough. In this low
level code we also cannot call gnutls/nss, because usually we don't have
that dependency. Maybe we could copy&paste the chacha20 implementation,
it's simple enough and a compatible license. That might be good, but
instead cock our own by adding some sha256 into the mix. This is
fallback code after all, and we want to try hard, but not *that* hard to
add chacha20 to NetworkManager.
So, what we do is to use a well seeded GRand instance, and XOR that
output with a sha256 digest of the state. It's probably slow, but
performance is not the issue in this code path.
If a prefix delegation is needed, currently NM restarts DHCPv6 on the
device with default route, but only if DHCPv6 was already running.
Allow the device to start DHCPv6 for a PD even if it was running
without DHCPv6.
See also: https://github.com/coreos/fedora-coreos-tracker/issues/888
Previously we sent announcements immediately for non-controllers, or
after the first port was attached for controllers.
This has two problems:
- announcements can be sent when there is no carrier and they would
be lost;
- if a controller has a port, the port could be itself a controller;
in that case we start sending ARPs with the fake address of the
port. Later, when a leaf port is added to the second-level
controller, the correct port MAC will be propagated by kernel up to
both controllers.
To solve both problems, send ARP announcements only when the interface
has carrier. This also solves the second issue because controllers
created by NM have carrier only when there is a port with carrier.
Fixes: de1022285a ('device: do ARP announcements only after masters have a slave')
https://bugzilla.redhat.com/show_bug.cgi?id=1956793
We encode the default value "direct" properties in the GParamSpec.
But we also avoid CONSTRUCT properties, because they have an overhead
and they are generally odd for the settings.
So up to now, it was cumbersome to explicitly set the default value,
but it was also error prone.
Avoid that by always initializing the default value for our "direct"
properties.
And as example, implement NMSettingVrf.table this way. This also
makes all properties of NMSettingVrf implemened as "direct" properties,
and we can drop the explicit getter/setters.
If all settings would be strictly be implemented as "direct" properties,
we could call this from NMSetting.finalize() and be done with it.
As it is, for now we cannot, so it's still cumbersome.
For our property meta data handling we require that all the meta data is
associated with one GType.
NMSettingIPConfig is a parent class of NMSettingIP[46]Config. Note that
we already have _nm_sett_info_property_override_create_array_ip_config()
because the meta data must be initialized together at one place.
We will require that we can find the offset for properties based on one
offset per type. That is cumbersome, if NMSettingIPConfigPrivate is
private itself.
Simplify that, by internally sharing NMSettingIPConfigPrivate and let
the subclasses embed the private data in their own private data.
Optimally we would simply embed the private struct as field into
NMSettingIPConfig. But that would be an ABI change as that struct
was public before 1.32. Don't change ABI for now, so we have to
awkwardly place it into the subclasses private data.
Introduce a new mechanism for how to handle properties generically.
We have NMSettInfoSetting, NMSettInfoProperty and NMSettInfoPropertType
with meta data about settings and their properties.
For example, we have a simple boolean property. Then (usually) we have a
boolean GParamSpec, and a plain boolean field in the NMSetting's private
data. We need very little to get (and convert to keyfile, GVariant),
set (from keyfile, GVariant) and compare this property.
All we need to know, is the GParamSpec and the offset of the bool field.
Introduce a new mechanism for that, and as example implement
NM_SETTING_CONNECTION_AUTOCONNECT property this way.
Note that this patch only changes the to_dbus_fcn() for the boolean
property. But this opens up all kind of further improvements.
What we eventually also can do is replace GObjectClass.get_property()
with a generic variant, that knows how to get and set the property.
NMSetting instances either have no private data, they use
g_type_add_class_private(), or they embed the private data in the
NMSetting struct.
In all cases, we can find the private data at a fixed offset. Track that
offset in the NMSettInfoSetting meta data.
This will be useful, because properties really are stored in simple
fields, like a boolean property can be stored in a "bool" field. We will
extend the property meta data to track the offset of this property
field, but we also need to know where the offset starts.
We have NM_VALUE_TYPE_UNSPEC (with numeric value 1).
NM_VALUE_TYPE_UNSPEC means that there is some undefined opaque
type, that cannot be handled generically.
But what we also need is NM_VALUE_TYPE_NONE (with numeric value 0) to
express that no type was set.
Sort entries in src/nmcli/devices.c (on line 5023 - 5036)
by alphabetical order. The Order is violated in cases where
the sort would affect previous behaviour.
Example: `nmcli d d` is still shortcut for `nmcli device disconnect`
instead of `nmcli device delete`.
nmcli now accepts `nmcli device up|down` which works the same way as
`nmcli device connect|disconnect`
I also edited man pages of nmcli with new options.
$ nmcli connection add type dummy con-name x autoconnect no ipv4.method disabled ipv6.method disabled ifname d0
$ ip link add d1 type dummy
$ nmcli connection up x ifname d1
Error: device 'd1' not compatible with connection 'x': The interface names of the device and the connection didn't match..
$ nmcli connection add type dummy con-name x autoconnect no ipv4.method disabled ipv6.method disabled ifname d0
$ mcli connection up x ifname bogus
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/12)
This is not right. A non-existing ifname argument was simply ignored
and nmcli would tell NetworkManager to activate the profile (on any
device).
Instead, if the user specifies a device argument, also for a virtual
type, it must exist.
Note that usually for virtual devices (like 'dummy'), the device
in fact does not exist, so passing `ifname` is likely to fail.
If the device already exists, then the command is no going to work
as expected, with
$ mcli connection up x ifname d0
succeeding, while
$ mcli connection up x ifname d1
fails (as intended) with
Error: device 'd1' not compatible with connection 'x': The interface names of the device and the connection didn't match..
$ nmcli connection add type ethernet con-name x autoconnect no ipv4.method disabled ipv6.method disabled
$ nmcli connection up x ifname bogus
Error: device 'bogus' not compatible with connection 'x'.
Better would be:
Error: device 'bogus' not found for connection 'x'.
Let the default normalization from nm_connection_normalize() choose
'ipv6.method'. It will now choose "disabled" for dummy profiles, which
is just what we need.
In particular, we don't want to enable autoconf for dummy devices --
unless the profile which the user provides already has it enabled (in
which case nm_connection_normalize() doesn't change it).
$ ip link add dd type dummy
$ nmcli device
DEVICE TYPE STATE CONNECTION
...
dd dummy unmanaged --
$ nmcli device connect dd
Error: Failed to add/activate new connection: A 'dummy' setting is required.
There are two problems here. The first is that we don't pass
the interface name to nm_utils_complete_generic(), but dummy
devices require "connection.interface-name" set. As a consequence,
nm_utils_complete_generic() fails to normalize the connection
and there is no [dummy] setting. Which then results in a failure
with complete_connection().
The important part of the fix is to set the interface name. Once
we do that, nm_utils_complete_generic() should be able to add
the [dummy] setting and the second part is not strictly necessary.
Still, the job of complete_connection() is not to verify the
profile but to create it with best effort. If a [dummy] setting
is still missing, we should just add it. The caller will then
again try to normalize/verify the connection, and that might then
fail -- but this time not with the wrong error message about
missing 'dummy' setting.
https://bugzilla.redhat.com/show_bug.cgi?id=1763054
"ipv6.method=ignore" really exists for historic reasons, from a time when
NetworkManager didn't support IPv6 autoconf and let kernel handle it.
Nowadays, we should choose an explicit mode, like "link-local" or
"disabled".
Let nm_connection_normalize() treat WireGuard and dummy profiles
different and set the IPv6 method to "disabled".
On a dummy device we cannot do DHCP. The default makes no sense.
This also affects `nmcli device connect dummy0`. We want that the
generated profile gets normalized to no IP configuration, because
DHCP/autoconf is not working on a dummy device.
Currently there is another problem and that command is not working. But
if that other problem would be fixed, then the generated profile would try
to do DHCP, fail, and retry endlessly (with backoff pauses).
That endless loop is a third problem. If `nmcli device connect` creates
a new profile, then upon failure the profile should be deleted again.
But these two other problems are not solved hereby.
I guess, to a certain point these normalization options are hardly used.
Still, it feels right to also support it for IPv4. These options make
sense to me to control normalization.
I missed that we already have a gettid() wrapper. Drop the duplicated
again and use nm_utils_gettid().
Fixes: e874c5bf6b ('random: Provide missing gettid() declaration')
