Kernel does a auto-mtu adjusting process whenever a port is added/removed from
the bridge, this can cause issues when NM wants to explicitly set an MTU which is
equal to the bridge default one (1500) because if later a port is added with a
different MTU the kernel will assign the bridge that port's MTU resulting in the bridge
runtime configuration differing from the bridge's NM connection profile.
What we can do is to always apply the MTU manually for the bridge (if explicitly
set by the profile), after doing so the kernel won't modify the MTU anymore,
which is what we want, problem is that kernel won't actually apply the MTU
to the netdev if it's not actually changing so we first apply it to
MTU-1 and then to the desired value.
https://bugzilla.redhat.com/show_bug.cgi?id=1778590
Signed-off-by: Antonio Cardace <acardace@redhat.com>
Add a parameter to the 'link_add()' virtual function so that
the MTU will be configured (via netlink) by the kernel when
creating the link.
https://bugzilla.redhat.com/show_bug.cgi?id=1778590
Signed-off-by: Antonio Cardace <acardace@redhat.com>
- we commonly use "int addr_family" as parameters to functions.
But then inside the function, we often need to do something for
IPv4 or IPv6 specifically. Instead of having lots of redundant
"if (addr_family == AF_INET)" checks, prefer to have a variable
IS_IPv4 and/or use NM_IS_IPv4() macro.
- don't make the "IS_IPv4" variable a gboolean but an int. gboolean
is a typedef for int, so it's in practice exactly the same. However,
we use "IS_IPv4" as index to arrays of length 2, where at position
"1" we have the value related to IPv4. Using a gboolean to index
an array is a bit odd. Maybe a "int" is preferable here.
This is more about doing consistently one or the other. There are
no strong reasons to prefer gboolean or int.
Apparently it is not actually used, but the function implements
a return value for AF_UNSPEC, while also asserting that the addr_family
is AF_INET/AF_INET6. Drop the assertions.
These macros are consistent with NMP_OBJECT_TYPE_IP_ADDRESS()
and NMP_OBJECT_TYPE_IP_ROUTE(), in name and usage.
Replace the previous functions that had inconsistent and a verbose
naming.
It's a bit ugly that NMActRequest also tracks the shared rules.
Why? It's just some additional state (the rules) and some additional
actions that should be done when activating/deactivating the profile.
NMActRequest also doesn't track the NMDhcpClient, so why these shared
rules?
Also, removing the rules from an object destructor is ugly. NMActRequest
is a GObject and ref-counted. We should not make assumptions when the
last reference gets releases, at least not in cases like this, where
we hand out the reference and the object is passed around through large
parts of the source code.
For now, still let NMActRequest keep track of NMUtilsShareRules.
Later this will be refactored too.
A static const array is marked as immutable by the linker.
This is what we want, because there is no need to change this
array.
Also, the tailing %NULL entry is not necessary, we can just
iterate over the fixed number of elements.
NML3Cfg is the manager instance for one interface (ifindex). For one
interface, it is not supported (nor useful) to run IPv4LL multiple
times. Hence, let NML3Cfg manage and return a single instance.
We may want to handle cases where we cannot assign a IPv4LL address
even after multiple attempts.
Add a new property nm_l3_ipv4ll_is_timed_out() to get into a failed
state. The user may choose to fail the activation or ignore it.
Also, remove some unused code and fix minor issues in NML3IPv4LL.
For hidden networks, we usually don't have an SSID. We try to match
and fill the SSID based on the profiles that we have:
<debug> [1603798852.9918] device[6b383dca267b6878] (wlp2s0): matched hidden AP AA:BB:CC:DD:EE:FF => "SSID"
However, we should not clear that value again on the next update:
<trace> [1603798856.5724] sup-iface[66c1a0883a262394,0,wlp2s0]: BSS /fi/w1/wpa_supplicant1/Interfaces/0/BSSs/3 updated
<debug> [1603798856.5726] device[6b383dca267b6878] (wlp2s0): wifi-ap: updated AA:BB:CC:DD:EE:FF (none)
Once we have a SSID, we can only update it to a better value,
but not clear it.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/438
Fixes: b83f07916a ('supplicant: large rework of wpa_supplicant handling')
NML3Cfg already handles IPv4 ACD. IPv4LL is just a small additional
layer on top of that, so it makes sense that it also is handled by
NML3Cfg.
Also, the overall goal is that multiple NMDevice and NMVpnConnection
instances can cooperate independently. So if multiple "users" enable
IPv4LL on an interface, then we should only run it once. This is
achieved by NML3IPv4LL's API where users register what they want,
and NML3IPv4LL figures out what that means as a whole.
Also, we thus will no longer need to use sd_ipv4ll/n-ipv4ll, because
we implement it ourself.
On the one hand, we want to keep the private fields internal. On the
other hand, we want to directly expose the NML3AcdAddrTrackInfo, so
that the user can access them without copying or calling a function.
Previously, there was some union ugliness and some padding involved.
That was probably correct, but lets solve this somewhat nicer by
having the private fields in a "_priv" struct and use NML3AcdAddrTrackInfo
throughout.
The DHCP client likes to order multiple default routes by adding
them with different, increasing metric.
To support that, let "metric_any" not completely disable the "metric"
field, but instead interpret it as an offset that should be added to
the default metric.
It's better to have a well-known, fixed MAC address on our test veth
devices.
Also, because later we will test IPv4 link local addressing, which
generates addresses by hashing the MAC address (among others).
- fix iterating logic in nm_l3cfg_add_config()
- fix preserving order during nm_l3cfg_commit_type_register()
- fix logic in _l3cfg_externally_removed_objs_drop_unused() to handle
all object types and not only routes.
- in nm-l3-config-data.c, fix coercing the route metric from metric_any
to the default metric.
- in _l3cfg_externally_removed_objs_drop_unused() and
_l3cfg_externally_removed_objs_track() ensure that the object is kept
alive long enough. The externally_removed_objs_hash hash keeps a
reference to the object, so when removing it, we either must no longer
access the object, or delay the destruction until later.
nm_auth_chain_new_subject() cannot return %NULL, so these checks are only
noise. Also, there are already calls that correctly rely on the fact that
this function cannot fail.
We use glib, where memory allocation by definition cannot fail. That means,
a lot of functions simply cannot fail in our code base. This is a very nice
property (to have an functions that cannot fail), so don't add error
checking that is not useful.
This results in the args of 'nm_utils_user_data_unpack'
containing random data potentially also from the
previous stack-frame which is really really bad.
Signed-off-by: Antonio Cardace <acardace@redhat.com>
Fixes: b50702775f ('device: implement auth-request as async operation nm_manager_device_auth_request()')
The wifi backends call nm_platform_wifi_get_quality and
nm_platform_wifi_get_rate one after another in periodic_update (every
6s) and the same information is queried twice, synchronously. For the
lack of a better mechanism to decide whether we're still inside the same
periodic_update call, store the timestamp in msecs and reuse the data
for 500ms.
As an optimization, use the NL80211_CMD_GET_STATION dump data instead
of the NL80211_CMD_GET_SCAN dump + GET_STATION command (non-dump) to
implement the following methods:
wifi_nl80211_get_bssid
wifi_nl80211_get_rate
wifi_nl80211_get_qual
GET_STATION records vary in size from a few hundred bytes to a few kB.
GET_SCAN records are usually on the few hundred bytes side, but there
can be many of them. In managed mode there will only be one
GET_STATION record. In AdHoc mode there may be more. These methods are
not used in AP or Mesh mode.
So without that patch we'd have a GET_SCAN dump that could be quite big
and then a GET_STATION with one record. Now it should be a GET_STATION
dump with one record or a few records, in any case fewer synchronous
commands is better. Additionally this should now not depend on the
currently-connected BSS being in the kernel's scan result cache.
The downside is that the signal strength is "optional" in the
GET_STATION records, depends on the driver's capabilities. Most
mainline drivers do seem to include it (the mac80211 based ones and a
few full-mac ones) but I can't know if all of them do.
As an optimization, implement wifi_nl80211_get_freq() using the
GET_INTERFACE nl8022 command instead of the GET_SCAN dump.
The GET_SCAN dump can be over 10kB of data that the kernel has to build
and we have to parse. Additionally the GET_SCAN dump is not guaranteed
to contain the currently-connected BSS if there was no recent scan (30s),
or if the recent scan missed the beacon from the current BSS, or if the
recent scan was for a subset of channels/SSIDs/BSSIDs etc. and the last
full scan was already flushed. Scan results are flushed after (I think)
30 seconds or if a new scan has the flush flag set.
In IWD we do occasionally do partial scans (on a subset of channels or
for a specific SSID) with the flush flag. In that case the previous
wifi_nl80211_get_freq() logic would probably return 0.
For historic reasons is NMSettingBond implemented differently from other
settings. It uses a strdict, and adds some validation on top of that.
The idea was probably to be able to treat bond options more generically.
But in practice we cannot treat them as opaque values, but need to know,
validate and understand all the options. Thus, this implementation with a
strdict is not nice.
The user can set the GObject property NM_SETTING_BOND_OPTIONS to any
strdict, and the setter performs no validation or normalization. That
is probably good, because g_object_set() cannot return an error to
signalize invalid settings. As often, we have corresponding C API like
nm_setting_bond_add_option() and nm_setting_bond_remove_option(). It
should be possible to get the same result both with the C API and with
the GObject property setting. Since there is already a way to set
certain invalid values, it does not help if the C API tries to prevent
that. That implies, that also add-option does not perform additional
validation and sets whatever the user asks.
Remove all validation from nm_setting_bond_add_option() and
nm_setting_bond_remove_option(). This validation was anyway only very
basic. It was calling nm_setting_bond_validate_option(), which can check
whether the string is (for example) and integer, but it cannot do
validation beyond one option. In most cases, the validation needs to
take into account the bond mode or other options, so validating one
option in isolation is not very useful.
Proper validation should instead be done via nm_connection_verify().
However, due to another historic oddity, that verification is very
forgiving too and doesn't reject many invalid settings when it should.
That is hard to fix, because making validation more strict can break
existing (and working) configurations. However, verify() already contains
basic validation via nm_setting_bond_validate_option(). So in the previous
behavior nm_setting_bond_add_option() would silently do nothing (only
returning %FALSE) for invalid options, while now it would add the
invalid options to the dictionary -- only to have it later fail validation
during nm_connection_verify(). That is a slight change in behavior, however it
seems preferable.
It seems preferable and acceptable because most users that call
nm_setting_bond_add_option() already understand the meaning and valid
values. Keyfile and ifcfg-rh readers are the few exceptions, which really just
parse a string dictionary, without need to understand them. But nmtui
or nmstate already know the option they want to set. They don't expect
a failure there, nor do they need the validation.
Note that this change in behavior could be dangerous for example for the
keyfile/ifcfg-rh readers, which silently ignored errors before. We
don't want them to start failing if they read invalid options from a
file, so instead let those callers explicitly pre-validate the value
and log an warning.
https://bugzilla.redhat.com/show_bug.cgi?id=1887523
