udev doesn't know about the device yet when NM creates it internally.
NetworkManager[9275]: <info> (team0): carrier is OFF
NetworkManager[9275]: <info> (team0): new Team device (driver: 'team' ifindex: 16)
(NetworkManager:9275): GUdev-CRITICAL **: g_udev_device_get_property: assertion 'G_UDEV_IS_DEVICE (device)' failed
NetworkManager[9275]: <info> (team0): exported as /org/freedesktop/NetworkManager/Devices/5
(cherry picked from commit 8173f0f9e8)
This reverts commit ebeaeaed4d.
No need to hardwire these as unmanaged anymore, an udev rule will take care of
it.
(cherry picked from commit 498d45e85f)
Some out of tree drivers add Ethernet devices that are supposed to be managed
by other their tooling, e.g. VirtualBox or VMWare.
Rather than hardcoding their drivers (at least VirtualBox doesn't even set a
"driver" property in sysfs) or hardcoding a logic that identifies such devices
let's just add a possibility to blacklist them in udev. This makes it possible
for whoever who ships such a driver to ship rules that prevent NetworkManager
from managing the device itself.
Furthermore it makes it possible for the user with special needs leverage the
flexibility of udev rules to override the defaults. In the end the user can
decide to let NetworkManager manage default-unmanaged interfaces such as VEth
or turn on default-unmanaged for devices on a particular bus.
An udev rule for VirtualBox would look like this:
SUBSYSTEM=="net", ENV{INTERFACE}=="vboxnet[0-9]*", ENV{NM_UNMANAGED}="1"
(cherry picked from commit 85ee1f4a9c)
There's no udev running in containers, it only starts if /sys is writable. If a
hardware device is added to the container's namespace NM would not announce it.
This also removes the software link special case -- the software links will now
wait for udev initialization (in case udev is there) as well. There's no reason
to treat them differently anymore. This makes it possible to use udev properties
of the software links.
https://bugzilla.gnome.org/show_bug.cgi?id=740526
(cherry picked from commit 4a05869557)
We trigger a new solicitation upon seeing the new token. Kernel triggers one
too, but that one is of no use to us, since the advertisement might arrive sooner
than we learn about the token change.
(cherry picked from commit 24e7ea7860)
nm_utils_get_shared_wifi_permission() that is called for each AddAndActivate
uses this and triggers an assertion failure for InifnibandConnections which
don't have IPv4 configuration:
NetworkManager[54006]: nm_utils_get_ip_config_method: assertion 's_ip4 != NULL' failed
#2 0x000055555562b833 in nm_utils_get_ip_config_method (connection=connection@entry=0x5555559c3b60, ip_setting_type=93824996202304) at NetworkManagerUtils.c:1329
#3 0x000055555562b914 in nm_utils_get_shared_wifi_permission (connection=0x5555559c3b60) at NetworkManagerUtils.c:1105
#4 0x00005555555fc012 in nm_active_connection_authorize (self=0x5555559b30a0, result_func=0x55555561b980 <_add_and_activate_auth_done>, user_data1=0x555555957210, user_data2=0x555555a055f0)
at nm-active-connection.c:683
#5 0x0000555555621b21 in impl_manager_add_and_activate_connection (self=0x555555957210, settings=<optimized out>, device_path=<optimized out>, specific_object_path=0x0, context=0x555555a055f0)
at nm-manager.c:3495
(cherry picked from commit 5e8182279a)
Fixes build with Ubuntu 12.04.
In file included from ppp-manager/nm-ppp-manager.c:42:0:
/usr/include/linux/if_ppp.h:103:16: error: field 'b' has incomplete type
/usr/include/linux/if_ppp.h:108:21: error: field 'b' has incomplete type
(cherry picked from commit 22b99e3bbb)
Note also the comment "Just make sure we don't expect specific data being
in the connection till then (especially in validate_activation_request())."
in impl_manager_add_and_activate_connection().
Creating a connection caused a failed assertion:
#0 0x00007ff8da3aa4e9 in g_logv (log_domain=0x7ff8ddf41036 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ffff5a0a090) at gmessages.c:989
#1 0x00007ff8da3aa63f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1025
#2 0x00007ff8dde8c47a in nm_utils_get_ip_config_method (connection=0x7ff8def21d20, ip_setting_type=140706868598912) at NetworkManagerUtils.c:1252
#3 0x00007ff8dde7d654 in validate_activation_request (self=0x7ff8def62150, context=0x7ff8deff5a00, connection=0x7ff8def21d20, device_path=0x7ff8def3f770 "/org/freedesktop/NetworkManager/Devices/2", out_device=0x7ffff5a0a370,
out_vpn=0x7ffff5a0a36c, error=0x7ffff5a0a378) at nm-manager.c:3061
#4 0x00007ff8dde7b7a2 in impl_manager_add_and_activate_connection (self=0x7ff8def62150, settings=0x7ff8def95460, device_path=0x7ff8def3f770 "/org/freedesktop/NetworkManager/Devices/2",
specific_object_path=0x7ff8deeeced0 "/org/freedesktop/NetworkManager/AccessPoint/227", context=0x7ff8deff5a00) at nm-manager.c:3386
#5 0x00007ff8dde6bd9c in dbus_glib_marshal_nm_manager_VOID__BOXED_BOXED_BOXED_POINTER (closure=0x7ffff5a0a5f0, return_value=0x0, n_param_values=5, param_values=0x7ff8defb9d30, invocation_hint=0x0,
marshal_data=0x7ff8dde7b660 <impl_manager_add_and_activate_connection>) at ./nm-manager-glue.h:189
#6 0x00007ff8dc506885 in invoke_object_method (message=0x7ff8def99a00, connection=0x7ff8deeec940, method=0x7ff8de1a6878 <dbus_glib_nm_manager_methods+72>, object_info=0x7ff8de1a2e70 <dbus_glib_nm_manager_object_info>,
object=0x7ff8def62150) at dbus-gobject.c:1899
#7 object_registration_message (connection=0x7ff8deeec940, message=message@entry=0x7ff8def99a00, user_data=user_data@entry=0x7ff8def16da0) at dbus-gobject.c:2161
#8 0x00007ff8dc2cef86 in _dbus_object_tree_dispatch_and_unlock (tree=0x7ff8deeec5e0, message=message@entry=0x7ff8def99a00, found_object=found_object@entry=0x7ffff5a0a814) at dbus-object-tree.c:862
#9 0x00007ff8dc2c10d9 in dbus_connection_dispatch (connection=connection@entry=0x7ff8deeec940) at dbus-connection.c:4699
#10 0x00007ff8dc503d65 in message_queue_dispatch (source=source@entry=0x7ff8deeee720, callback=<optimized out>, user_data=<optimized out>) at dbus-gmain.c:90
#11 0x00007ff8da3a32a6 in g_main_dispatch (context=0x7ff8deebd320) at gmain.c:3066
#12 g_main_context_dispatch (context=context@entry=0x7ff8deebd320) at gmain.c:3642
#13 0x00007ff8da3a3628 in g_main_context_iterate (context=0x7ff8deebd320, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713
#14 0x00007ff8da3a3a3a in g_main_loop_run (loop=0x7ff8deebd3e0) at gmain.c:3907
#15 0x00007ff8dddc0979 in main (argc=1, argv=0x7ffff5a0afd8) at main.c:442
Fixes: 477033b9ef
(cherry picked from commit b3944cfc71)
With GCC 5, -Wlogical-not-parentheses is enabled by -Wall and warns
about suspicious code like:
int a;
...
if (!a > 1) { ... }
Fix the following warning:
test_all.c: In function ‘test_is_static’:
test_all.c:114:32: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
ASSERT (!is_static_ip6 ("eth0") == TRUE, "is static",
^
(cherry picked from commit fe765d30da)
Add the new configuration option 'assume-ipv6ll-only' which specifies
the devices for which NM will try to assume an existing IPv6LL-only
configuration.
The new default behavior is to ignore such configurations since IPv6LL
addresses are automatically assigned by the kernel when the device is
brought up and thus the presence of an IPv6LL address doesn't mean
that the device was configured by the administrator.
The previous behavior was to always assume IPv6LL-only configurations
but this often had the unwanted effect of preventing other on-disk
configurations to be activated. To preserve the old behavior the
option must be set to '*'.
https://bugzilla.redhat.com/show_bug.cgi?id=1138426
(cherry picked from commit 3bc097b084)
Now on SIGHUP, when reloading NetworkManager configuration, also reload
the ignore-carrier flag.
While a device is activated, the reload is ignored until the device
deactivates.
Maybe it would be simpler just not to cache ignore_carrer and let it
take effect immediately. But not caching ignore_carrer has the
additional downside that every call to is_available must check the
specs -- which in sum is potentially expensive for something that
almost never changes.
https://bugzilla.gnome.org/show_bug.cgi?id=748050
(cherry picked from commit 8ebb8d0d0f)
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)
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)
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).
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)
