| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
|
| | |
| |
| |
| | |
https://bugzilla.gnome.org/show_bug.cgi?id=794329
|
| | |
| |
| |
| |
| |
| |
| | |
There are cases, where we need the untranslated text.
There is no change of behavior of this patch, because all
callers now explicitly call gettext().
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
| |
use nmc_print() for the job.
|
| |\
| |
| |
| |
| | |
Fix setting PrimaryConnection for VPNs.
https://github.com/NetworkManager/NetworkManager/pull/158
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If a VPN with default route is activated, the Manager's
PrimaryConnection property is not updated to indicate the VPN as
primary connection.
This happens because the PrimaryConnection property gets updated when
the default_ipX_device property of NMPolicy changes, and the primary
connection is set to the activation request currently pending on the
default device. We select the base (for example, ethernet) device as
best device and therefore the NMActRequest active on it is selected as
primary connection.
This patch fixes the problem by properly selecting the VPN as
primary. It seems a better choice to track best active connections
directly from NMPolicy instead of going through two steps.
|
| |/
|
|
|
| |
As the FIXME suggests, select the VPN with best metric to determine
the best IP config.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Commit 10753c36168a ("manager: merge VPN handling into
_new_active_connection()") added a check to fail the activation of
VPNs when a device is passed to ActivateConnection(), since the device
argument is ignored for VPNs.
This broke activating VPNs from nm-applet as nm-applet sets both the
specific_object (parent-connection) and device arguments in the
activation request.
Note that we already check in _new_active_connection() that when a
device is supplied, it matches the device of the parent
connection. Therefore, the check can be dropped.
Reported-by: Michael Biebl <biebl@debian.org>
Fixes: 10753c36168a82cd658df8a7da800960fddd78ed
https://github.com/NetworkManager/NetworkManager/pull/159
|
| |
|
|
| |
Fixes: 1cdb36b8de5ad942fed979c8838e5df63a1edcb0
|
| | |
|
| |
|
|
| |
Fixes: 0827d4c2e402b8c82d58e053e922d9d22679b960
|
| |
|
|
| |
Fixes: 2ac5860a064e99587751e6cffb0b30e60e0566db
|
| |
|
|
|
|
|
|
| |
Path to pppd can be set via configure flag but the source code ignores it.
Let's use PPPD_PATH like other calls of nm_utils_find_helper do.
https://bugzilla.gnome.org/show_bug.cgi?id=796752
|
| |
|
|
|
|
|
| |
configure.ac defines it just like it defines other PATH variables
for use with nm_utils_find_helper. Meson for some reason did not.
https://bugzilla.gnome.org/show_bug.cgi?id=796752
|
| |\
| |
| |
| | |
https://github.com/NetworkManager/NetworkManager/pull/143
|
| | |
| |
| |
| |
| |
| | |
Add support for a new wireguard link type to the platform code. For now
this only covers querying existing links via genetlink and parsing them
into platform objects.
|
| | |
| |
| |
| | |
Resolves Generic Netlink family ID by name.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The following commit:
b869d9cc0 device: add spec "driver:" to match devices
added two parameters ("driver" and "driver_version") to the
nm_match_spec_device() function.
However, the definition of the function and its declaration are not
consistent.
The prototype shows:
nm_match_spec_device (const GSList *specs,
const char *interface_name,
const char *driver,
const char *driver_version,
const char *device_type,
But the definition shows:
nm_match_spec_device (const GSList *specs,
const char *interface_name,
const char *device_type,
const char *driver,
const char *driver_version,
Since all parameters are pointers to const char, the type checking
succeeds at compile time.
All currently existing invocations of the function are correct and pass
the arguments in the order described in the definition/implementation.
This patch only changes the prototype so that potential future
invocations don't end up buggy.
Fixes: b869d9cc0dda4fe5300f5ec5b5a090199ecd4e3e
|
| | |
| |
| |
| |
| | |
On slow architectures it can take longer then 3s for the test service to
start up.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The @connection argument can be NULL; add the (allow-none) annotation
otherwise calling the API with a NULL argument through GObject
introspection fails with:
Argument 1 does not allow None as a value
Fixes: 278fd4fb0fde3f290e366dab91fb6a49f9ff186c
|
| |\ \
| | |
| | |
| | | |
https://bugzilla.gnome.org/show_bug.cgi?id=796645
|
| | | |
| | |
| | |
| | |
| | |
| | | |
gretap and ip6gretap ip-tunnel interfaces encapsulate L2 packets over
IP. Allow adding a wired setting for such connections so that users
can change the interface MAC.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add platform support for IP6GRE and IP6GRETAP tunnels. The former is a
virtual tunnel interface for GRE over IPv6 and the latter is the L2
variant.
The platform code internally reuses and extends the same structure
used by IPv6 tunnels.
|
| | | |
| | |
| | |
| | |
| | | |
Add platform support for GRETAP tunnels (Virtual L2 tunnel interface
GRE over IPv4) partially reusing the existing GRE code.
|
| | | |
| | |
| | |
| | | |
Print all the platform-lnk attributes in a consistent manner.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
They should return a gboolean, not an int.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Certain platform operations are logged both in nm-platform.c and
nm-linux-platform.c, resulting in duplicate messages. Drop log prints
from the latter.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Input and output flags are 16 bit.
Fixes: 91bf0efaa7dbfed84954192a449f6770d20105c1
|
| |/ /
| |
| |
| |
| |
| | |
GRETAP have an Ethernet-like hardware address.
Fixes: e2270040c0a25bee1549dda9054cca482b896819
|
| |\ \
| | |
| | |
| | | |
https://github.com/NetworkManager/NetworkManager/pull/147
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Although we don't really need protect for thread safety in _nm_utils_init(),
avoid using static variables without lock/atomic operations. libnm is not
thread-safe, but we still should try to avoid potential issues whenever it is
easy.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
constructor functions are ugly, because code is running before
main() starts. Instead, as the registration code for NMSetting types
is insid the GType constructor, we just need to ensure at the
right place, that the GType was created.
The right place here is _register_settings_ensure_inited(), because
that is called before we need the registration information.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
_nm_register_setting() and _nm_register_setting_impl() are called from within
the GType constructor for the NMSetting subtype. As such, at that point it
runs inside a g_once_init_enter() block. However, each implementation
for initializing the GType has a separate g_once_init_enter() variable, hence,
if two threads create GType instances for different NMSetting subclasses, there
is a race.
libnm is not thread safe. However, it should be at least thread safe
with respect to constructing the GType instances.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
NMSetting
For NMSetting subtypes, we need the static dictionaries "registered_settings" and
"registered_settings_by_type" to keep track of existing NMSetting types.
Initialize these dictionaries inside NMSetting's type initialization code.
This is guaranteed to run before any use of NMSetting type, and is also
guarded by a mutex.
Also, drop the __attribute__((constructor)) function to initialize the
hash tables. They are not needed, and it's ugly to run code before
main().
|
| | |
| |
| |
| |
| | |
Also backport the ABI to 1.12.2 (and thus, don't bother
initially adding the API as libnm_1_14_0).
|
| | |
| |
| |
| | |
Fixes: c1bafea71831994b54d0d9f104005b08797d3e2d
|
| | |
| |
| |
| | |
Fixes: 191c9c7f0d941a34446d26637db535a3ec1c57d8
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This disables loading the system-wide dnsmasq from /etc/dnsmasq.conf
and defines to use the NMSTATEDIR device-unique dhcp-leasefile,
preventing it from trampling over others, and isolating it to just
the wifi-ap use.
https://github.com/NetworkManager/NetworkManager/pull/156
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`nm-online --wait-for-startup` isn't really intended to be called directly.
It is mainly for implementing "NetworkManager-wait-online.service".
Anyway, at the end, the result does not indicate the connectivty status
of the host. Hence, printing
Connecting............... 30s [online]
is misleading. It merely means, that startup is complete. Likewise,
printing "[offline]" would not mean that there is no connectivity.
Instead, it means that startup is still in progress on timeout.
As it is now, the distinction between whether to print "start-pending"
and "failure" is not very clear. Not that it matters much. At least is
corresponds to the exit status of the program. If we sometimes confuse
EXIT_FAILURE_OFFLINE with other failure reasons, the exit status needs
to be corrected first.
https://github.com/NetworkManager/NetworkManager/pull/152
|
| | |
| |
| |
| | |
This was an accidental ommission.
|
