NMDeviceVxlan has some "q" type properties. They were not handled:
$ G_MESSAGES_DEBUG=all PAGER= LIBNM_GLIB_DEBUG=properties-changed nmcli 2>&1 | grep "couldn't be set from D-Bus type"
libnm-Message: 10:44:04.538: demarshal_generic: NMDeviceVxlan:dst-port (type guint) couldn't be set from D-Bus type q.
libnm-Message: 10:44:04.538: demarshal_generic: NMDeviceVxlan:src-port-max (type guint) couldn't be set from D-Bus type q.
libnm-Message: 10:44:04.538: demarshal_generic: NMDeviceVxlan:src-port-min (type guint) couldn't be set from D-Bus type q.
libnm-Message: 10:44:04.539: demarshal_generic: NMDeviceWireGuard:listen-port (type guint) couldn't be set from D-Bus type q.
The only contributors to this code are Red Hat employees who agree
with this license change.
$ git log --pretty=format:'%Cred%h%Creset - %Cgreen(%ai)%Creset [%C(yellow)%an%Creset] %s%C(yellow)%d%Creset' --no-merges -- 'libnm-core/nm-json.?' 'libnm-core/nm-jansson.?'
...
$ git shortlog -s --no-merges -- 'libnm-core/nm-json.?' 'libnm-core/nm-jansson.?'
1 Beniamino Galvani
1 Lubomir Rintel
8 Thomas Haller
Signed-off-by: Beniamino Galvani <bgalvani@redhat.com>
Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Thomas Haller <thaller@redhat.com>
In nm_acd_manager_announce_addresses() we should not only start the
probes but also add the acd file descriptor to the main loop.
Otherwise, a timer is armed to send the announcements but it never
fires and no announcements are sent.
Fixes: d9a4b59c18 ('acd: adapt NM code and build options')
https://bugzilla.redhat.com/show_bug.cgi?id=1767681
NM 1.22 is not released yet and 1.20.6 will happen before 1.22.0, so
we can introduce the new API with version libnm_1_20_6 in both
releases without having duplicate symbols on 1.22.
When processing the rd.znet option set the interface name only in case when
the persistent interface names feature isn't disabled via net.ifnames=0
[lkundrak@v3.sk: minor tweaks to the net.ifnames=0 parsing]
The current solution for s390 specific details relies on an interface to
exist before adding the s390 details. It means the ip= option must precede
the rd.znet= option. Also only a single interface can be configured. With
this change the s390 details are put to the right interface and properly
named interface is created if it hasn't existed yet.
Otherwise repeated "nmcli d wifi hotspot" commands create multiple
Hostpot connections, which is just sad. We do already reuse existing
connections with "nmcli d wifi connect" -- let's just do a similar thing
here.
Our NMObject implementations should behave in a similar manner.
For example, string properties should be coerced the a consistent
manner.
Add functions _nml_coerce_property_*() for that. Of course, they
are trivial. Their value is not that they encapsulate some complex
implementation, but that they convey a general concept of how we
want to handle certain properties in NMClient's object cache.
The library should not print to stdout/stderr. This function is used to
convert untrusted(!!) input to a normalized and sanitized strv array.
g_warning() is essentially an assertion, and it's wrong to do that
for untrusted data. If the caller had to pre-validate the array, then
having this function would be pointless.
Default values should preferably be zero and/or a value that indicates
that the property is unknown/unset.
In practice, this property is not unset because it's present
on the D-Bus API.
Yes, by default (server side) devices do autoconnect.
But that does not mean an NMObject, that has its GObject property
not set via D-Bus shall default to TRUE.
Default values preferably should be FALSE, because that is what we get
by default (memset(0)).
NMAccessPoint is an NMObject, and exclusively created and initialized by
NMClient. In practice, the D-Bus property is always present on D-Bus, so
the default value is not used. However, a better default is anyway
"unknown", also because that has zero numeric value.
If the user adds an address manually, kernel automatically adds a
prefix route for it unless the address has the NOPREFIXROUTE
flag. When ip_config_merge_and_apply() gets called, NM also adds its
prefix route and so we end up with two routes that differ only for the
metric.
This is a problem because the route added by NM is not removed if the
user removes the previously added address. Also, it seems confusing to
have multiple instances of the same routes.
This commit skips the addition of a prefix route for addresses added
manually outside of NetworkManager.
