It's possible that the modem is enabled outside of NM. If not
re-check, device could stay disabled throughout until something else
about the modem changes again.
If modem is not at least "registered", a connection is not happening, which
means IP settings change is probably not interesting. Avoid trying to
parse it, so that we don't trigger connection failure when there isn't
one.
Downstream patches for this does it through NMSettings plugin, however
settings plugin are hard to maintain and complicated architecture wise
as well.
So directly create a connection profiles in-memory from the
nm-modem-ofono side. Those profiles are created in /run, and are not
added as a persistent connection, because connection state quite depends
on the state of ofono
This also allows us to drop the hack where we are keeping track of
active context/APN through the connection name, i.e if connection name
was in /imsi/context1 format, it was used. Instead now, Connection name
is actual context name which is user friendly ("Vodafone Connect" e.g.
in my case), and details like IMSI and context are stored internally.
[ratchanan@ubports.com:
- forward-ported to main branch.
- fold "wwan/ofono: handle context removal" into this commit.
- track the "preferred"-ness of the context and react accordingly.
Creates proxies for all retrived contexts to listen to changes.
While at it, also track name and type.
- use, instead of ignore, internet APN. Also support internet+mms APN.
- correct priv->contexts' value destroy function.
- factor out UUID generation as a helper function.
- handle the case where context dictionary is missing required keys.
- simplify nm_ofono_connection_new's arguments and rename to
add_or_update_connection. Makes it handle the case where the
connection already exists.
- also simplify other functions' arguments.
- clean up code and comments. Fix memory problems. Get rid of warnings.
]
Co-authored-by: Ratchanan Srirattanamet <ratchanan@ubports.com>
"gen-metadata-nm-settings-libnm-core.xml" now contains also the names of
the NMSetting types, like "NMSettingConnection". That can be useful
to create NMSetting instances generically (that is, without knowing
the C API that gets called).
So you might be tempted to run
#!/bin/python
import gi
gi.require_version("NM", "1.0")
from gi.repository import GObject, NM
connection = NM.SimpleConnection()
# NM.utils_ensure_gtypes()
gtype_name = "NMSetting6Lowpan"
gtype = GObject.type_from_name(gtype_name)
setting = GObject.new(gtype)
connection.add_setting(setting)
However, without NM.utils_ensure_gtypes() that would not work, because
the GType is not yet created. For a user who doesn't know a priory all
setting types, it's not entirely clear how to make this work. Well, a
GObject introspection user could iterate over al NM.Setting* names and
try to instantiate the classes. However, that is still cumbersome, and not
accessible to a C user (without GI) and the currently loaded libnm
library may be newer and have unknown setting types.
In particular plain C user would need to know to call all the right
nm_setting_*_get_type(), functions, so it needs to know all the existing
52 type getters (and cannot support those from a newer libnm version).
With nm_utils_ensure_gtypes(), the user can get the typename and create
instances generically only using g_type_from_name().
Possible alternatives:
- libnm also has _nm_utils_init() which runs as __attribute__((constructor)).
We could also always instantiate all GType there. However, I don't like running
non-trivial, absolutely necessary code before main().
- hook nm_setting_get_type() to create all GType for the NMSetting
subclasses too. The problem is, that it's not entirely trivial to
avoid deadlock.
- hook nm_connection_get_type() to create all NMSetting types. That
would not deadlock, but it still is questionable whether we should
automatically, at non-obvious times instantiate all GTypes.
The NMPObject is a tagged union. There is no need to initialize anything
after the size of the actually used union field. Change this, so maybe we
get a valgrind warning about uninitialized memory if we wrongly try to
access it.
On the other hand, the object really is supposed to be a full
NMPObject. Previously, we would get a valgrind warning, if we tried to
pass fewer data there.
It really doesn't matter much, but all other functions don't assume
that there is any important data after the size indicated by the class.
We will extend IPv4 routes with the list of next hops. This field will
be heap allocated and be part of the NMPObjectIP4Route object, while
also being part of the identity. To support the ID operator that checks
fields of the NMPObject, add a "for_id" argument to the hash/cmp hooks.
Also, a function that sets cmd_obj_{hash_update,cmp}() MUST not set
cmd_plobj_id_{hashupdate,cmp}(), as it would have overlapping
functionality. Therefore, the objects that define
cmd_obj_{hash_update,cmp}() need to fully implement the ID comparison.
A NMPClass that has data outside the plobj part, needs
to implement the cmd_obj_*() hooks, instead of cmd_plobj_*().
For those objects, reasoning only about the plobj part is not
sufficient. Implementing both hooks is also unnecessary and
confusing.
Ensure that if we have cmd_obj_*() hooks set, that the corresponding
cmd_plobj_*() hooks are unset.
The if-else-if was wrong. It meant that if an object did not implement
cmd_plobj_id_copy(), nothign was copied (for id-only).
I think this code path was not actually hit, because we never clone
an object only by ID.
Fixes: c91a4617a1 ('nmp-object: allow missing implementations for certain virtual functions')
In the commit 2a11c57c4e ('libnm/wifi: rework NMSetting8021xAuthFlags
to explicitly disable TLS version'), it said:
> In the future, supplicant may disable options by default, and
> the inverse option can become interesting to configure
> "tls_disable_tlsv1_0=0". When that happens, we can solve it by
> adding another flag NM_SETTING_802_1X_AUTH_FLAGS_TLS_1_0_ENABLE.
This commit adds the `NM_SETTING_802_1X_AUTH_FLAGS_TLS_1_0_ENABLE`
flag as well as similar flags for other TLS versions.
This commit also adds flags for TLS v1.3, as the corresponding flags
are now provided in wpa_supplicant.
The NMSetting8021xAuthFlags setting is rejected when both enable and
disable are set for the same TLS version. if-else-if is used in
nm_supplicant_config_add_setting_8021x to guarantee this behavior.
It prefers ENABLE over DISABLE to match the behavior of wpa_supplicant.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1133https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1450
Fix up the doc comment so that the gir data gets that right.
Fixes: 90d0ae0faf ('libnm: implement nm_client_activate_connection()/nm_client_add_and_activate_connection*() by using GDBusConnection directly')
- the static assertions were wrong, there was a "," instead of "==".
- the numeric values were wrong, as shown by the static assertions.
- move the code comment to the implementation. This does not seem
relevant for the library user and should not be in the public header.
Fixes: 08e845f651 ('nm-setting: mangle public constant to make g-ir-scanner happy')
Fix this compile error when "defined(__GNUC__) && (__GNUC__ > 2) &&
defined(__OPTIMIZE__)" doesn't match:
In file included from ../src/libnm-std-aux/nm-default-std.h:102,
from ../src/libnm-std-aux/nm-std-utils.c:3:
../src/libnm-std-aux/nm-std-aux.h: In function ‘NM_ALIGN_TO’:
../src/libnm-std-aux/nm-std-aux.h:160:6: error: expected expression before ‘{’ token
160 | ({ \
| ^
../src/libnm-std-aux/nm-std-aux.h:169:31: note: in expansion of macro ‘_NM_BOOLEAN_EXPR_IMPL’
169 | #define NM_BOOLEAN_EXPR(expr) _NM_BOOLEAN_EXPR_IMPL(NM_UNIQ, expr)
| ^~~~~~~~~~~~~~~~~~~~~
../src/libnm-std-aux/nm-std-aux.h:175:27: note: in expansion of macro ‘NM_BOOLEAN_EXPR’
175 | #define NM_LIKELY(expr) NM_BOOLEAN_EXPR(expr)
| ^~~~~~~~~~~~~~~
../src/libnm-std-aux/nm-std-aux.h:238:19: note: in expansion of macro ‘NM_LIKELY’
238 | } else if NM_LIKELY (cond) { \
| ^~~~~~~~~
../src/libnm-std-aux/nm-std-aux.h:449:5: note: in expansion of macro ‘nm_assert’
449 | nm_assert(nm_utils_is_power_of_two(ali));
| ^~~~~~~~~
The NM_LIKELY()/NM_UNLIKELY() macros should be alwas called enclosed
in parentheses like in:
if (NM_LIKELY(i == 1)) ...
and should be expanded with only a single pair of parentheses so that
expressions like (i = 1) generate a compiler warning.
Fixes: 030d68aef7 ('shared: add nm_assert() to "nm-std-aux.h"')
libnm-core-impl has lots of internal meta data about the properties.
In particular, which properties exist (their names), and their D-Bus
type.
We should use this information for our manual pages. For example,
currently `man nm-settings-dbus` has nonsense like: "Value Type: array
of string", when it should be reall "as".
In a first step, generate an XML with that meta data for later use.
This is the better name, becuse this is not in particular about "docs".
It's about generating an XML with the information from the settings
meta data for nmcli.
We will do something similar with the libnm-core meta data.
It just feels nicer to be explicit about the filenames and
not rely on a specific naming.
Also, in meson we can directly pass the target as argument, which
expands to the filename but also adds a dependency.
