The macro EWOULDBLOCK is another name for EAGAIN; they are always the
same in the GNU C Library.
https://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Error-Codes.html
Otherwise, we would need a workaround for EWOULDBLOCK too, because
libnl maps that to NLE_FAILURE. So we would have to detect EAGAIN
as (nle == -NLE_FAILURE && errno == EWOULDBLOCK).
(cherry picked from commit d2fab2df54)
When the errno was accidentally set to EAGAIN or EWOULDBLOCK,
we would only read one single message and return that there is
nothing to read.
This means, if there were more then one messages ready to read,
we would only read the first one and return to the main-loop
(which then again calls back to platform as more data is ready
to be read).
(cherry picked from commit 10b684b827)
Unslaving from a bridge causes a wrong RTM_DELLINK event for
the former slave.
# ip link add dummy0 type dummy
# ip link add bridge0 type bridge
# ip link set bridge0 up
# ip link set dummy0 master bridge0
# ip monitor link &
# ip link set dummy0 nomaster
18: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop master bridge0 state DOWN group default
link/ether 76:44:5f:b9:38:02 brd ff:ff:ff:ff:ff:ff
18: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
link/ether 76:44:5f:b9:38:02
Deleted 18: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
link/ether 76:44:5f:b9:38:02
18: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
link/ether 76:44:5f:b9:38:02 brd ff:ff:ff:ff:ff:ff
19: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
19: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
Previously, during do_request_link() we would remember the link that is
about to be requested (delayed_deletion) and delay processing a new
RTM_DELLINK message until the end of do_request_link() -- and possibly
forget about about the deletion, if RTM_DELLINK was followed by a
RTM_NEWLINK.
However, this hack does not catch the case where an external command
unslaves the link.
Instead just accept the wrong event and raise a "removed" signal right
away. This brings the cache in an externally visible, wrong state that
will be fixed by a following "added" signal.
Still do that because working around the kernel bug is complicated. Also,
we already might emit wrong "added" signals for devices that are already
removed. As a consequence, a user should not consider the platform signals
until all events are processed.
Listeners to that signal should accept that added/removed link changes
can be wrong and should preferably handle them idly, when the events
have settled.
It can even be worse, that a RTM_DELLINK is not fixed by a following
RTM_NEWLINK:
...
# ip link set dummy0 nomaster
36: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop master bridge0 state DOWN
link/ether e2:f2:20:98:3a:be brd ff:ff:ff:ff:ff:ff
36: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
link/ether e2:f2:20:98:3a:be
Deleted 36: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
link/ether e2:f2:20:98:3a:be
37: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
37: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
So, when a slave is deleted, we have to refetch it too.
https://bugzilla.redhat.com/show_bug.cgi?id=1285719
(cherry picked from commit 8a87a91813)
Conflicts:
src/platform/nm-linux-platform.c
src/platform/tests/test-link.c
On some kernels (at least RHEL-7.2) we receive a spurious RTM_NEWLINK
message after the RTM_DELLINK message for deleting a bond master.
On RHEL-7, the following commands give:
# ip link add dummy0 type dummy
# ip link add bond0 type bond
# ip link set bond0 up
# ip link set dummy0 master bond0
# ip monitor link &
# ip link del bond0
21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noqueue state DOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
Deleted 21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
20: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
link/ether da:ee:58:70:6f:e5 brd ff:ff:ff:ff:ff:ff
^^^^^^^^^^^^^^^ RTM_NEWLINK after RTM_DELLINK (and there follows no
RTM_DELLINK afterwards)
21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
link/ether da:ee:58:70:6f:e5 brd ff:ff:ff:ff:ff:ff
20: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
20: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
Fix that by reverting clear_REFRESH_LINK(). This fix has two downsides:
- on kernels where this hack is not necessary, we unnecessarily refetch
a link
- the platform cache first removes the link, adds it again and removes
it. This is ugly, but should have no real consequences because all
listeners to the platform signals delay processing the signals to an
idle handler.
https://bugzilla.redhat.com/show_bug.cgi?id=1285719
This reverts commit f4f4e1cf09 (on master).
This reverts commit 91c00072f2 (on nm-1-0).
(cherry picked from commit 83240f24ae)
The related bug rh#1285827 in kernel causes a missing IFLA_LINK/parent
attribute when creating a veth pair:
# ip monitor link &
[1] 6745
# ip link add dev vm1 type veth peer name vm2
30: vm2@NONE: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
link/ether be:e3:b7:0e:14:52 brd ff:ff:ff:ff:ff:ff
31: vm1@vm2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN
link/ether da:e6:a6:c5:42:54 brd ff:ff:ff:ff:ff:ff
Add a workaround and test.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1285827
(cherry picked from commit 5650c82a8e)
Conflicts:
src/platform/nm-linux-platform.c
src/platform/tests/test-link.c
"platform" implements a iproute2 like command-line
tool based on NMPlatform.
It is badly maintained and mostly unused. If we want
to test something, we should write tests that are run
automatically during `make check`. Manual tests just
don't fly.
(cherry picked from commit f122879c83)
The program ran over the platform links and printed them.
Our to-string methods of platform objects are already supposed
to print all fields. So this only duplicates code to print a link.
If you want to see what links were picked up by platfrom run:
NMTST_DEBUG=log-level=TRACE ./src/platform/tests/monitor
or just
./src/platform/tests/monitor
Yes, this has less the iproute2 feeling, but it gives you a more
native access to the platform objects -- which is what you want
for debugging platform.
(cherry picked from commit d13d17f84a)
This gives us a way to externally configure the logging level like:
NMTST_DEBUG=log-level=TRACE ./src/platform/tests/monitor
(cherry picked from commit ca8e40e1dc)
Previsously, _LOGT() could be disabled at compile time. Thus it
was different then the other macros _LOGD(), _LOGI(), etc.
OTOH, _LOGt() was the macro that always was compiled in.
Swap the name of the macros. Now the upper-case macros are always
enabled, while the lower-case macro _LOGt() is enabled depending
on compile configuration.
(cherry picked from commit 9587867349)
Add a new 'ignore' option to NMSettingWired.wake-on-lan which disables
management of wake-on-lan by NetworkManager (i.e. the pre-existing
option will not be touched). Also, change the default behavior to be
'ignore' instead of 'disabled'.
https://bugzilla.gnome.org/show_bug.cgi?id=755182
(cherry picked from commit e587dcb16e)
We get a lot of these debugging message, although the event is entirely
internal to NMLinuxPlatform and only interesting when debugging a problem
in platform itself.
Downgrade to TRACE level.
(cherry picked from commit 9f1eb190f7)
For libnm library, "nm-dbus-interface.h" contains defines like the D-Bus
paths of NetworkManager. It is desirable to have this header usable without
having a dependency on "glib.h", for example for a QT application. For that,
commit c0852964a8 removed that dependancy.
For libnm-glib library, the analog to "nm-dbus-interface.h" is
"NetworkManager.h", and the same applies there. Commit
159e827a72 removed that include.
However, that broke build on PackageKit [1] which expected to get the
version macros by including "NetworkManager.h". So at least for libnm-glib,
we need to preserve old behavior so that a user including
"NetworkManager.h" gets the version macros, but not "glib.h".
Extract the version macros to a new header file "nm-version-macros.h".
This header doesn't include "glib.h" and can be included from
"NetworkManager.h". This gives as previous behavior and a glib-free
include.
For libnm we still don't include "nm-version-macros.h" to "nm-dbus-interface.h".
Very few users will actually need the version macros, but not using
libnm.
Users that use libnm, should just include (libnm's) "NetworkManager.h" to
get all headers.
As a special case, a user who doesn't want to use glib/libnm, but still
needs both "nm-dbus-interface.h" and "nm-version-macros.h", can include
them both separately.
[1] https://github.com/hughsie/PackageKit/issues/85
Fixes: 4545a7fe96
(cherry picked from commit 7bf10a75db)
When we receive an update for a link, cancel a scheduled
REFRESH_LINK delayed-action for that ifindex. At the point when we
scheduled refrehing the link, we only cared about receiving a
notification that was newer then the current state.
We scheduled requesting this new notification to resync the cache.
It is not necessary to actually request a new update, any update we
receive *after* requesting a new update will suffice.
This potentially saves extra round-trips re-requesting the link.
(cherry picked from commit f4f4e1cf09)
When moving a link to another netns, it gets removed from
NMPlatform's view.
Currently kernel does not sent a notification to inform about
that change (see related bug rh#1262908).
Ensure that we reload all linked interfaces which now might
have an invisible parent.
(cherry picked from commit 2cd6aaa918)
Due to a bug, we would only handle one REFRESH_LINK delayed action
and ignore the ones queued afterwards.
Fixes: 051cf8bbde
(cherry picked from commit eee240ffe8)
Defect type: CHECKED_RETURN
3. NetworkManager-1.0.6/src/platform/nm-linux-platform.c:1145: check_return: Calling "clock_gettime" without checking return value (as is done elsewhere 6 out of 7 times).
(cherry picked from commit 0f694f1a9a)
There seems to be an issue with glib/ffi that causes failures
to pass enum-typed arguments to signals (related bug rh#1260577).
Add a test for platform signals which, beside NM_CONFIG_SIGNAL_CONFIG_CHANGED,
is the only place where we use enum-typed arguments for signals.
Strangely, this test doesn't cause the failure, so it's unclear why
the workaround was necessary for "config-changed" signal (commit
e7d66f1df6).
(cherry picked from commit 52cd5ee612)
The parent of a link (IFLA_LINK) can be in another network namespace and
thus invisible to NM.
This requires the netlink attribute IFLA_LINK_NETNSID which is supported
by recent versions of kernel and libnl.
In this case, set the parent field to NM_PLATFORM_LINK_OTHER_NETNS
and properly handle this special case.
(cherry picked from commit 790a0713d2)
It can happen on a regular basis when many events get raised.
It is probalby not avoidable and most likely not an issue, so
downgrade the warning to info level.
(cherry picked from commit 7f9cb13057)
The logging macros _LOGD(), etc. are specific to each
file as they format the message according to their context.
Still, they were cumbersome to define and their implementation
was repeated over and over (slightly different at times).
Move the declaration of these macros to "nm-logging.h".
The source file now only needs to define _NMLOG(), and either
_NMLOG_ENABLED() or _NMLOG_DOMAIN.
This reduces code duplication and encourages a common implementation
and usage of these macros.
(cherry picked from commit ad7cdfc766)
Performing an ioctl on a non existent device may cause the automatic
load of a kernel module if the device name matches a module
alias. Check if the device actually exists before calling the ioctl.
(cherry picked from commit ab41c13b06)
For delete-events, we only need a shallow object with the key fields
set. That sufficies to lookup in the cache and find the object to
delete.
One other issue is that _nmp_vt_cmd_plobj_init_from_nl_link() and
link_extract_type() might call to ethtool for the already deleted
instance. Just avoid that.
https://bugzilla.redhat.com/show_bug.cgi?id=1247156
(cherry picked from commit a4c7176fe9)
Add an assert (g_return_val_if_reached()) that the interface name is
valid and shorter then 16 bytes. If it happened to be longer, strncpy()
would not have zero terminated the interface name.
(cherry picked from commit 5b123f2539)
Seems that team changed to now also raise two change signals.
Relax the assertion that broke tests on Fedora 22.
(cherry picked from commit 1c2883c940)
Coverity detected that it was always-true:
src/platform/nm-linux-platform.c:4035: dead_error_line: Execution cannot reach the expression "preferred != 0U" inside this statement: "if (lifetime != 0U || lifet...".
(cherry picked from commit da612acc6a)
This gets called for all links via link_get_permanent_address(). This could
easily be an infiniband address and we don't want to assert it's not.
(cherry picked from commit 31c8bd6b69)
