Introduce a "vlan.protocol" property that specifies the protocol of a
VLAN, which controls the tag (EtherType) used for encapsulation.
Regular VLANs use 802.1Q (tag 0x8100). To implement VLAN stacking it's
sometimes useful to have 802.1ad VLANs with tag 0x88A8.
The property is a string instead of e.g. an enum because this allows
maximum flexibility in the future. For example, it becomes possible to
specify an arbitrary number in case if the kernel ever allows it.
There are two benefits:
- the returned (allocated) string will have exactly the required
length and no excess buffer that was used to build the string.
- the string is (most likely) short enough to fit in 488 bytes on the
stack. There is no re-allocation necessary to grow the buffer.
The warning "-Wcast-align=strict" seems useful and will be enabled
next. Fix places that currently cause the warning by using the
new macro NM_CAST_ALIGN(). This macro also nm_assert()s that the alignment
is correct.
GArray.data is a char pointer. Most of the time we track other data in
a GArray. Casting that pointer can trigger "-Wcast-align=strict"
warnings.
Avoid them. Most of the time, instead use the nm_g_array*() helpers,
which also assert that the expected element size is correct.
A loopback interface cannot be attached to a controller interface (in kernel).
Also, we have special handling for the loopback address 127.0.0.1. It's
not clear how that should behave when the loopback device would be
attached to another interface.
Just reject such configuration as invalid.
Fixes: e8618f03d7 ('support loopback interface')
openvswitch accepts "dot1q-tunnel" as vlan mode:
A dot1q-tunnel port is somewhat like an access port. Like an
access port, it carries packets on the single VLAN specified
in the tag column and this VLAN, called the service VLAN,
does not appear in an 802.1Q header for packets that ingress
or egress on the port. The main difference lies in the be‐
havior when packets that include a 802.1Q header ingress on
the port. Whereas an access port drops such packets, a
dot1q-tunnel port treats these as double-tagged with the
outer service VLAN tag and the inner customer VLAN taken
from the 802.1Q header. Correspondingly, to egress on the
port, a packet outer VLAN (or only VLAN) must be tag, which
is removed before egress, which exposes the inner (customer)
VLAN if one is present.
Support this mode.
Add a new "ovs-port.trunks" property that indicates which VLANs are
trunked by the port.
At ovsdb level the property is just an array of integers; on the
command line, ovs-vsctl accepts ranges and expands them.
In NetworkManager the ovs-port setting stores the trunks directly as a
list of ranges.
The next commit is going to introduce a new object in libnm to
represent a range of ovs-port VLANs. A "range of integers" object
seems something that can be used for other purposes in the future, so
instead of adding an object specific for this case
(e.g. NMOvsPortVlanRange), introduce a generic NMRange object that
generically represents a range of non-negative integers.
Support managing the loopback interface through NM as the users want to
set the proper mtu for loopback interface when forwarding the packets.
Additionally, the IP addresses, DNS, route and routing rules are also
allowed to configure for the loopback connection profiles.
https://bugzilla.redhat.com/show_bug.cgi?id=2060905
This is the version shipped in Fedora 37. As Fedora 37 is now out, the
core developers switch to it. Our gitlab-ci will also use that as base
image for the check-{patch.tree} tests and to generate the pages. There
is a need that everybody agrees on which clang-format version to use,
and that version should be the one of the currently used Fedora release.
Also update the used Fedora image in "contrib/scripts/nm-code-format-container.sh"
script.
The gitlab-ci still needs update in the following commit. The change
in isolation will break the "check-tree" test.
We must consume the reference, like we would in the other case.
Interestingly, I am unable to reproduce a case where valgrind would
complain about the leak. But it is there nonetheless.
Fixes: 0a22f4e490 ('libnm: refactor tracking of NMSetting in NMConnection')
See wpa_supplicant commit [1]:
macsec: Make pre-shared CKN variable length
IEEE Std 802.1X-2010, 9.3.1 defines following restrictions for
CKN:
"MKA places no restriction on the format of the CKN, save that it
comprise an integral number of octets, between 1 and 32
(inclusive), and that all potential members of the CA use the same
CKN. No further constraints are placed on the CKNs used with PSKs,
..."
Hence do not require a 32 octet long CKN but instead allow a
shorter CKN to be configured.
This fixes interoperability with some Aruba switches, that do not
accept a 32 octet long CKN (only support shorter ones).
[1] https://w1.fi/cgit/hostap/commit/?id=b678ed1efc50e8da4638d962f8eac13312a4048f
These are just general purpose D-Bus utils, based on glib and GDBus.
They fit perfectly to libnm-glib-aux. Move the code.
Also, there is already the file "src/core/nm-dbus-utils.c", having two
files with the same name on our source tree is just confusing.
Most users included this by accident, by including nm-connection.h. That
is not too great, becuase stuff it contains is by no means specific to
NMConnection.
Anyways, it's not like it would matter too that. I mainly care about it
being included in NetworkManager.h, so that there's one less special
case in a test that makes sure useful stuff from NetworkManager.h ends up
in gtk-doc (a separate commit).
libnm-core-impl/nm-setting-bond.c:1276: warning: Symbol name not found at the start of the comment block.
libnm-core-impl/nm-setting-vpn.c:1135: warning: Symbol name not found at the start of the comment block.
libnm-core-impl/nm-setting-vpn.c:1158: warning: Symbol name not found at the start of the comment block.
libnm-core-impl/nm-setting-wired.c:1560: warning: Symbol name not found at the start of the comment block.
libnm-client-impl/nm-dhcp-config.c:149: warning: Symbol name not found at the start of the comment block.
libnm-client-impl/nm-secret-agent-old.c:967: warning: Symbol name not found at the start of the comment block.
libnm-client-impl/nm-secret-agent-old.c:1010: warning: Symbol name not found at the start of the comment block.
libnm-client-impl/nm-secret-agent-old.c:1037: warning: Symbol name not found at the start of the comment block.
libnm-core-impl/nm-setting-bond.c:602: warning: Parameter description
for nm_setting_bond_validate_option::value (allow-none) is not used
from source code comment block.
gtk-doc (and perhaps other tools) treat pound sign in comments
specially:
html/NMSetting8021x.html:1501: warning: no link for: "11" -> (<span class="type">11</span>).
"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.
These are present in a public header yet are not properly commented,
versioned or exported.
Export them now. Another option would be to move them to a private
header; but I suspect someone has intended them to be exported at some
point.
Add them to @libnm_1_40_4 as opposed to @libnm_1_42_0 because we now know
this is going to be backported to 1.40.4 first.
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
- 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')
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.
nm_setting_diff() ends up calling the compare_fcn() hook. Previously,
the hook for "dns" was _nm_setting_property_compare_fcn_default()
and the hook for "dns-data" was _nm_setting_property_compare_fcn_ignore().
That's wrong. _nm_setting_property_compare_fcn_default() converts
the property to D-Bus and compares the GVariant. However, "dns" has
to_dbus_only_in_manager_process set, so it wouldn't
Fixes: 63eaf168d1 ('libnm: add "dns-data" replacement for "ipv[46].dns" properties on D-Bus')
property_to_dbus() gets called for two reasons. Once from
_nm_setting_to_dbus(). In that case, we want to honor
to_dbus_only_in_manager_process().
It gets also called from _nm_setting_property_compare_fcn_default(),
with ignore_flags set. In that case, we don't want to ignore the property
as the hook really wants to compare them.
Fixes: c8392018ca ('libnm: refactor to-dbus on the client skipping to serialize legacy properties')
