Currently, default-routes cannot be added like regular static-routes
as ipv4.routes setting.
Instead, one has to configure "ipv4.gateway" and "ipv4.never-default".
That of course should be fixed, for example to configure a default-route
in different routing tables.
As it is, both nmcli's parse function and libnm's
NMSettingIPConfig:verify() functions reject default-routes.
But nmcli goes way beyond that, it also rejects all networks with
"0.0.0.0"/"::" even if their prefix length is not zero. Such routes are
not default-routes, and nmcli has no business rejecting them. The
correct way for checking for a default-route is to check the prefix-length
for zero.
Drop the wrong validation in nmcli.
Note, it may still not be the best idea to add catch-all routes like
"0.0.0.0/1" and "128.0.0.0/1". It just defeats what counts as a default-route.
NM has other means (like configuring the route-metric) to handle routing
in face of multiple interfaces. But sure, whatever works for you.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/114https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/75
The generic connection validation produces a good result:
Error: failed to modify 802-11-wireless-security.psk: ':(' is not a valid PSK.
vs.:
Error: Failed to add 'wifi666' connection: 802-11-wireless-security.psk: property is invalid
nmcli connection modify t ipv4.dns-options ndots:2
nmcli connection modify t +ipv4.dns-options ndots:4
should set dns-options to 'ndots:4', so we must remove other
occurences of the same option before adding it, otherwise the setting
refuses to set the same option again.
Appending to the ipvx.dns-options property:
nmcli connection modify con +ipv4.dns-options rotate
currently is buggy because it resets the list to contain only
'rotate'. The setter function should not clear the list.
https://bugzilla.redhat.com/show_bug.cgi?id=1665649
The 'number' property in GSM settings is a legacy thing that comes
from when ModemManager used user-provided numbers, if any, to connect
3GPP modems.
Since ModemManager 1.0, this property is completely unused for 3GPP
modems, and so it doesn't make sense to use it in the NetworkManager
settings. Ofono does not use it either.
For AT+PPP-based 3GPP modems, the 'number' to call to establish the
data connection is decided by ModemManager itself, e.g. for standard
GSM/UMTS/LTE modems it will connect a given predefined PDP context,
and for other modems like Iridium it will have the number to call
hardcoded in the plugin itself.
https://github.com/NetworkManager/NetworkManager/pull/261
VALUES_STATIC() was a macro to initialize the values_static pointer with
a (static) strv array.
For one, it lacked a "const" in "(const char *[])", which means
the data is not put in a read only section by the linker. That should
be fixed.
Anyway, we already have a macro for creating such constant strv arrays:
NM_MAKE_STRV().
I think it is good to the concept of "initializing values_static" a
name (VALUES_STATIC()). But it also hides (for better or worse), that
this is a strv array. Let's use NM_MAKE_STRV() instead. By looking at
the code, it's still clear that this initializes the "values_static"
array, but it also makes it clear that this is a plain strv array.
The meta data type descriptor must set .get_gtype only for
GObject properties which are of type int or uint. That is, when
the enum type cannot be automatically detected.
However, NM_SETTING_SERIAL_PARITY is a g_param_spec_enum()
of type NM_TYPE_SETTING_SERIAL_PARITY, so setting the get_gtype()
hook is wrong and leads to a crash
$ /bin/nmcli connection add type gsm autoconnect no con-name t ifname '*' apn xyz serial.parity 5
(process:11086): libnmc-CRITICAL **: 15:04:35.180: file clients/common/nm-meta-setting-desc.c: line 1283 (_set_fcn_gobject_enum): should not be reached
Segmentation fault (core dumped)
That is because the enum property setter does:
»···if ( has_gtype
»··· && NM_IN_SET (gtype_prop,
»··· G_TYPE_INT,
»··· G_TYPE_UINT)
»··· && G_TYPE_IS_CLASSED (gtype)
»··· && (gtype_class = g_type_class_ref (gtype))
»··· && ( (is_flags = G_IS_FLAGS_CLASS (gtype_class))
»··· || G_IS_ENUM_CLASS (gtype_class))) {
»···»···/* valid */
meaning, it only allows "has_gtype" if the native "gtype_prop" is
G_TYPE_INT or G_TYPE_UINT.
Fixes: 9a68123827
libnm currently has only one GObject property of type uint64:
"serial.send-delay". However, it's broken because uint64 handling
is not implemented.
$ nmcli connection add type gsm autoconnect no con-name t ifname '*' apn 'xyz' serial.baud 5
Connection 't' (4c929f17-9fda-41d6-8f90-897f6d46b078) successfully added.
$ nmcli connection show t
...
ipv6.dhcp-duid: --
ipv6.dhcp-send-hostname: yes
ipv6.dhcp-hostname: --
ipv6.token: --
(process:14016): libnmc-CRITICAL **: 14:08:32.591: file clients/common/nm-meta-setting-desc.c: line 811 (_get_fcn_gobject_int): should not be reached
serial.baud: 5
serial.bits: 8
serial.parity: none
serial.stopbits: 1
serial.send-delay: --
gsm.number: *99#
...
$ nmcli connection add type gsm autoconnect no con-name t ifname '*' apn 'xyz' serial.baud 5 serial.send-delay 100
(process:14852): libnmc-CRITICAL **: 14:12:24.259: file clients/common/nm-meta-setting-desc.c: line 1131 (_set_fcn_gobject_int): should not be reached
Segmentation fault (core dumped)
Fixes: b6d9bdcee8
The new hash table should destroy elements stolen from the hash table
returned by nm_utils_parse_variant_attributes().
Fixes: d094914120
(cherry picked from commit 31bda1b837)
Before, we would not autocomplete connection types that have an alias:
Connection type: <TAB><TAB>
6lowpan cdma macvlan vlan
802-11-olpc-mesh dummy olpc-mesh vpn
802-11-wireless ethernet ovs-bridge vxlan
802-3-ethernet generic ovs-interface wifi
adsl gsm ovs-port wimax
bluetooth infiniband pppoe wpan
bond ip-tunnel team
bridge macsec tun
Connection type: 8<TAB> [-> no completion]
Don't treat the default connection type (for example,
"802-3-ethernet") in a special way and allow it to be autocompleted,
because we already display it when the user did not enter any text.
Add a new 'match' setting containing properties to match a connection
to devices. At the moment only the interface-name property is present
and, contrary to connection.interface-name, it allows the use of
wildcards.
As of upstream kernel v4.18-rc8.
Note that we name the features like they are called in ethtool's
ioctl API ETH_SS_FEATURES.
Except, for features like "tx-gro", which ethtool utility aliases
as "gro". So, for those features where ethtool has a built-in,
alternative name, we prefer the alias.
And again, note that a few aliases of ethtool utility ("sg", "tso", "tx")
actually affect more than one underlying kernel feature.
Note that 3 kernel features which are announced via ETH_SS_FEATURES are
explicitly exluded because kernel marks them as "never_changed":
#define NETIF_F_NEVER_CHANGE (NETIF_F_VLAN_CHALLENGED | \
NETIF_F_LLTX | NETIF_F_NETNS_LOCAL)
We will add a large number of offload features. That means, the output
of `nmcli connection show "$PROFILE"` would be very verbose, in case
the profile has a [ethtool] option.
Since this is newly added API, don't do that. Don't show ethtool properties
that are left unset.
A minor problem here is, that it becomes no longer obvious which
properties exist. We should however counter that by documentation.
Also, one could do:
$ nmcli connection modify "$PROFILE" ethtool.xxx x
Error: invalid property 'xxx': 'xxx' not among [feature-gro, feature-gso, feature-lro, feature-ntuple, feature-rx, feature-rxhash, feature-rxvlan, feature-sg, feature-tso, feature-tx, feature-txvlan, feature-tx-tcp6-segmentation, feature-tx-tcp-segmentation].
Likewise, bash completion still works as one would expect.
$ nmcli --complete-args connection modify "$PROFILE" ethtool.
ethtool.feature-gro
ethtool.feature-gso
ethtool.feature-lro
[...]
Note the output of
$ nmcli -f ethtool.feature-gro connection show "$PROFILE"
gives now nothing (if there is an ethtool section, but not this
particular feature). Maybe this shouldn't be like that. On the other
hand, specifying a connection setting that doesn't exist also gives
no output:
$ nmcli -f bond connection show "$PROFILE"
So, maybe this behavior is fine.
Also, add two more features "tx-tcp-segmentation" and
"tx-tcp6-segmentation". There are two reasons for that:
- systemd-networkd supports setting these two features,
so lets support them too (apparently they are important
enough for networkd).
- these two features are already implicitly covered by "tso".
Like for the "ethtool" program, "tso" is an alias for several
actual features. By adding two features that are already
also covered by an alias (which sets multiple kernel names
at once), we showcase how aliases for the same feature can
coexist. In particular, note how setting
"tso on tx-tcp6-segmentation off" will behave as one would
expect: all 4 tso features covered by the alias are enabled,
except that particular one.
Note that in NetworkManager API (D-Bus, libnm, and nmcli),
the features are called "feature-xyz". The "feature-" prefix
is used, because NMSettingEthtool possibly will gain support
for options that are not only -K|--offload|--features, for
example -C|--coalesce.
The "xzy" suffix is either how ethtool utility calls the feature
("tso", "rx"). Or, if ethtool utility specifies no alias for that
feature, it's the name from kernel's ETH_SS_FEATURES ("tx-tcp6-segmentation").
If possible, we prefer ethtool utility's naming.
Also note, how the features "feature-sg", "feature-tso", and
"feature-tx" actually refer to multiple underlying kernel features
at once. This too follows what ethtool utility does.
The functionality is not yet implemented server-side.
Add a new option that allows to activate a profile multiple times
(at the same time). Previoulsy, all profiles were implicitly
NM_SETTING_CONNECTION_MULTI_CONNECT_SINGLE, meaning, that activating
a profile that is already active will deactivate it first.
This will make more sense, as we also add more match-options how
profiles can be restricted to particular devices. We already have
connection.type, connection.interface-name, and (ethernet|wifi).mac-address
to restrict a profile to particular devices. For example, it is however
not possible to specify a wildcard like "eth*" to match a profile to
a set of devices by interface-name. That is another missing feature,
and once we extend the matching capabilities, it makes more sense to
activate a profile multiple times.
See also https://bugzilla.redhat.com/show_bug.cgi?id=997998, which
previously changed that a connection is restricted to a single activation
at a time. This work relaxes that again.
This only adds the new property, it is not used nor implemented yet.
https://bugzilla.redhat.com/show_bug.cgi?id=1555012
The virtual function NMMetaType.get_nested() has only one caller:
nm_meta_abstract_info_get_nested(). That caller makes sure to
always pass in an @out_to_free argument, and that it is initialized
to NULL.
We commonly don't use the glib typedefs for char/short/int/long,
but their C types directly.
$ git grep '\<g\(char\|short\|int\|long\|float\|double\)\>' | wc -l
587
$ git grep '\<\(char\|short\|int\|long\|float\|double\)\>' | wc -l
21114
One could argue that using the glib typedefs is preferable in
public API (of our glib based libnm library) or where it clearly
is related to glib, like during
g_object_set (obj, PROPERTY, (gint) value, NULL);
However, that argument does not seem strong, because in practice we don't
follow that argument today, and seldomly use the glib typedefs.
Also, the style guide for this would be hard to formalize, because
"using them where clearly related to a glib" is a very loose suggestion.
Also note that glib typedefs will always just be typedefs of the
underlying C types. There is no danger of glib changing the meaning
of these typedefs (because that would be a major API break of glib).
A simple style guide is instead: don't use these typedefs.
No manual actions, I only ran the bash script:
FILES=($(git ls-files '*.[hc]'))
sed -i \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>\( [^ ]\)/\1\2/g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\> /\1 /g' \
-e 's/\<g\(char\|short\|int\|long\|float\|double\)\>/\1/g' \
"${FILES[@]}"
The function nmc_print() receives a list of "targets". These are essentially
the rows that should be printed (while the "fields" list represents the columns).
When filling the cells with values, it calles repeatedly get_fcn() on the
column descriptors (fields), by passing each row (target).
The caller must be well aware that the fields and targets are
compatible. For example, in some cases the targets are NMDevice
instances and the target type must correspond to what get_fcn()
expects.
Add another user-data pointer that is passed on along with the
targets. That is useful, if we have a list of targets/rows, but
pass in additional data that applies to all rows alike.
It is still unused.
gretap and ip6gretap ip-tunnel interfaces encapsulate L2 packets over
IP. Allow adding a wired setting for such connections so that users
can change the interface MAC.
It is safer to enable send-sci by default because, at the cost of
8-byte overhead, it makes MACsec work over bridges (note that kernel
also enables it by default). While at it, also make the option
configurable.
https://bugzilla.redhat.com/show_bug.cgi?id=1588041
Coccinelle:
@@
expression a, b;
@@
-a ? a : b
+a ?: b
Applied with:
spatch --sp-file ternary.cocci --in-place --smpl-spacing --dir .
With some manual adjustments on spots that Cocci didn't catch for
reasons unknown.
Thanks to the marvelous effort of the GNU compiler developer we can now
spare a couple of bits that could be used for more important things,
like this commit message. Standards commitees yet have to catch up.
It is meant to be rather similar in nature to isblank() or
g_ascii_isspace().
Sadly, isblank() is locale dependent while g_ascii_isspace() also considers
vertical whitespace as a space. That's no good for configuration files that
are strucutured into lines, which happens to be a pretty common case.
