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.
Track whether IP addresses were added by NM or externally. In this way
it becomes possible in a later commit to add prefix route only for
addresses added by NM.
Allow a reapply of the connection when the device is still activating
and ensure that each reapply action is performed only at a given
activation stage. For example, the IP configuration is not reactivated
if the device is in the prepare stage.
https://bugzilla.redhat.com/show_bug.cgi?id=1763062
WiMAX is deprecated since NetworkManager 1.2.0. Note that also
NetworkManager on server side no longer supports this type, hence
the server's D-Bus API will never expose devices of this type.
Note that NMDeviceWimax and NMWimaxNsp are NMObject types. That means,
they are instantiated by NMClient to represent information on the D-Bus
interface. As NetworkManager no longer exposes WiMAX devices, such
devices are never created. Note that it makes no sense that a user would
directly instantiate NMObject types, because they only work together with
NMClient.
Don't drop the related symbols and definitions from libnm, so that there
is no API/ABI change (as far as building and linking is concerned). But
make the types defunctional (which of course is a behavioral API change).
Calling the API now triggers a g_return_*() warning.
Also belatedly mark the WimaxNsp API as deprecated. It should have been
done in 1.2. Note that here we deprecate the API and retire it at the
same time. Optimally, we would have deprecated it a few releases ago,
before retiring it. However, marking something for deprecation is anyway
no excuse for anything. I mean, removing or retiring API is usually
painful, regardless whether it was marked for deprecation or not. In this
case, there is no possibility that a libnm user gets hold on a NMDeviceWimax
or NMWimaxNsp instance, because NMClient simply no longer instantiates
them. Hence, this change should not affect any user in practice.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/316
RFC does not define how long the client ID can be. However,
n-dhcp4 enforces that the server replies with a client ID that
matches the request. Also, the client ID gets encoded as a DHCP
option, hence it cannot be longer than 255 bytes.
While n-dhcp4 doesn't enforce a certain length, a too long client
ID is not going to work. Hence, truncate it at 133 bytes.
This is the same limit that also systemd's DHCP client has. It's chosen
to fit an RFC4361-complient client ID with a DUID of length
MAX_DUID_LEN (which is 128 bytes according to RFC 3315 section 9.1).
Fixes-test: @ipv4_set_very_long_dhcp_client_id
See-also: https://github.com/nettools/n-dhcp4/pull/6https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/307
These types are all subclasses of NMObject. These instances are commonly
created by NMClient itself. It makes no sense that a user would
instantiate the type. Much less does it make sense to subclass them.
Hide the object and class structures from public API.
This is an API and ABI break, but of something that is very likely
unused.
This is mainly done to embed the private structure in the object itself.
This has benefits for performance and debugability. But most
importantly, we can obtain a static offset where to access the private data.
That means, we can use the information to access the data pointer
generically, as we will need later.
This is not done for the internal types NMManager, NMRemoteSettings,
and NMDnsManager. These types will be dropped later.
