While at it, rename the "addr" field to "l_address". The term "addr" is
used over and over. Instead we should use distinct names that make it
easier to navigate the code.
nmtst_get_rand_int() was originally named that way, because it
calls g_rand_int(). But I think if a function returns an uint32, it
should also be named that way.
Rename.
Maybe DHCP plugins should be configurable per address family and be
re-loadable via SIGHUP. But that just adds complexity.
Nowadays we always have the "internal" DHCP plugin, which is known to
support both IPv4 and IPv6. One day, we should get rid of all plugins
and only use one implementation (that works well). The "internal" plugin
is supposed to be(come) that.
That also means, that we are not going to add more (external) DHCP
plugins and we are not going to invest work in the existing plugins
(except the "internal" plugin).
Some DHCP plugins are known to not support IPv6. If the user selects
"dhcpcd" we should just fallback to the "internal" plugin. What's the
point of letting the activation fail? Probably users shouldn't use
"dhcpcd" plugin anyway, but that's a different story. Doing such fallback
could be a problem with forward compatibility if we ever would add IPv6
support to "dhcpcd". But we won't.
Also, we are going to add "n-dhcp4" as replacement for the systemd based
code. For a time, there will be an experimental plugin "nettools" that
eventually will become the new "internal" plugin. Until that happens,
we want for IPv6 automatically fallback to systemd based "internal"
plugin. This patch will make that simple.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/173
NM_MODEM_OPERATOR_CODE property is construct-only. Add our common
code comment to the property setter.
Construct-only setters are pretty simple. They run before the object is
constructed, hence their scope is clearer. As such, there is no need to
emit property changed notifications (also because that is already taken
care by the GObject property setter). Don't call _nm_modem_set_operator_code(),
just directly set the property.
Usually we aim to have only one place where we set state (_nm_modem_set_operator_code()).
But a construct-only property setter is trivial enough that we can affort having two
places to modify the property. In particular, because the property setter does not "modify"
the property, it merely initializes it before the object is fully
constructed.
The early boot tooling gets the root-path from our state file due to a
lack of a better way to do that. However, when booting with NFS root,
the root path alone is not sufficient; the server address is communicated
via the next-server option. Save that one in the state file as well.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/168
Clang (3.4.2-9.el7) on CentOS 7.6 fails related to nm_hash_update_vals().
Clang seems to dislike passing certain complex arguments to typeof().
I'd prefer to fix nm_hash_update_vals() to not have this problem,
but I don't know how.
This works around the issue.
clang (3.4.2-9.el7) on CentOS 7.6 fails related to nm_hash_update_vals().
I am not even quoting the error message, it's totally non-understandable.
nm_hash_update_vals() uses typeof(), and in some obscure cases, clang dislikes
when the argument itself is some complex macro. I didn't fully understand why,
but this works around it.
I would prefer to fix nm_hash_update_vals() to not have this limitation.
But I don't know how.
There is probably no downside to have this an inline function instead of
a macro.
This code is now unused.
Also, it does not seem state of the art to me
anymore.
Drop it, it could always be resurrected if need by, but maybe
GFileMonitor could be used instead.
It's deprecated and off by default for a long time.
It is bad to automatically reload connection profiles. For example, ifcfg
files may consist of multiple files, there is no guarantee that we
pick up the connection when it's fully written.
Just don't do this anymore.
Users should use D-Bus API or `nmcli connection reload` or `nmcli
connection load $FILENAME` to reload profiles from disk.
If the AddAndActivate() caller didn't explicitely a MAC address, default
to pinpointing the connection to the device by the means of an interface
name. This makes more sense than a MAC address with stable device names.
If the AddAndActivate() caller didn't explicitely a MAC address, default
to pinpointing the connection to the device by the means of an interface
name. This makes more sense than a MAC address with stable device names.
If the AddAndActivate() caller didn't explicitely a MAC address, default
to pinpointing the connection to the device by the means of an interface
name. This makes more sense than a MAC address with stable device names.
This is used to indicate the network dracut module should fall back to
configure network automatically (as with ip=dhcp was specified) if
there's no other network configuration present on the command line.
The option is documented in dracut.cmdline(7).
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/167
Before commit e3ac45c026 the reader set the private key in the
setting using the libnm function, which also set the key as client
certificate if it was in PKCS #12 format.
After the commit, existing connections with a PKCS #12 private key but
without a client certificate became invalid. Restore the old behavior.
Fixes: e3ac45c026 ('ifcfg-rh: don't use 802-1x certifcate setter functions')
When changing the number of VFs the kernel can block for very long
time in the write() to sysfs, especially if autoprobe-drivers is
enabled. Turn the nm_platform_link_set_sriov_params() into an
asynchronous function.
Remove the call-id from the requests hash before invoking the callback.
This prevents the user to cancel the request from within the callback.
Supporting such a use case is not necessary so prevent it and tighten
the callers up.
- drops nm_dispatcher_init(), which was called early in the main loop
and created a proxy synchronously. Instead, the GDBusConnection is
always ready.
- reuse the GDBusConnection of NMDBusManager. This means, we won't even
try from in "initrd" configure-and-quit mode.
- as before, there is no "manager" instance. Instead, the data is stored
in a global variable. That's ok. What is not OK is how the entire
shutdown is handled (calling dispatcher blockingly, not waiting for
requests to complete). That is fixable, but a lot of work. It is
independent of whether we use a manager object or not.
A guint value can wrap, so we would need to check that we don't allocate duplicate
IDs (which we currently don't, and it's likely never to actually hit).
Just expose the (opaque) pointer of the call-id.
We still keep a "request_id", but that is only for logging purpose.
This way, we avoid code duplication of how to print the request-id
("(%u) "), but it also will allow up to attach the interface name
and connection name to the call-id, so that we can use it for structured
logging.
We don't need the two callers both unpack the GVariant and pass a GVariantIter.
Let dispatcher_results_process() do the unpacking.
Also, use some cleanup attributes.
Completely refactor the team/JSON handling in libnm's NMSettingTeam and
NMSettingTeamPort.
- team handling was added as rh#1398925. The goal is to have a more
convenient way to set properties than constructing JSON. This requires
libnm to implement the hard task of parsing JSON (and exposing well-understood
properties) and generating JSON (based on these "artificial" properties).
But not only libnm. In particular nmcli and the D-Bus API must make this
"simpler" API accessible.
- since NMSettingTeam and NMSettingTeamPort are conceptually the same,
add "libnm-core/nm-team-utils.h" and NMTeamSetting that tries to
handle the similar code side-by-sdie.
The setting classes now just delegate for everything to NMTeamSetting.
- Previously, there was a very fuzzy understanding of the provided
JSON config. Tighten that up, when setting a JSON config it
regenerates/parses all other properties and tries to make the
best of it. When modifying any abstraction property, the entire
JSON config gets regenerated. In particular, don't try to merge
existing JSON config with the new fields. If the user uses the
abstraction API, then the entire JSON gets replaced.
For example note that nm_setting_team_add_link_watcher() would not
be reflected in the JSON config (a bug). That only accidentally worked
because client would serializing the changed link watcher to
GVariant/D-Bus, then NetworkManager would set it via g_object_set(),
which would renerate the JSON, and finally persist it to disk. But
as far as libnm is concerned, nm_setting_team_add_link_watcher() would
bring the settings instance in an inconsistent state where JSON and
the link watcher property disagree. Setting any property must
immediately update both the JSON and the abstraction API.
- when constucting a team setting from D-Bus, we would previously parse
both "config" and abstraction properties. That is wrong. Since our
settings plugins only support JSON, all information must be present
in the JSON config anyway. So, when "config" is present, only the JSON
must be parsed. In the best case, the other information is redudant and
contributes nothing. In the worse case, they information differs
(which might happen if the client version differs from the server
version). As the settings plugin only supports JSON, it's wrong to
consider redundant, differing information from D-Bus.
- we now only convert string to JSON or back when needed. Previously,
setting a property resulted in parsing several JSON multiple times
(per property). All operations should now scale well and be reasonably
efficient.
- also the property-changed signals are now handled correctly. Since
NMTeamSetting knows the current state of all attributes, it can emit
the exact property changed signals for what changed.
- we no longer use libjansson to generate the JSON. JSON is supposed
to be a machine readable exchange format, hence a major goal is
to be easily handled by applications. While parsing JSON is not so
trivial, writing a well-known set of values to JSON is.
The advantage is that when you build libnm without libjansson support,
then we still can convert the artificial properties to JSON.
- Requiring libjansson in libnm is a burden, because most of the time
it is not needed (as most users don't create team configurations). With
this change we only require it to parse the team settings (no longer to
write them). It should be reasonably simple to use a more minimalistic
JSON parser that is sufficient for us, so that we can get rid of the
libjansson dependency (for libnm). This also avoids the pain that we have
due to the symbol collision of libjansson and libjson-glib.
https://bugzilla.redhat.com/show_bug.cgi?id=1691619
We have nm_setting_verify() for a purpose.
The checks that ifcfg-rh reader does are either
- redundant (and thus unnecessary)
- wrong (and thus we cannot read valid settings)
- should belong to libnm's nm_setting_verify().
NMSettingTeam/NMSettingTeamPort are already very libraral and don't do
almost any strict validation. Previously, ifcfg reader would be even more
liberal. If there is totally invalid data in the profile, reading the profile
should fail.
If we created a software interface it is because we already decided
that it should be managed, and so there is no point in waiting udev to
check that the interface is not udev-unmanaged.
We still wait udev for software interfaces created externally.
An active connection started by user could be queued in state UNKNOWN
which means the device hasn't started activating yet. Eventually it
will, and we don't want to cancel the user activation because of an
internal autoconnection attempt.
