| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a copy of a few linux user space headers in `src/linux-headers`.
The idea is that we want to use recent kernel API, and not depend on the
kernel UAPI headers installed on the build system (and not need to
workaround that).
However, we may not be able to simply compile them, because they too
have dependencies. For example,
../src/linux-headers/ethtool.h:1389:2: error: implicit declaration of function '__KERNEL_DIV_ROUND_UP' [-Werror=implicit-function-declaration]
__u32 queue_mask[__KERNEL_DIV_ROUND_UP(MAX_NUM_QUEUE, 32)];
^
As workaround, don't include headers from "linux-headers" directly,
but only include the new "libnm-std-aux/nm-linux-compat.h" adapter
header, which tries to solve these incompatibilities.
Fixes: 34d48d2596f7 ('platform: clear all BASE types when setting advertised modes for ethernet autoneg')
|
| |
|
|
| |
Fixes: 34d48d2596f7 ('platform: clear all BASE types when setting advertised modes for ethernet autoneg')
|
| |\
| |
| |
| |
| |
| | |
https://bugzilla.redhat.com/show_bug.cgi?id=1897004#c10
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/972
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The check whether the current setting are already as expected are wrong.
The reason is that nm_platform_ethtool_set_link_settings() also sets
the announced ethernet modes, but nm_platform_ethtool_get_link_settings()
does not give them.
That means, we cannot check whether the current link configuration is
the same, because the getter doesn't give that information.
Consequently, we must not skip the setting on the assumption that
there is nothing to change.
This bug has bad effects. If the device is currently activated with ethtool
option set, then re-activating the profile will result in wrongly
skipping the update.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Disabling autoneg is not supported for Gigabit ethernet. But it seems that
ixgbe also doesn't honor
ethtool -s enp5s0f0 speed 100 duplex full autoneg off
As a workaround, when we disable autoneg then always set the advertised
modes too. I think (hope) that should not have a bad effect otherwise,
but seems most sensible for ixgbe.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is no point in logging the current speed/duplex. OK, with
the "*", we could at least see whether the printed values are
to be set, or are currently configured on the interface.
But mixing these two outputs is confusing and meaningless.
Either log what we are about to do, or what the current configuration
is. Not a mix of both.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
autoneg
Get the list of supported flags from ethtool utility ([1]).
When we enable auto-negotiation, the user may select only one mode to
be advertised. But then we need to clear all other modes, the previous
define BASET_ALL_MODES did not cover them all.
[1] https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/tree/ethtool.c?id=7cca9692b9b0c4e2c7eb7868a7791f97202014b0#n397
|
| | |
| |
| |
| |
| | |
I don't understand why this was done. I don't think it's necessary nor
correct.
|
| | |
| |
| |
| | |
set_link_settings_new()
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
libnm-platform.la depends on libnm-udev-aux and libnm-base.
Only by accident this was working, because we happened to use
no symbol in the test that required any of these dependencies.
A small change to the test can (and will soon) change that. Fix the
build to link the right library.
|
| | |
| |
| |
| |
| | |
Taken from "include/net/nl802154.h", Linux 5.14,
7d2a07b769330c34b4deabeed939325c77a7ec2f, Aug 30, 2021.
|
| | |
| |
| |
| |
| | |
Taken from Linux 5.14, 7d2a07b769330c34b4deabeed939325c77a7ec2f,
Aug 30, 2021.
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
On CentOS 7, gcc.x86_64 0:4.8.5-44.el7 fails compilation:
In file included from ./src/libnm-glib-aux/nm-default-glib.h:69:0,
from ./src/libnm-glib-aux/nm-default-glib-i18n-lib.h:13,
from src/libnm-core-aux-extern/nm-libnm-core-aux.c:6:
./src/libnm-glib-aux/nm-shared-utils.h:1051:1: error: '__thread' before 'extern'
_nm_thread_local extern char _nm_utils_to_string_buffer[2096];
^
Fixes: fb94903444db ('glib-aux: mark _nm_utils_to_string_buffer at thread-local')
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/968
|
| | |
| |
| |
| |
| |
| |
| | |
"_NM_L3_ACD_DEFEND_TYPE_NONE"
This value is only used internally. It's not part of the public API of
NML3Cfg, and not a value that users could/should set.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It's great to have functions that cannot fail, because it allows to
skip any error handling.
_set_stable_privacy() as it was could not fail, so the only reason why
nm_utils_ipv6_addr_set_stable_privacy() could fail is because the DAD
counter exhausted.
Also, it will be useful to have a function that does not do the counter
check, where the caller wants to handle that differently.
Rename some functions, and make the core nm_utils_ipv6_addr_set_stable_privacy()
not failable.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
While NMUtilsIPv6IfaceId is only 8 bytes large, it seems unidiomatic to
pass the plain struct around.
With a "const NMUtilsIPv6IfaceId *" argument it is more clear what the
meaning of this is.
Change to use pointers.
|
| | |
| |
| |
| |
| |
| |
| | |
The preference for IPv6 routes was added in kernel v4.1,
22 June 2015. It is even in latest RHEL7 kernels.
Drop trying to be compatible with such old kernels.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We use extended IFA_FLAGS for IFA_F_MANAGETEMPADDR (IPv6) and
IFA_F_NOPREFIXROUTE (IPv4 and IPv6).
These flags for IPv4 were added to kernel 3.14, 30 March, 2014.
The flag for IPv4 was added to kernel 4.4, 11 January 2016.
Even latest RHEL-7 kernels have backport for IFA_F_NOPREFIXROUTE
for IPv4 (rh#1221311).
Drop this. The backward compatibility code paths are likely broken
anyway, and add considerable complexity.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is supported since kernel 3.17, dated 5 October, 2014. Drop the backward
compatibility for that.
It's very hard to sensibly support a mode where we set the interface up,
but prevent kernel from enabling IPv6. We would hack around that by disabling
IPv6 altogether.
But these code paths are not tested and likely make no sense. And it's hard
to implement a sensible behavior in this case anyway.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The term "user_ipv6ll" is confusing and not something somebody familiar
with kernel or `ip -d link` would understand.
Also, it maps a boolean to addr-gen-mode "none" or "eui64", although
there are 2 more address generation modes in kernel.
Don't abstract the underlying API, and name things as they are in
kernel.
|
| | |
| |
| |
| | |
nm_device_activate_schedule_stage3_ip_config_start() should only... schedule.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NMDevice's act_stage3_ip_config_start() has an out parameter,
so that an NMIPConfig object can be returned. That is (luckily)
not used much, and it's fundamentally flawed. We want that
the start method becomes simpler and idempotent. That argument
is problematic there.
Instead, of the result is already ready, postpone the activation
and process the return on an idle handler.
Why not use nm_device_set_dev2_ip_config() to pass the configuration?
Good question, who knows? For now, just mimic the previous behavior.
Usually the IP configuration would be announced late, so we can just
do that artificially by scheduling an idle action.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The idea, that callers to nm_modem_stage3_ip4_config_start() pass
a NMDeviceClass, which then might invoke a virtual function on
the class is really bad.
nm_modem_stage3_ip4_config_start() should indicate what the caller
should do.
The main problem is, that act_stage3_ip_config_start() is not supposed
to be called by anybody except NMDevice. It's an internal hook, not for
NMModem's concern.
|
| | |
| |
| |
| | |
nm_device_activate_schedule_ip_config_timeout()
|
| | |
| |
| |
| |
| |
| |
| |
| | |
We possibly should refactor our code to no use _nm_utils_to_string_buffer,
but instead always provide a suitable (stack allocated?) buffer.
Until that is done, make the buffer thread local so that it avoids
the most obvious problem (of resulting in non-thread-safe code).
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
helpers
It can be convenient to track a NMPObject in form of their down-cast
pointers. When doing that, it's useful to have clear/ref-set helpers
that operate on such pointers and up-cast first.
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
| |
For most purposes, this makes no difference. But it allows
to write something like:
if ( ptr
&& nm_assert(check_ptr(ptr))
&& other_check(ptr))
...
|
| |\
| |
| |
| | |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/973
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This approach does not seem to work with clang 3.4 (rhel-7). Instead,
make sure we actually use the symbol in NetworkManager so that it gets
preserved for the OVS device plugin.
This reverts commit 684f2acffea3ed5704330bff05b87acbf371ccdd.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The two nm-sudo helper functions are only used by the OVS device plugin,
but they are part of NetworkManager core binary.
This is done commonly, where the NetworkManager binary has symbols that
are used by the plugins. But in this case, NetworkManager itself doesn't
use the symbols. That will case the linker to drop them.
A previous solution for that was commit 684f2acffea3 ('build: add way to
keep unused symbols when linking NetworkManager'), but that doesn't seem
to work with clang 3.4 (rhel-7).
Instead, actually use the symbol so that it cannot be dropped.
|
| |/
|
|
| |
It will be used next.
|
| |
|
|
| |
Fixes: 414d2c1d4b3e ('contrib,gitlab-ci: fix "contrib/fedora/REQUIRED_PACKAGES" to install "vala"')
|
| |
|
|
| |
Fixes: 53562b19150c ('contrib: remove "vala-tools" from "contrib/fedora/REQUIRED_PACKAGES"')
|
| |
|
|
| |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/971
|
| |
|
|
|
|
|
|
|
|
| |
The formatting produced by clang-format depends on the version of the
tool. The version that we use is the one of the current Fedora release.
Fedora 34 recently updated clang (and clang-tools-extra) from version
12.0.0 to 12.0.1. This brings some changes.
Update the formatting.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It fails to install the container. Disable it, until it is more
stable.
...
Install 363 Packages
Total download size: 275 M
Installed size: 1.1 G
Downloading Packages:
python3: allocatestack.c:191: advise_stack_range: Assertion `freesize < size' failed.
./contrib/fedora/REQUIRED_PACKAGES: line 17: 815 Aborted $NM_INSTALL "$@"
subprocess exited with status 134
subprocess exited with status 134
exit status 134
|
