Also, track sd_lldp_neighbor instance directly.
sd_lldp_neighbor is a perfectly reasonable container for keeping
track of the LLDP neighbor information. Just keep a reference to
it, and don't clone the data. Especially since the LLDP library
keeps a reference to this instance as well.
Also, to compare whether two neighbors are the same, it is sufficient
to only consider the raw data. Everything else depends on these fields
anyway.
This is only possible and useful becuase sd_lldp_neighbor is of course
immutable. It wouldn't make sense otherwise, but it also would be bad
design to mutate the sd_lldp_neighbor instances.
This couples our code slightly more to the systemd code, which we usually
try to avoid. But when we move away in the future from systemd LLDP library,
we anyway need to rework this heavily (and then too, we wouldn't want
to clone the data, when we could just share the reference).
Allocating and growing the buffer with realloc isn't really
complicated. Do that instead of using a CList.
Also, if there is only one element, then we can track it in-place.
NM_UTILS_LOOKUP_STR_DEFINE() is implemented via a switch statement.
You'd expect that the compiler could optimize that to plain lookup,
since all indexes are consecutive numbers. Anyway, my compiler doesn't,
so use the array ourself.
Note that NM_UTILS_LOOKUP_STR_DEFINE() is exactly intended to lookup
by enum/integer, if the enum values are not consecutive numbers. It may
not be best, when you can directly use the numbers as lookup index.
VARDICT sounds like it would be a variant of "a{sv}" type. But it
can be really any GVariant. Rename to make the type more generic.
This will be used to also hold a binary variant of type "ay".
Currently the LLDP parsing code uses GVariantBuild, which possibly does not
ensure a stable order of elements. Thus the test may not be stable.
However, that will be fixed very soon.
Yes, fewer lines of code is often better, if that means the code itself is
simpler. Code doesn't get simpler by cramping more in the same line.
Have every value on a separate line.
Also, vertically align the table.
Autoconnect-slaves currently forces an activation of all slaves, even
if there is already an active connection for them. This is bad because
at boot slaves first try to autoconnect, then the autoconnect-slaves
of the master kicks in and disconnects/reactivates them.
The only reason why the forceful reactivation was added was to fix
[1]; in that scenario, a slave connection is already active as
non-slave; then it is updated to be a slave; later, the master with
autoconnect-slaves is manually activated. NetworkManager should detect
that the slave connection must now be activated by autoconnect-slaves.
Add a specific check for such situation, instead of always
reactivating all slaves.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1845018
Fixes: 4985ca5ada ('manager: allow autoconnect-slaves to reconnect the same connection')
When a device is not marked as unmanaged, but also not actively managed
by NetworkManager, then NetworkManager will generate an in-memory
profile to represent the active state, if the device is up and
configured (with an IP address).
Such profiles are commonly named like "eth0", and they are utterly
confusing to users, because they look as if NetworkManager actually
manages the device, when it really just shows that somebody else configures
the device.
We should express this better in the UI, hence add flags to indicate
that.
In practice, such profiles are UNSAVED, NM_GENERATED, and VOLATILE. But
add an explicit flag to represent that.
https://bugzilla.redhat.com/show_bug.cgi?id=1816202
When there are two patch ports connected, each of them must reference
the other; however they can't be created in a single transaction
because they are part of different bridges (so, different
connections). Therefore, the first patch that gets activated will
always fail with "No usable peer $x exists in 'system' datapath" until
the second patch exists.
In theory we could also match the error message, however this doesn't
seem very robust as the message may slightly change in the future.
Psrse the 802.11 IEs after parsing the security information.
Previously the OWE transition mode flag was potentially removed
in case the security properties changed.
Signed-off-by: David Bauer <mail@david-bauer.net>
Commit 37e7fa38c2 ("nm-supplicant-interface: enable OWE security
when transition mode is available") adds the OWE security flag in
case a valid OWE transtition mode IE is present on the beacon.
It also removes the OWE security flag in case the Iinformation elements
of a beacon are updated and a OWE transition mode IE can't be found.
When a pure OWE AP updates it's Information Elements (e.g. BSS Load
Element), the OWE security flag is falsely removed.
Introduce a new NM_802_11_AP_SEC_KEY_MGMT_OWE_TM security flag and use
it exclusively for OWE transition mode. Don't use the
M_802_11_AP_SEC_KEY_MGMT_OWE security flag on transition-mode APs.
Signed-off-by: David Bauer <mail@david-bauer.net>
Systemd's LLDP client also internally tracks all neighbours, and it thus
already needs a maximum already. For systemd, that is currently 128.
We don't need to implement our own rate limiting on top of that,
because if we wouldn't trust the LLDP client to get this right,
it would be DoS-able already.
Also decrease the number of maximum neighbours from 4k to 128.
Note that already previously we wouldn't ever get more than 128
entries.
nm_keyfile_read() and nm_keyfile_write() will be public API.
As such, it must be flexible and extendible for future needs.
There is already the handler callback that fully solves this
(e.g. a future handler event could request whether a certain
behavior is enabled or not).
As additional possibility for future extension, add a flags
argument. Currently no flags are implemented.
From inside a callback 4 properties are potentially interesting
to all callbacks: the currenty group, key, setting and property-name.
Refactor the code to track these properties in NMKeyfileHandlerData
and distinguish between the property name and the keyfile key.
Setting the error on the callback does not work well from bindings.
Instead, let bindings call a (future) nm_keyfile_handler_data_fail_with_error()
function on the handler_data to indicate failure.
As the keyfile handler callback will become public API, it needs to be
usable via bindings. A plain void pointer is not usable. Instead, add
a new type that can be used via introspection.
This will become public API. The enum for read and write callback
serves very similar purposes. Merge them so that we have fewer
types in the public API.
6876b73ec113 all: rework logging to append logging messages to the event queue
65ca0e4bea32 client: check length of client id for n_dhcp4_client_config_set_client_id()
6a9ca10b7ad6 client: close timer file descriptor explicitly when EPOLL_CTL_ADD fails
e5f3b27f5301 connection: don't fail dispatch in case of receive errors
68790d5ec950 connection: keep trying after a failure in send()
788b03891cd0 n-dhcp4: fix logging macro
6cd0fd5e8b3f probe: request previous address after expiration
ef11c7079ad7 connection: avoid double free of NDhcp4Outgoing
922a9a2326e7 n-dhcp4: fix initialization of the 'secs' DHCP header field
7fff54117436 outgoing: fix uninitialized variable in n_dhcp4_outgoing_append()
27547faaf258 probe: move back to INIT after lease expires
d07cb4e32884 incoming: accept options that are longer than requested
34d365e2267f client: handle invalid return codes gracefully during n_dhcp4_client_dispatch()
2e8c6017f85b n-dhcp4: use packet socket in rebinding state
9a7c82143c06 n-dhcp4: support init-reboot state
e615e3f5b063 n-dhcp4/socket: use SO_REUSEADDR on UDP socket
8dbfa1ad2549 merge branch 'bengal:log'
6e50189fba86 n-dhcp4: log outgoing packets
aea0315d3862 n-dhcp4: log incoming packets
1ca64a82393d n-dhcp4: add logging API
72c16a0028ac client-probe: fix state transitions on timer dispatch
c023ae2ad829 merge branch 'leasetime'
780f94c333ca lease: add n_dhcp4_client_lease_get_basetime()
a94378274cf4 incoming: don't handle 0xFFFFFFFF timestamps special in n_dhcp4_incoming_query_u32()
6bb277aefe0b probe: unconditionally pass ownership of message in n_dhcp4_client_probe_dispatch_io()
1cf87c90c6a1 probe: fix leaking message during client probe
55239cef2d63 lease: remove unreachable code in n_dhcp4_incoming_get_timeouts()
fa5ee7903061 lease: expose the server IP address
0cfce4a4fe07 all: merge branch 'th/build-centos76'
cae4868e5f7e all: avoid {net,linux}/if.h clashes on old distros
05859a3e4d32 all: avoid c_min() macro to work with old GCC
0be7033dd940 probe: arm timers in bound state
8735cdb0f95f ci: switch to c-util automation
a0bb7c69a11a client: fallback to CLOCK_MONOTONIC for timerfd
308cb242caf7 ci: disable valgrind run
468c93195ad3 build: update submodules
9d0f690f9ee8 ci: switch to github actions
9ba143a037bb probe: allocate memory of right size in n_dhcp4_client_probe_option_new()
2546aa2c809d util/link: suppress gcc warning
e4a01f5870a6 ci: drop broken armv7hl
2e2fbfa18f2c build: update submodules
6277dfd20eca Merge pull request #2 from NetworkManager/th/declaration-after-statement
1b660ae2d12a outgoing: avoid "-Werror=declaration-after-statement" warning with static_assert
f34a54cd9719 client/probe: fix memory leak
21e68f3bba80 client/connection: fix memory leak
git-subtree-dir: shared/n-dhcp4
git-subtree-split: 6876b73ec113328712a5cdc2ffb9497fd774c0e2
../src/nm-manager.c: In function periodic_update_active_connection_timestamps:
../src/nm-manager.c:7358:43: error: t may be used uninitialized in this function [-Werror=maybe-uninitialized]
nm_settings_connection_update_timestamp (nm_active_connection_get_settings_connection (ac),
^
Fixes: 6f3ae8a563 ('core: in periodic_update_active_connection_timestamps() use same timestamp')
We don't need the mask argument. If the caller wants to check only for certain
flags, she can do that right away with
NM_FLAGS_ANY (nm_settings_connection_autoconnect_blocked_reason_get (sett_con), flags)
When the secrets for a connection are updated, unblock autoconnection
in case it had been blocked previously due to bad or no
secrets. Otherwise we would need to manually activate the connection
or restart NM to get another try with the new secrets.
As commit ccfe5fec8d ('wifi: don't autoconnect to networks that have
never been successful') explains, Wi-Fi profiles only autoconnected
if they had no or a positive timestamp.
The problem that tried to solve is when a user accidentally clicks on a
Wi-Fi network in applet. Then the created profile may not be usable
(because of wrong credentials). To avoid indefinitely to autoconnect,
uch a profile will have a timestamp of 0, which prevents further
auto activations.
However, I find that problematic.
An important use case is pre-deploying profiles. In that case, the user
cannot set the timestamp, because the timestamp cache
/var/lib/NetworkManager/timestamps is internal, undocumented API. Also,
ifcfg-rh doesn't support the timestamp and anyway, does the timestamp
of the NMConnection does not get honored (only the one from the
timestamps file).
Maybe that could be an alternative solution here, to allow the user to
mark profiles as "I really want it to autoconnect". But that seems
unnecessary and wrong to me.
The problem really is that the user cannot do anything to ensure that
autoconnect will work tomorrow (short of editing the timestamps
database). The problem is that the property of whether a profile
every connected successfully is not in direct control of the user (it
depends on external conditions).
If the user has bogus profiles configured, those profiles should be
deleted (or autoconnect disabled) and not keep autoconnect blocked.
Also note that if you are at home and accidentally click on your
neighbour's Wi-Fi network, then you presumably still also have a working
profile to your own network. That usable profile will have a more
recent timestamp and be preferred during autoconnect already.
This reverts commit ccfe5fec8d.
https://bugzilla.redhat.com/show_bug.cgi?id=1781253
Updating the timestamp marks the keyfile database as dirty. Avoid
that, if there is no change. Of course, nm_key_file_db_set_value()
itself already checks whether the are any changes, and does nothing
if there aren't.
Simply perform the check earlier, to do nothing.
When performing a synchronous action together (like iterating
over all settings and set the current timestamp), it's nicer
to pretend that all this would happen instantaneously. That means,
ensure we use the same timestamp throughout.
On a minor point, there really is no need to call time() multiple times.
Code like
»···»···if (strcmp (tag, "net.ifnames") == 0)
»···»···»···net_ifnames = strcmp (argument, "0") != 0;
is really hard to understand (at least to me). Compare to
»···»···if (nm_streq (tag, "net.ifnames"))
»···»···»···net_ifnames = !nm_streq (argument, "0");
