There are three configuration options that contain device specs:
'main.ignore-carrier', 'main.no-auto-default', and
'keyfile.unmanaged-devices'.
Unify the parsing of them by splitting the device spec with
nm_match_spec_split(). This changes behavior for parsing of these
properties.
Also get rid of logging warnings when parsing 'keyfile.unmanaged-devices'.
(cherry picked from commit c6778ad1b7)
There are currently three device spec properties: 'main.ignore-carrier',
'main.no-auto-default' and 'keyfile.unmanaged-devices'.
The first two, called g_key_file_parse_value_as_string() to split
the string into individual device specs. This uses ',' as separator
and supports escaping using '\\'.
'keyfile.unmanaged-devices' is split using ',' or ';' as separator
without supporting escaping.
Add a new function nm_match_spec_split(), to unify these two behaviors
and support both formats. That is, both previous formats are mostly
supported, but obviously there are some behavioral changes if the string
contains one of '\\', ',', or ';'.
nm_match_spec_split() is copied from glibs g_key_file_parse_value_as_string()
and adjusted.
(cherry picked from commit 3bcc5e4bd0)
Extend nm_match_spec_*() to support an "except:" prefix to negate
the result of a match. "except:" only works when followed by
an exact match type, for example "except:interface-name:vboxnet0",
but not "except:vboxnet0".
A matching "except:" spec always wins, regardless of other positive
matchings.
(cherry picked from commit 5c2e1afd1b)
This includes several changes how to match device specs:
- matching the interface name is no longer case-insenstive as
interface names themselves are case-sensitive.
- Now we skip patterns that start with "mac:" or "s390-subchannels:"
for comparing interface names. Previously a spec "mac:1" would have
matched an interface named "mac:1", now it doesn't.
To match such an interface, you would have to specify
"interface-name:mac:1".
- previously, a pattern "a" would have matched an interface
named "interface-name:a", now it doesn't. Since valid interface
name (in the kernel) can be at most 15 characters long, this is
however no problem.
- if the spec has the prefix "interface-name:", we support
simple globbing using GPatternSpec. Globbing without exact
spec type will still not match "vboxnet*" -- with the exception
of "*".
You can disable globbing by putting an '=' immediately
after the ':'.
(a) "interface-name:em1" | matches "em1"
(b) "interface-name:em*" | matches "em", "em1", "em2", etc.
(c) "interface-name:em\*" | matches "em\", "em\1", etc.
(d) "interface-name:=em*" | matches "em*"
(e) "em*" | matches "em*"
(cherry picked from commit 2b518538be)
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)
