| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the kernel command-line doesn't contain an explict ip=$method,
currently the generator creates connections with both IPv4 and IPv6
set to 'auto', and both allowed to fail.
Since NM is run in configure-and-quit mode in the initrd, NM can get
an IPv4 address or an IPv6 one (or both) depending on which address
family is quicker to complete. This unpredictable behavior is not
present in the legacy module, which always does IPv4 only by default.
Set a required-timeout of 20 seconds for IPv4, so that NM will
preferably get an IPv4, or will fall back to IPv6.
See also: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/729
|
| |
|
|
|
|
| |
Change the logic in check_ip_state() to delay the connection ACTIVATED
state if an address family is pending and its required-timeout has not
expired.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new property to specify the minimum time interval in
milliseconds for which dynamic IP configuration should be tried before
the connection succeeds.
This property is useful for example if both IPv4 and IPv6 are enabled
and are allowed to fail. Normally the connection succeeds as soon as
one of the two address families completes; by setting a required
timeout for e.g. IPv4, one can ensure that even if IP6 succeeds
earlier than IPv4, NetworkManager waits some time for IPv4 before the
connection becomes active.
|
| | |
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/914
|
| | |
| |
| |
| |
| | |
Dunno whether the compiler can optimize this out. Assign to an auto
variable.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
nm_utils_random_bytes()
g_rand_new() reads /dev/urandom and falls back to timestamp and pid.
At this point, we already unsuccessfully tried getrandom()/urandom,
so that doesn't seem promising to try.
Try harder to get good random seeds for our GRand instance.
Have one global instance, that gets seeded with various things that come
to mind. The random sequence of that instance is then used to initialize
the thread-local GRand instances.
Maybe this is all snake oil. If we fail to get good randomness by using
kernel API, what can we do? But really, callers also don't know how they
should handle a failure to get random data (short of abort() or
logging), so there is value in nm_utils_random_bytes() trying really
the best it can, and callers pretending that it doesn't fail.
This aims to improve the fallback case.
|
| | |
| |
| |
| | |
Fixes: b01a453ca298 ('core: add nm_utils_random_bytes() and use getrandom()')
|
| | |
| |
| |
| | |
Fixes: 12df49f8ab45 ('platform: make NMPNetns thread-safe')
|
| | |
| |
| |
| |
| |
| | |
The previous implementation was just wrong.
Fixes: e1ca3bf7ed40 ('shared: add nm_strerror_native() to replace strerror() and g_strerror()')
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
_nm_thread_local is very neat, but when we allocate resources
we need to make sure that they are destroyed when the thread
exits.
We can use pthread_setspecific() for that, but using it is cumbersome.
Add a helper function to make that simpler.
Also, the number of possible pthread_key_t keys is limited. With this
way, we only need one key in total.
|
| |/
|
|
|
| |
We require these, otherwise we can get a linker error about
_nm_utils_monotonic_timestamp_initialized symbol being undefined.
|
| | |
|
| |
|
|
| |
Merge Request NetworkManager/NetworkManager!913
|
| |
|
|
| |
Fixes: 56a1a5426af5 ('all: add ipvX.dhcp-iaid properties')
|
| |
|
|
| |
Add the NEWS entries that were also present in 1.32.2 release.
|
| | |
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/906
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We have two GKeyfile files (timestamps and seen-bssids).
When a profile was deleted while NetworkManager was running, then
entries were removed from these keyfiles. But if a profile disappeared
while NetworkManger was stopped, then those UUIDs piled up.
This also happens if you have temporary connections in /run and reboot.
We need a way to garbage collect entries that are no longer relevant.
As the keyfile databases only get loaded once from disk, we will prune
all UUIDs for which we have no more connection loaded, on the first time
we write out the files again.
Note what this means: if you "temporarily" remove a connection profile
(without NetworkManager noticing) and restore it later, then the additional
information might have been pruned. There is no way how NetworkManager
could know that this UUID is coming back. The alternative is what we did
before: pile them up indefinitely. That seems more problematic.
|
| | |
| |
| |
| |
| | |
A helper function to remove entires that are no longer
relevant.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, there was no limit how many seen-bssids are tracked.
That seems problematic, also because there is no API how to get
rid of an excessive list of entries.
We should limit the number of entries. Add an (arbitrary) limit
of 30.
But this means that we drop the surplus of entries, and for that it
seems important to keep the newest, most recently seen entries.
Previously, entries were merely sorted ASCIIbetically. Now, honor
their order (with most recently seen first).
Also, normalize the BSSIDs. From internal code, we should only get
normalize strings, but when we load them from disk, they might be bogus.
As we might cut of the list, we don't want that invalid entries
cut of valid ones. And of course, invalid entries make no sense at
all.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
ifcfg-rh plugin never stored the seen bssid list to file, and
keyfile no longer does, and it's no longer parsed from GVariant.
So there is actually no way how anything could be set here.
The seen-bssids should only be populate from
"/var/lib/NetworkManager/seen-bssids". Nowhere else.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
"wifi.seen-bssid" is an unusual property, therefore very ugly due to the
inconsistency.
It is not a regular user configuration that makes sense to store to
disk or modify by the user. It gets populated by the daemon, and
stored in "/var/lib/NetworkManager/seen-bssids" file.
As such, how to convert this to/from D-Bus needs special handling.
This means, that the to/from D-Bus functions will only serialize the
property when the seen-bssids are specified via
NMConnectionSerializationOptions, which is what the daemon does.
Also, the daemon ignores seen-bssids when parsing the variant.
This has the odd effect that when the client converts a setting to
GVariant, the seen-bssids gets lost. That means, a conversion to GVariant
and back looses information. I think that is OK in this case, because the
main point of to/from D-Bus is not to have a lossless GVariant representation
of a setting, but to transfer the setting via D-Bus between client and
daemon. And transferring seen-bssids via D-Bus makes only sense from the daemon
to the client.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
"seen-bssids" primarily gets stored to "/var/lib/NetworkManager/seen-bssids",
it's not a regular property.
We want this property to be serialized/deserialized to/from GVariant,
because we expose these settings on the API like a property of the
profile. But it cannot be modified via nmcli, it cannot be stored
to ifcfg files, and it makes not sense to store it to keyfile either.
Stop doing that.
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
import gi
gi.require_version("NM", "1.0")
from gi.repository import NM
r = NM.IPRoutingRule.from_string('priority 10 type blackhole', NM.IPRoutingRuleAsStringFlags.AF_INET)
r.to_string(NM.IPRoutingRuleAsStringFlags.NONE)
r = NM.IPRoutingRule.from_string('priority 10 blackhole', NM.IPRoutingRuleAsStringFlags.AF_INET)
r.to_string(NM.IPRoutingRuleAsStringFlags.NONE)
r= NM.IPRoutingRule.from_string('priority 10 bogus', NM.IPRoutingRuleAsStringFlags.AF_INET)
# CRASH
Fixes: e922404990c9 ('libnm,core: support "prohibit"/"blackhole"/"unreachable" type routing rules')
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
On RHEL-8.5, s390x with gcc-8.5.0-2.el8, we get a compiler warning:
$ CFLAGS='-O2 -Werror=maybe-uninitialized' meson build
...
cc -Isrc/libndhcp4-private.a.p -Isrc -I../src -Isubprojects/c-list/src -I../subprojects/c-list/src -Isubprojects/c-siphash/src -I../subprojects/c-siphash/src -Isubprojects/c-stdaux/src -I../subprojects/c-stdaux/src -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11 -g -D_GNU_SOURCE -O2 -Werror=maybe-uninitialized -fPIC -fvisibility=hidden -fno-common -MD -MQ src/libndhcp4-private.a.p/n-dhcp4-c-connection.c.o -MF src/libndhcp4-private.a.p/n-dhcp4-c-connection.c.o.d -o src/libndhcp4-private.a.p/n-dhcp4-c-connection.c.o -c ../src/n-dhcp4-c-connection.c
../src/n-dhcp4-c-connection.c: In function ‘n_dhcp4_c_connection_dispatch_io’:
../src/n-dhcp4-c-connection.c:1151:17: error: ‘type’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
uint8_t type;
^~~~
https://github.com/nettools/n-dhcp4/pull/24
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This macro is deprecated and replaced by AC_USE_SYSTEM_EXTENSIONS
(which is already being called)
See:
- https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Obsolete-Macros.html
- https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Posix-Variants.html#AC%5fUSE%5fSYSTEM%5fEXTENSIONS
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/912
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nm-cloud-setup automatically detects routes, addresses and rules and configures them
on the device using the emphermal Reapply() API. That is, it does not modify the
existing profile (on disk), but changes the runtime configuration only.
As such, it used to wipe otherwise statically configured IP addresses, routes and
rules. That seems unnecessary. Let's keep the configuration from the (persistent)
configuration.
There is of course the problem that nm-cloud-setup doesn't really
understand the existing IP configuration, and it can only hope that
it can be meaningfully combined with what nm-cloud-setup wants to
configure. This should cover most simple cases, for more complex setups,
the user probably should disable nm-cloud-setup and configure the
network explicitly to their liking.
https://bugzilla.redhat.com/show_bug.cgi?id=1971527
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/893
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/908
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This function is badly named, because it has no NMHostnameManager self
argument. It's just a simple function that entirely operates on a string
argument.
Move it away from "nm-hostname-manager.h" to "libnm-glib-aux/nm-shared-utils.h".
Hostname handling is complicated enough. Simple string validation
functions should not obscure the view on the complicated parts.
|
| | | |
|
| |/
|
|
|
|
|
| |
- drop nm_hostname_manager_read_hostname() from header file.
It's only used internally.
- inline some code and drop helper functions.
|
| |
|
|
|
|
|
|
|
| |
rd.znet support was added with commit 11d4412ee155 ("process s390
specific device info from rd.znet parameter in nm-initrd-generator").
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
https://github.com/NetworkManager/NetworkManager/pull/362
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/904
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
We get it now always by "nm-macros-internal.h".
|
| | |
| |
| |
| |
| |
| | |
We already always include all of <glib.h>. <glib-unix.h> is small
and only not included by default to support non-UNIX systems,
which we don't care.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The numeric source IDs exist from a time before 2000, when there
was only one "GMainContext" singleton instance. Nowadays, the source
ID is only relative to one GMainContext, and you'd have to track
that association yourself. Als, g_source_remove() requires an additional
hash lookup, when you could simply track the GSource instance from the
start.
This API should not be used anymore. Operate on GSouce instances
direclty and use API like
nm_clear_g_source_inst()
nm_g_idle_add_source()
nm_g_idle_souce_new()
nm_g_source_attach()
g_source_attach
g_source_destroy
g_source_unref
etc.
Note that if you don't care about to ever remove a source again, like
scheduling an idle action that should not be cancelled, then
g_idle_add(callback, user_data);
is fine. It is only problematic to do something with those numeric IDs.
checkpatch.pl would also flag those uses, but these are just warnings
and in the few cases where such a warning is emitted wrongly, it's find
to ignore them.
|
| | |
| |
| |
| |
| |
| | |
Using the guint source ID always requires an additional hash lookup
during removal to find the real source instance. Use instead the
underlying GSource instance.
|
| | |
| |
| |
| |
| |
| | |
Searching over all sources in order to remove them is not what we want
to do. If you think you need these functions, instead keep track of the
GSource instances yourself.
|
