Also make sure the secrets request callback only send a reply to IWD and
the Connect method return callback executes the device state change to
"disconnected".
(cherry picked from commit 061913c588)
state_changed (called when IWD signalled device state change) was
supposed to not change NM device state on connect success or failure and
instead wait for the DBus Connect() method callback but it would
actually still call nm_device_emit_recheck_auto_activate on failure so
refactor state_changed and network_connect_cb to make sure
the state change and nm_device_emit_recheck_auto_activate are only
called from network_connect_cb.
This fixes a race where during a switch from one network to another NM
would immediately start a new activation after state_changed and
network_connect_cb would then handle the Connect failure and mark the
new activation as failed.
(cherry picked from commit 44af62eb1f)
When creating the mirror 802.1x connections for IWD 802.1x profiles
set the NM_SETTING_SECRET_FLAG_NOT_SAVED flag on the secrets that
may at some point be requested from our agent. The saved secrets could
not be used anyway because of our use of
NM_SECRET_AGENT_GET_SECRETS_FLAG_REQUEST_NEW in
nm_device_iwd_agent_query. But also try to respect whatever secret
caching policy has been configured in the IWD profile for those secrets,
IWD would be responsible for storing them if it was allowed in the
profile.
(cherry picked from commit e3aba12d14)
In two places stop using g_dbus_proxy_new_* to create whole new
interface proxy objects for net.connman.iwd.Network as this will
normally have a huge overhead compared to asking the ObjectManager
client that we already have in NMIwdManager for those proxies.
dbus-monitor shows that for each network path returned by
GetOrderedNetworks () -- and we call it every 10 or 20 seconds and may
get many dozens of networks back -- gdbus would do the following each
time:
org.freedesktop.DBus.AddMatch("member=PropertiesChanged")
org.freedesktop.DBus.StartServiceByName("net.connman.iwd")
org.freedesktop.DBus.GetNameOwner("net.connman.iwd")
org.freedesktop.DBus.Properties.GetAll("net.connman.iwd.Network")
org.freedesktop.DBus.RemoveMatch("member=PropertiesChanged")
(cherry picked from commit fd1cfa6db4)
char[] is not a char *; it can not go NULL.
test-ifupdown.c:147:27: error: address of array 'n->name' will always evaluate
to 'true' [-Werror,-Wpointer-bool-conversion]
g_assert (b->name && n->name);
test-ifupdown.c:156:27: error: address of array 'm->key' will always evaluate
to 'true' [-Werror,-Wpointer-bool-conversion]
g_assert (k->key && m->key);
(cherry picked from commit b64ae759ad)
libcurl does not allow removing easy-handles from within a curl
callback.
That was already partly avoided for one handle alone. That is, when
a handle completed inside a libcurl callback, it would only invoke the
callback, but not yet delete it. However, that is not enough, because
from within a callback another handle can be cancelled, leading to
the removal of (the other) handle and a crash:
==24572== at 0x40319AB: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24572== by 0x52DDAE5: Curl_close (url.c:392)
==24572== by 0x52EC02C: curl_easy_cleanup (easy.c:825)
==24572== by 0x5FDCD2: cb_data_free (nm-connectivity.c:215)
==24572== by 0x5FF6DE: nm_connectivity_check_cancel (nm-connectivity.c:585)
==24572== by 0x55F7F9: concheck_handle_complete (nm-device.c:2601)
==24572== by 0x574C12: concheck_cb (nm-device.c:2725)
==24572== by 0x5FD887: cb_data_invoke_callback (nm-connectivity.c:167)
==24572== by 0x5FD959: easy_header_cb (nm-connectivity.c:435)
==24572== by 0x52D73CB: chop_write (sendf.c:612)
==24572== by 0x52D73CB: Curl_client_write (sendf.c:668)
==24572== by 0x52D54ED: Curl_http_readwrite_headers (http.c:3904)
==24572== by 0x52E9EA7: readwrite_data (transfer.c:548)
==24572== by 0x52E9EA7: Curl_readwrite (transfer.c:1161)
==24572== by 0x52F4193: multi_runsingle (multi.c:1915)
==24572== by 0x52F5531: multi_socket (multi.c:2607)
==24572== by 0x52F5804: curl_multi_socket_action (multi.c:2771)
Fix that, by never invoking any callbacks when we are inside a libcurl
callback. Instead, the handle is marked for completion and queued. Later,
we complete all queue handles separately.
While at it, drop the @error argument from NMConnectivityCheckCallback.
It was only used to signal cancellation. Let's instead signal that via
status NM_CONNECTIVITY_CANCELLED.
https://bugzilla.gnome.org/show_bug.cgi?id=797136https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1792745https://bugzilla.opensuse.org/show_bug.cgi?id=1107197https://github.com/NetworkManager/NetworkManager/pull/207
Fixes: d8a31794c8
(cherry picked from commit fa40fc6d76)
The new hash table should destroy elements stolen from the hash table
returned by nm_utils_parse_variant_attributes().
Fixes: d094914120
(cherry picked from commit 31bda1b837)
Note that NMSettingEthtool and NMSettingMatch don't have such
functions either.
We have API
nm_connection_get_setting (NMConnection *, GType)
nm_connection_get_setting_by_name (NMConnection *, const char *)
which can be used generically, meaning: the requested setting type
is an argument to the function. That is generally more useful and
flexible.
Don't add API which duplicates existing functionality and is (arguably)
inferiour. Drop it now. This is an ABI/API break for the current development
cycle where the 1.14.0 API is still unstable. Indeed it's already after
1.14-rc1, which is ugly. But it's also unlikely that somebody already uses
this API/ABI and is badly impacted by this change.
Note that nm_connection_get_setting() and nm_connection_get_setting_by_name()
are slightly inconvenient in C still, because they usually require a cast.
We should fix that by changing the return type to "void *". Such
a change may be possibly any time without breaking API/ABI (almost, it'd
be an API change when taking a function pointer without casting).
(cherry picked from commit a10156f516)
We cannot be sure who holds a reference to the proxy, and
who is gonna call us back after the VPN connection instance
is destroyed.
(cherry picked from commit 6ebb9091d2)
Got this assertion:
NetworkManager[12939]: <debug> [1536917977.4868] active-connection[0x563d8fd34540]: set state deactivated (was deactivating)
...
NetworkManager[12939]: nm-openvpn[1106] <info> openvpn[1132]: send SIGTERM
NetworkManager[12939]: nm-openvpn[1106] <info> wait for 1 openvpn processes to terminate...
NetworkManager[12939]: nm-openvpn[1106] <warn> openvpn[1132] exited with error code 1
NetworkManager[12939]: <info> [1536917977.5035] vpn-connection[0x563d8fd34540,2fdeaea3-975f-4325-8305-83ebca5eaa26,"my-openvpn-Red-Hat",0]: VPN plugin: requested secrets; state disconnected (9)
NetworkManager[12939]: plugin_interactive_secrets_required: assertion 'priv->vpn_state == STATE_CONNECT || priv->vpn_state == STATE_NEED_AUTH' failed
Meaning. We should either ensure that secrets_required_cb() signal callback
is disconnected from proxy's signal, or we gracefully handle callbacks at
unexpected moments. Do the latter.
(cherry picked from commit 92344dd084)
Set the execution bit on /usr/sbin/{ifup,ifdown} ghost files to match
the mode of same files installed by initscripts.
Otherwise, they will appear as changed according to rpm verify:
.M....... g /usr/sbin/ifdown
.M....... g /usr/sbin/ifup
when the alternatives mechanism is not in place.
# ll /usr/sbin/if{up,down}
-rwxr-xr-x. 1 root root 1651 Aug 24 06:23 /usr/sbin/ifdown
-rwxr-xr-x. 1 root root 5010 Aug 24 06:23 /usr/sbin/ifup
https://bugzilla.redhat.com/show_bug.cgi?id=1626517
(cherry picked from commit d8a972c575)
Seems rpmbuild does not honor the latest occurance with
--with test --without test
to disable tests. Work around that.
Fixes: ad850c4f03
(cherry picked from commit cc8c207120)
In general, when we build a package, we want no compiler warnings
and all unit tests to pass.
That is in particular true when building a package for the distribution
in koji. When builing in koji, we (rightly) cannot pass rpmbuild options, so
the default whether tests/compiler-warnings are fatal matter very much.
One could argue: let's have the tests/compiler-warnings fatal and fail the build.
During a build in koji for a Fedora release, we want them all pass. And if somebody
does a manual build, the person can patch the spec file (or use rpmbuild
flags).
However, note how commit "f7b5e48cdb contrib/rpm: don't force fatal warnings
with tests" already disabled fatal compiler warnings. Why? It seems
compiler warnings should be even more stable than our unit tests, as long
as you target a particular Fedora release and compiler version. So this
was done to support rebuilding an SRPM for a different Fedora release,
or to be more graceful during early development phase of a Fedora
release, where things are not as stable yet.
The exactly same reasoning applies to treating unit-tests failures as fatal.
For example, a recent iproute2 issue broke unit tests. That meant, with
that iproute2 release in build root, the NetworkManager RPM could not be built.
Very annoying.
Now:
- if "test" is enabled, that means both `make check` and compiler warnings
are treated fatal. If "test" is disabled, `make check` and compiler
warnings are still done, just not fatal.
- "test" is now disabled by default via the spec file. They are not fatal
when building in koji or when rebuilding the package manually.
- tests can be enabled optionally. Note that the "build_clean.sh"
script enables them by default. So, a user using this script would
need to explicitly "--without test".
(cherry picked from commit ad850c4f03)
- always enable more compiler warnings. They are not marked as breaking
the build anyway.
- also, always build with '--with-tests=yes'. Note that our autotools is
actually very nice. Even if you build '--with-tests=no', you still can
run `make check` and the tests are build on demand. The only
difference here is whether the tests are build during `make` or during
`make check`. While little difference, build everything during the
`make` step.
- when running tests, use `make -k check`. Even if they fail, we want to
run the entire test suite.
- also running tests are disabled, still run them. But don't let them
fail the build.
(cherry picked from commit 58b030f39a)
The correct way to create a tarball for release is
./contrib/fedora/rpm/build_clean.sh -r
Just ensure to issue this from a clean shell environment.
(cherry picked from commit 5894da67dc)
In libnm, we prefer opaque typedefs. gtk-doc needs to be patched to properly
generate documentation. Add a check for that.
Add a test. By default, this does not fail but just prints a warning. The test
can be made failing by setting NMTST_CHECK_GTK_DOC=1.
See-also: https://gitlab.gnome.org/GNOME/gtk-doc/merge_requests/2
(cherry picked from commit 02464c052e)
The NetworkManager spec file used to determine devel builds as those that
have an odd minor version number. In that case, the built package would
enable more-asserts.
-- By the way, why is '1.13.3-dev' considered a delopment version worthy of more
asserts, but a build from the development phase of the next minor release on
'nm-1-12' branch not?
Note that during the development phase of Fedora (and sometimes even afterwards),
we commonly package development versions from 'master'. For example '1.12.0-0.1',
which is some snapshot with version number '1.11.x-dev' (or '1.12-rc1' in this case),
but before the actual '1.12.0' release.
It's problematic that for part of the devel phase we compile the
package for the distribution with more assertions. This package is
significanly different and rpmdiff and coverity give different results
for them.
For example, the binary size of debug packages is larger, so first
rpmdiff will complain that the binary sized increased (compare to the
previous version) and then later it decreases again.
Likewise, coverity finds significantly different issues on a debug
build. For example, it sees assertions against NULL and takes that
as a hint as to whether the parameter can/shall be NULL. Keeping
coverity warnings low is already high effort to sort out false
positives. We should not invest time in checking debug builds with
coverity, at least not as long as there are more important issues.
But more importantly, the --with-more-asserts configure option governs whether
nm_assert() is enabled. The only point of existance of nm_assert() -- compared to
g_assert(), g_return_*() and assert() -- is that this variant is disabled by default.
It's only used for checks that are really really not supposed to fail and/or
which may be expensive to do. This is useful for developing and CI,
but it's not right to put into the distribution. It really enables
assertions that you don't want in such a scenario. Enabling them even
for distribution builds defeats their purpose. If you care about an
assertion to be usually/always enabled, you should use g_assert() or
g_return_*() instead.
What this changes, that "devel" builds in koji/brew do not have more-asserts
enabled. When manually building the SRPM one still can enable it,
for example via
$ ./contrib/fedora/rpm/build_clean.sh -w debug
Also our CI has an option to build packages with or without more-asserts
(defaulting to more asserts already).
(cherry picked from commit b4e2f83403)
If the user explicitly passes --with-netconfig=$PATH or --with-resolvconf=$PATH,
the path is accepted as is. We only do autodetection, if the binary was not found.
In that case, if the binary cannot be found in the common paths fail compilation.
(cherry picked from commit 5b36585a3d)
