Calling va_start() (with va_end()) in between seems to work and
is done by systemd and other code occasionally.
However, it's not clear that this really works on every architecture.
So just replace thise one instance with a different implementation
by passing the arguments as an array.
First, cb751012a2 mistakenly converted the
act_stage_context_step() in connect_ready() to connect_context_clear()
instead of connect_context_step(). This would cause the IP Type retry
logic to fail and no further types to be tried. It also throws
away the ctx->first_error and causes all errors that MM returns on the
connect attempt to be dropped on the floor.
Second, not all errors should cause an advance to the next IP Type,
since some errors aren't related to it. Specifically, MM_CORE_ERROR_RETRY
when using Simple.Connect() means that a timeout was reached
in the internal connect logic, not a modem or network error. In
that case, try the connect again with the same IP Type before advancing
to the next type.
Fixes: cb751012a2
Tested-by: Ladislav Michl <ladis@linux-mips.org>
Tested-by: Tore Anderson <tore@fud.no>
Seems that "dash" has issues with trap EXIT. This causes
test failures on systems where the default shell is not "bash".
[thaller@redhat.com: patch extracted from BZ and modified to
use bash everywhere]
https://bugzilla.gnome.org/show_bug.cgi?id=761146
"nm-vpn-service-plugin.h" includes "nm-connection.h", so there is already no
way to use "nm-vpn-service-plugin.h" without also pulling in all "NetworkManager.h".
On the other hand, we might not include "nm-vpn-service-plugin.h" in
"NetworkManager.h" to keep the overall headers small (by default).
But let's just include it too. We already opted for convenience
over small-include by having one top-level header file.
The crash from rh1301389 is probably not fixed by these changes.
The cause there is still unclear, however these changes seem
anyway correct. Merge them.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1301389
Specifically for resolvconf, if the write succeeded, but the pclose()
failed error would be left NULL and SR_ERROR would be returned, which
caused a crash in nm_dns_manager_end_updates().
Previously, we would log messages like:
#3 'pre-up' [tun0]: new request (1 scripts)
Journald interprets the "#" prefix as a severity level and
highlights them.
When the receive buffer is too small, we easily can hit ENOBUFS during recvmsg()
and need to resync the platform cache. But even worse, we possibly also loose
ACKs for pending netlink requests so that requests seem to fail (although they
might have succeeded).
Avoid that harder by increasing the buffer size to 8MB. This is also
done by networkd:
be660c371b
When we decide to add a new link, we alredy checked that no such link exists
(ignoring race conditions).
It is wrong to accept a EXITS failure when adding the link. There is no guarantee
that the existing link has all the same properties as the one we intend to add.
More importantly, this link was added externally outside of NetworkManager and it
should not be taken over.
Just treat EXISTS as a failure as any other.
When reading from netlink-socket fails with NLE_NOMEM, messages were
lost. In this case the cache must be resynced and all pending messages
from the socket are rejected via "event_handler_recvmsgs (platform, FALSE)".
In this case, we don't want to handle the received messages as the
cache anyway needs to resync. However, we are still interested in
all queued ACKs that are there.
We are also interested in RTM_NEWADDR messages which we use to detect
kernel support via _support_kernel_extended_ifa_flags_detect().
NM_DEVICE_CHECK_CON_AVAILABLE_FOR_USER_REQUEST is a multi-flag value combining all
the hooks that compose a user-request. Add a special value that has no esplicit
meaning except that it ~is~ a user-request.
For update, don't delete first and add it again. Just do it
in one step.
For recheck, don't delete all connections first to add them
all anew. Instead, check what changes and only emit the changed
signal if there are any actual changes.
