Let the server decide which device to use if the user didn't explicitly
specify the interface, wireless access point or a wimax nsp.
The server will just reuse the device for an already active connection
or potentially do a better guess.
https://bugzilla.gnome.org/show_bug.cgi?id=730492
(cherry picked from commit 0e8a14cc5f)
The connection now might be being activated on another device. Defer the
removal until we're sure the activation request will proceed and only add the
active connection afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=730492
(cherry picked from commit 4cb97cf66f)
If a connection is already active let's keep it on the same device. This makes
it possible to reactivate a connection without client knowing which device is
it active on.
https://bugzilla.gnome.org/show_bug.cgi?id=730492
(cherry picked from commit 6e94f302b2)
I did a "ip link set lo name yolo" and now my NetworkManager triggers an
assertion failure. :( Nevertheless, the loopback interface is always ifindex=1.
(cherry picked from commit 36f7669a4c)
The previous patch 9ffcecf86a was
completely wrong.
It tried to fix callers that provided a floating GVariant reference.
We require the caller to unref @secrets, so the correct fix it to
ensure that the reference is not floating.
Fixes: 6793a32a8c
(cherry picked from commit 9ffcecf86a)
(cherry picked from commit 2071e4794f)
The limit seems to be too low and causes problems in libnm-glib. We increase
the limit and warn in libnm-glib if it was exceeded.
(cherry picked from commit 242fe0bfb0)
D-Bus default limit of replies per connection has been lowered to 128 due to
CVE-2014-3638, see:
http://cgit.freedesktop.org/dbus/dbus/commit/?id=5bc7f9519ebc6117ba300c704794b36b87c2194bhttps://bugs.freedesktop.org/show_bug.cgi?id=81053
The limit seems to be too low and causes problems in libnm-glib, that will not
return all NetworkManager connection profiles if there are too many of them
(roughly more than the limit). As a consequence, libnm-glib based clients will
not work properly.
Lets increase the limit in our D-Bus org.freedesktop.NetworkManager.conf
configuration as we had it before.
See also older commit d5b31d55fa that did the
opposite thing (removing the limit because the default D-Bus limit was 8192 at
that time).
This reverts commit 7daf63461d.
Turns out the removal of the second set of [] in configure.ac causes the command
to be wrong in 'configure' and the test to be incorrect.
The VPN connection requests secrets a few times; first it retrieves
only system-owned secrets to see if they are sufficient (and thus
doesn't need to bother the user), then it retrieves existing agent
owned secrets (so the user doesn't get a popup), then finally if
those aren't sufficient it asks the user interactively.
But if there was some error retrieving system secrets, or if there
weren't any system secrets at all, don't fail the VPN connection.
Just go on and ask the user for the secrets.
(cherry picked from commit 5b1cde1bfc)
Manual page claims that a missing configuration option for connectivity
interval means "300". That was not the case for a long time (never?).
https://bugzilla.gnome.org/show_bug.cgi?id=723350
Based-on-patch-by: Mathieu Trudel-Lapierre <mathieu.trudel-lapierre@canonical.com>
(cherry picked from commit 652853e0d0)
Conflicts:
src/nm-config-data.c
Calling read_entire_config() without passing a @cli argument would
always have caused an assert due to unset @o_config_main_file.
That is not a real problem as that situation didn't arise. Still
fix it.
(cherry picked from commit ae0608eef5)
NM always prepends the list of DNS domains received through DHCP to
the search list in /etc/resolv.conf, overriding the DHCP-supplied DNS
domain search order. This behavior is not entirely correct since it
changes the search order provided by system administrators.
We cannot simply avoid adding the DNS domain list to the search list
because this would break some configurations that rely on the 'domain'
option to deliver the search list.
This patch modifies the behavior of DNS manager to:
- insert the DHCP-provided 'domain' at the end of 'searches' option
so that 'searches' is always preferred
- ignore 'domain' if 'searches' option exists and 'domain' is a
single domain
https://bugzilla.gnome.org/show_bug.cgi?id=748900
(cherry picked from commit 6edc737173)
We have different kinds of plugins (settings, dhcp, dns).
Clearify, that we are about to load "settings" plugins.
(cherry picked from commit e9b9d9b627)
Hard to debug failures, if we don't print where the failure
happens.
(cherry picked from commit 500cbcba21)
Conflicts:
src/platform/tests/test-common.c
Support accepting more then one signal at a time.
It is to be expected, that one change in platform raises
several signals. Extend the assertion helpers to express
that.
(cherry picked from commit 050c644cce)
And nmtst_platform_ip6_routes_equal().
As already indicated by the comment, using memcmp() doesn't really work
here. It worked up to now, because the NMPlatformIP4Route structure has no
padding at the end.
If we would have a last 'guint8' member (as we will add later),
initializing an arry of routes on the stack would not clear the bytes
from the padding and the comparison using memcmp() would fail.
(cherry picked from commit d8d0c481b8)
Add a comment about the upstream bug that fixes
the suppressed memleak in libnl.
Also, add a different backtrace for the same bug.
It currently doesn't hit easily, because we don't
call nl_msg_parse() often. In the future we will
though.
(cherry picked from commit 8e2ad8a3bd)
It could be that the device was removed and the default route manager holds the
last reference:
Breakpoint 1, dispose (object=0x90e710 [NMDeviceTun]) at devices/nm-device.c:8588
8588 NMDevice *self = NM_DEVICE (object);
(gdb) bt
#0 0x000000000045d24e in dispose (object=0x90e710 [NMDeviceTun]) at devices/nm-device.c:8588
#1 0x00007ffff4d29b7c in g_object_unref (_object=0x90e710) at gobject.c:3133
#2 0x00000000004b0a61 in _entry_at_idx_remove (entry=<optimized out>) at nm-default-route-manager.c:192
#3 0x00000000004b0a61 in _entry_at_idx_remove (vtable=<optimized out>, self=<optimized out>, entry_idx=<optimized out>) at nm-default-route-manager.c:638
#4 0x00000000004adb51 in _ipx_update_default_route (vtable=0x7b1850 <vtable_ip6>, self=0x7da610 [NMDefaultRouteManager], source=<optimized out>) at nm-default-route-manager.c:814
#5 0x0000000000459ccb in nm_device_set_ip6_config (self=0x90e710 [NMDeviceTun], new_config=<optimized out>, commit=<optimized out>, reason=<optimized out>) at devices/nm-device.c:6213
#6 0x0000000000450c92 in ip6_config_merge_and_apply (self=0x90e710 [NMDeviceTun], commit=0, out_reason=0x0) at devices/nm-device.c:3670
#7 0x0000000000452d06 in update_ip_config (self=0x90e710 [NMDeviceTun], initial=<optimized out>) at devices/nm-device.c:6915
#8 0x000000000046253e in queued_ip_config_change (user_data=<optimized out>) at devices/nm-device.c:6945
#9 0x00007ffff4a257fb in g_main_context_dispatch (context=0x7ca3e0) at gmain.c:3111
#10 0x00007ffff4a257fb in g_main_context_dispatch (context=context@entry=0x7ca3e0) at gmain.c:3710
#11 0x00007ffff4a25b98 in g_main_context_iterate (context=0x7ca3e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#12 0x00007ffff4a25ec2 in g_main_loop_run (loop=0x7ca4a0) at gmain.c:3975
#13 0x0000000000444bbe in main (argc=<optimized out>, argv=<optimized out>) at main.c:486
(gdb)
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x7ffff4d4f164 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffd5b0) at gmessages.c:1046
1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 0x00007ffff4a2c970 in g_logv (log_domain=0x7ffff4d4f164 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffd5b0) at gmessages.c:1046
#1 0x00007ffff4a2cbaf in g_log (log_domain=log_domain@entry=0x7ffff4d4f164 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7ffff4d563b0 "invalid unclassed pointer in cast to '%s'") at gmessages.c:1079
#2 0x00007ffff4d481f9 in g_type_check_instance_cast (type_instance=0x90e710, iface_type=<optimized out>) at gtype.c:4030
#3 0x0000000000459ceb in nm_device_set_ip6_config (self=0x90e710, new_config=<optimized out>, commit=<optimized out>, reason=0x0) at devices/nm-device.c:6217
#4 0x0000000000450c92 in ip6_config_merge_and_apply (self=0x90e710, commit=0, out_reason=0x0) at devices/nm-device.c:3670
#5 0x0000000000452d06 in update_ip_config (self=0x90e710, initial=<optimized out>) at devices/nm-device.c:6915
#6 0x000000000046253e in queued_ip_config_change (user_data=<optimized out>) at devices/nm-device.c:6945
#7 0x00007ffff4a257fb in g_main_context_dispatch (context=0x7ca3e0) at gmain.c:3111
#8 0x00007ffff4a257fb in g_main_context_dispatch (context=context@entry=0x7ca3e0) at gmain.c:3710
#9 0x00007ffff4a25b98 in g_main_context_iterate (context=0x7ca3e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#10 0x00007ffff4a25ec2 in g_main_loop_run (loop=0x7ca4a0) at gmain.c:3975
#11 0x0000000000444bbe in main (argc=<optimized out>, argv=<optimized out>) at main.c:486
(gdb)
https://bugzilla.gnome.org/show_bug.cgi?id=748193
(cherry picked from commit 6fba9fd2e5)
