valgrind complains (rightly):
==7702== 15 bytes in 2 blocks are definitely lost in loss record 411 of 6,278
==7702== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7702== by 0x8151E6E: g_malloc (gmem.c:104)
==7702== by 0x816972E: g_strdup (gstrfuncs.c:364)
==7702== by 0x1D6671: nm_properties_changed_signal_add_property (nm-properties-changed-signal.c:235)
==7702== by 0x1AF2D5: nm_dbus_manager_register_exported_type (nm-dbus-manager.c:867)
==7702== by 0x7EE0D3D: g_type_class_ref (gtype.c:2220)
==7702== by 0x7EC9A78: g_object_new_valist (gobject.c:1928)
==7702== by 0x7EC9C10: g_object_new (gobject.c:1559)
==7702== by 0x14A5FC: new_link (nm-device-bridge.c:482)
==7702== by 0x1CF8FD: platform_link_cb (nm-manager.c:2154)
==7702== by 0x988FD8B: ffi_call_unix64 (unix64.S:76)
==7702== by 0x988F6BB: ffi_call (ffi64.c:522)
(cherry picked from commit 8396c58167)
During queued_ip_config_change(), we eventually call update_ip_config()
and ip4_config_merge_and_apply(). These functions read the IP configuration
from platform and setup the private ip4_config instance.
Trigger this initialization after constructing the device to setup
the IP configuration.
Before, for unmanaged devices we would not call ip4_config_merge_and_apply()
until the first platform change event.
Note that in the worst case we do some unnecessary work due to this,
because queued_ip_config_change() must already be robust to be called
at any time.
(cherry picked from commit ddac52a61e)
Since 0c136c1e2, we also track the default route for devices
without active-connection (unmanaged). They must not be returned
as best_config() or as best_device(), because the caller don't
expect unmanaged devices here.
This also gets closer to the original behavior of get_best_device()
before merging default-route-manager in d4417e3460
where we also would ignore devices depending on the state.
This fixes an assertion when having an interface unmanaged
and activating it externally:
#0 0x00007ffff6806187 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#1 0x00007ffff6807dea in __GI_abort () at abort.c:89
#2 0x00007ffff6c0aec5 in g_assertion_message (domain=domain@entry=0x5332d5 "NetworkManager", file=file@entry=0x539460 "nm-default-route-manager.c", line=line@entry=1056, func=func@entry=0x539920 <__FUNCTION__.28934> "_ipx_get_best_config", message=message@entry=0x8c9cb0 "assertion failed: (req)") at gtestutils.c:2356
#3 0x00007ffff6c0af5a in g_assertion_message_expr (domain=domain@entry=0x5332d5 "NetworkManager", file=file@entry=0x539460 "nm-default-route-manager.c", line=line@entry=1056, func=func@entry=0x539920 <__FUNCTION__.28934> "_ipx_get_best_config", expr=expr@entry=0x53132f "req") at gtestutils.c:2371
#4 0x000000000049a196 in _ipx_get_best_config (self=<optimized out>, ignore_never_default=ignore_never_default@entry=1, out_ip_iface=out_ip_iface@entry=0x7fffffffd310, out_ac=out_ac@entry=0x0, out_device=0x0, out_vpn=0x7fffffffd318, vtable=0x7a0a00 <vtable_ip4>, vtable=0x7a0a00 <vtable_ip4>) at nm-default-route-manager.c:1056
#5 0x000000000049a3f6 in nm_default_route_manager_ip4_get_best_config (self=<optimized out>, ignore_never_default=ignore_never_default@entry=1, out_ip_iface=out_ip_iface@entry=0x7fffffffd310, out_ac=out_ac@entry=0x0, out_device=out_device@entry=0x0, out_vpn=out_vpn@entry=0x7fffffffd318) at nm-default-route-manager.c:1079
#6 0x00000000004b7518 in update_ip4_dns (self=0x7ecac0 [NMPolicy], out_vpn=0x7fffffffd318, out_device=0x0, out_ac=0x0, out_ip_iface=0x7fffffffd310, ignore_never_default=1) at nm-policy.c:390
#7 0x00000000004b7518 in update_ip4_dns (dns_mgr=0x8623a0 [NMDnsManager], policy=0x7ecac0 [NMPolicy]) at nm-policy.c:406
#8 0x00000000004b99d5 in device_ip4_config_changed (device=0x8844b0 [NMDeviceEthernet], new_config=0x908aa0 [NMIP4Config], old_config=0x908aa0 [NMIP4Config], user_data=0x7ecac0) at nm-policy.c:1260
#9 0x000000368f405d60 in ffi_call_unix64 () at /lib64/libffi.so.6
#10 0x000000368f4057d1 in ffi_call () at /lib64/libffi.so.6
#11 0x00007ffff6ee5b8c in g_cclosure_marshal_generic_va (closure=0x886a40, return_value=0x0, instance=0x8844b0, args_list=<optimized out>, marshal_data=0x0, n_params=2, param_types=0x87d3a0) at gclosure.c:1541
#12 0x00007ffff6ee5144 in _g_closure_invoke_va (closure=closure@entry=0x886a40, return_value=return_value@entry=0x0, instance=instance@entry=0x8844b0, args=args@entry=0x7fffffffd810, n_params=<optimized out>, param_types=0x87d3a0) at gclosure.c:831
#13 0x00007ffff6eff900 in g_signal_emit_valist (instance=0x8844b0, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffd810) at gsignal.c:3201
#14 0x00007ffff6f0014f in g_signal_emit (instance=instance@entry=0x8844b0, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3348
#15 0x000000000044a1f4 in nm_device_set_ip4_config (self=self@entry=0x8844b0 [NMDeviceEthernet], new_config=new_config@entry=0x9089a0 [NMIP4Config], default_route_metric=default_route_metric@entry=100, commit=commit@entry=0, reason=reason@entry=0x0) at devices/nm-device.c:5866
#16 0x000000000044a5af in ip4_config_merge_and_apply (self=self@entry=0x8844b0 [NMDeviceEthernet], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0) at devices/nm-device.c:3037
#17 0x000000000044b4fd in update_ip_config (self=self@entry=0x8844b0 [NMDeviceEthernet], initial=initial@entry=0) at devices/nm-device.c:6617
#18 0x000000000044bc39 in queued_ip_config_change (user_data=<optimized out>) at devices/nm-device.c:6688
#19 0x00007ffff6be4e1b in g_main_context_dispatch (context=0x7ba3a0) at gmain.c:3122
#20 0x00007ffff6be4e1b in g_main_context_dispatch (context=context@entry=0x7ba3a0) at gmain.c:3737
#21 0x00007ffff6be51b0 in g_main_context_iterate (context=0x7ba3a0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808
#22 0x00007ffff6be54d2 in g_main_loop_run (loop=0x7ba460) at gmain.c:4002
#23 0x000000000043291d in main (argc=1, argv=0x7fffffffdef8) at main.c:442
Fixes: da708059da
(cherry picked from commit aadef137b4)
Since 03a5a85d, NMDeviceTeam was trying to use priv->teamd_pid to
decide whether a teamd_dbus_vanished() call indicated "teamd hasn't
been started yet" or "teamd was previously started and has now
exited". But this resulted in a race condition, where at startup, a
device could call g_dbus_watch_name(), then launch teamd (causing
teamd_pid to get set), and then have gdbus report that teamd hasn't
been started yet before the newly-launched teamd managed to grab the
bus name. Since teamd_pid would already be set when
teamd_dbus_vanished() was called, it would decide that this meant
"teamd was previously started and has now exited", so it would call
teamd_cleanup(), killing the just-started teamd process.
Fix this by having teamd_dbus_vanished() check priv->tdc instead,
which doesn't get set until after the first teamd_dbus_appeared()
call.
(cherry picked from commit f0e74622cc)
We forgot to include the BRIDGE, so that bridge
devices got a default priority (route-metric) of 950
Add it between VLAN and MODEM type.
Also return a different metric for UNKNOWN
device types, but these priorities are not
actually expected.
(cherry picked from commit 8dce71be74)
Testing WWAN connections through a Nokia Series 40 phone, addresses of family
AF_PHONET end up triggering an assert() in object_has_ifindex(), just because
object_type_from_nl_object() only handles AF_INET and AF_INET6 address.
In order to avoid this kind of problems, we'll try to make sure that the object
caches kept by NM only store known object types.
(fixup by dcbw to use cached passed to cache_remove_unknown())
https://bugzilla.gnome.org/show_bug.cgi?id=742928
Connect: ppp0 <--> /dev/ttyACM0
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 5 / phase 'establish'
NetworkManager[27434]: <info> (ppp0): new Generic device (driver: 'unknown' ifindex: 12)
NetworkManager[27434]: <info> (ppp0): exported as /org/freedesktop/NetworkManager/Devices/4
[Thread 0x7ffff1ecf700 (LWP 27439) exited]
NetworkManager[27434]: <info> (ttyACM0): device state change: ip-config -> deactivating (reason 'user-requested') [70 110 39]
Terminating on signal 15
nm-pppd-plugin-Message: nm-ppp-plugin: (nm_phasechange): status 10 / phase 'terminate'
**
NetworkManager:ERROR:platform/nm-linux-platform.c:1534:object_has_ifindex: code should not be reached
Program received signal SIGABRT, Aborted.
0x00007ffff4692a97 in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff4692a97 in raise () from /usr/lib/libc.so.6
#1 0x00007ffff4693e6a in abort () from /usr/lib/libc.so.6
#2 0x00007ffff4c8d7f5 in g_assertion_message () from /usr/lib/libglib-2.0.so.0
#3 0x00007ffff4c8d88a in g_assertion_message_expr () from /usr/lib/libglib-2.0.so.0
#4 0x0000000000472b91 in object_has_ifindex (object=0x8a8320, ifindex=12) at platform/nm-linux-platform.c:1534
#5 0x0000000000472bec in check_cache_items (platform=0x7fe8a0, cache=0x7fda30, ifindex=12) at platform/nm-linux-platform.c:1549
#6 0x0000000000472de3 in announce_object (platform=0x7fe8a0, object=0x8a8c30, change_type=NM_PLATFORM_SIGNAL_REMOVED, reason=NM_PLATFORM_REASON_EXTERNAL) at platform/nm-linux-platform.c:1617
#7 0x0000000000473dd2 in event_notification (msg=0x8a7970, user_data=0x7fe8a0) at platform/nm-linux-platform.c:1992
#8 0x00007ffff5ee14de in nl_recvmsgs_report () from /usr/lib/libnl-3.so.200
#9 0x00007ffff5ee1849 in nl_recvmsgs () from /usr/lib/libnl-3.so.200
#10 0x00000000004794df in event_handler (channel=0x7fc930, io_condition=G_IO_IN, user_data=0x7fe8a0) at platform/nm-linux-platform.c:4152
#11 0x00007ffff4c6791d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#12 0x00007ffff4c67cf8 in ?? () from /usr/lib/libglib-2.0.so.0
#13 0x00007ffff4c68022 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#14 0x00000000004477ee in main (argc=1, argv=0x7fffffffeaa8) at main.c:447
(gdb) fr 4
#4 0x0000000000472b91 in object_has_ifindex (object=0x8a8320, ifindex=12) at platform/nm-linux-platform.c:1534
1534 g_assert_not_reached ();
(cherry picked from commit bf7865e859)
The address might be zero-size, and therefore nl_addr_get_binary_addr()
returns a pointer to a zero-size array. We don't want to read past the
end of that array. Since zero-size addresses really mean an address
of all zeros, just make that happen.
As an additional optimization, if the prefix length is zero, the whole
address is host bits and should be cleared.
==30286== Invalid read of size 4
==30286== at 0x478090: clear_host_address (nm-linux-platform.c:3786)
==30286== by 0x4784D4: route_search_cache (nm-linux-platform.c:3883)
==30286== by 0x4785A1: refresh_route (nm-linux-platform.c:3901)
==30286== by 0x4787B6: ip4_route_delete (nm-linux-platform.c:3978)
==30286== by 0x47F674: nm_platform_ip4_route_delete (nm-platform.c:1980)
==30286== by 0x4B279D: _v4_platform_route_delete_default (nm-default-route-manager.c:1122)
==30286== by 0x4AEF03: _platform_route_sync_flush (nm-default-route-manager.c:320)
==30286== by 0x4B043E: _resync_all (nm-default-route-manager.c:574)
==30286== by 0x4B0CA7: _entry_at_idx_remove (nm-default-route-manager.c:631)
==30286== by 0x4B1A66: _ipx_update_default_route (nm-default-route-manager.c:806)
==30286== by 0x4B1A9C: nm_default_route_manager_ip4_update_default_route (nm-default-route-manager.c:813)
==30286== by 0x45C3BC: _cleanup_generic_post (nm-device.c:7143)
==30286== Address 0xee33514 is 0 bytes after a block of size 20 alloc'd
==30286== at 0x4C2C080: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30286== by 0x6B2B0B1: nl_addr_alloc (in /usr/lib/libnl-3.so.200.20.0)
==30286== by 0x6B2B0E3: nl_addr_build (in /usr/lib/libnl-3.so.200.20.0)
==30286== by 0x6B2B181: nl_addr_clone (in /usr/lib/libnl-3.so.200.20.0)
==30286== by 0x66DB0D7: ??? (in /usr/lib/libnl-route-3.so.200.20.0)
==30286== by 0x6B33CE6: nl_object_clone (in /usr/lib/libnl-3.so.200.20.0)
==30286== by 0x6B2D303: nl_cache_add (in /usr/lib/libnl-3.so.200.20.0)
==30286== by 0x472E55: refresh_object (nm-linux-platform.c:1735)
==30286== by 0x473137: add_object (nm-linux-platform.c:1795)
==30286== by 0x478373: ip4_route_add (nm-linux-platform.c:3846)
==30286== by 0x47F375: nm_platform_ip4_route_add (nm-platform.c:1939)
==30286== by 0x4AEC06: _platform_route_sync_add (nm-default-route-manager.c:254)
https://bugzilla.gnome.org/show_bug.cgi?id=742937
(cherry picked from commit d2871089a8)
Don't start an automatic connectivity check right when NMManager tells
us we're online; only do it if the manager doesn't request an explicit
connectivity check immediately afterward.
(cherry picked from commit 66b8f2b7a0)
Merge the two nm_connectivity_set_online() calls into one, after
tweaking NMConnectivity to always update its internal state before
alerting callers to the new state.
(cherry picked from commit 0997c4b245)
When a connection has finished activating, but we don't know yet that
we have full connectivity, then find_best_device_state() should return
CONNECTED_SITE, not CONNECTING. Fixes a bug where the manager state
would repeatedly switch between those two states.
(cherry picked from commit 5e182d5577)
nm-connectivity was logging both "started" and "finished" for periodic
connectivity checks, but was only logging "finished" for manual ones,
which made the logs look weird. Fix it to log both periodic and manual
starts, and differentiate them.
Also add some additional logging to indicate when set_online() is
called, and when :state changes.
(cherry picked from commit 53f2642c73)
Custom IP ranges for shared connection were implemeted in bgo #6759732
(commit 32a001f526). The first IP address
is used and a range is calculated.
However, the commit missed to update ifcfg-rh plugin to read the address.
Test case:
* use ifcfg-rh plugin for NetworkManager
$ nmcli con add type eth con-name shared-ip ifname eth0
$ nmcli con mod shared-ip ipv4.addresses 9.8.7.6/24 ipv4.method shared
$ nmcli con show shared-ip
$ nmcli con show shared-ip <--- ip address 9.8.7.6 was missing
https://bugzilla.redhat.com/show_bug.cgi?id=1174632
(cherry picked from commit c8fe3bbabc)
If a connection has an associated "rule-NAME" or "rule6-NAME" file,
don't try to read in the routes, since NetworkManager won't be able to
parse them correctly. Instead, log a warning that they will need to be
applied via a dispatcher script, and provide a script that would do
that in examples/dispatcher/.
(cherry picked from commit f79d62692e)
Add a "filename" property to NMSettingsConnection, and set it from
keyfile and ifcfg-rh (replacing the existing priv->path variables in
those connection types). (The other plugins either don't use files, or
don't use per-connection files.)
(cherry picked from commits 24a464a7da
and c9002c041d)
If an ifcfg file has a DEVTIMEOUT property (and a DEVICE, and is
ONBOOT=yes), and the device is not present at startup, then wait up to
DEVTIMEOUT seconds for it to appear before declaring the connection
ready.
This allows for a hacky workaround to devices that take a bizarrely
long time to be probed.
(cherry picked from commit 62d870e1a6)
Add an NMSettingsConnection:ready property, which indicates if the
connection is ready to use. Add NMSettings:startup-complete, which is
TRUE when all connections are ready. Make NMManager:startup-complete
take NMSettings:startup-complete into account.
(cherry picked from commit b067ca7034)
wireless_connection_from_ifcfg() did not support being called without
error argument.
#0 0x00007fe4fa2204e9 in g_logv (log_domain=0x7fe4f0597060 "NetworkManager-ifcfg-rh", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fff1c7aaf00) at gmessages.c:989
#1 0x00007fe4fa22063f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1025
#2 0x00007fe4f057eec3 in wireless_connection_from_ifcfg (file=0x7fe4fec7c800 "/etc/sysconfig/network-scripts/ifcfg-Wi-Fi-1", ifcfg=0x7fe4fec6f730, error=0x0) at reader.c:3431
#3 0x00007fe4f057e2b6 in connection_from_file_full (filename=0x7fe4fec7c800 "/etc/sysconfig/network-scripts/ifcfg-Wi-Fi-1", network_file=0x7fe4f05976aa "/etc/sysconfig/network", test_type=0x0, out_unhandled=0x7fff1c7ab1f8,
error=0x0, out_ignore_error=0x7fff1c7ab174) at reader.c:4750
#4 0x00007fe4f057db80 in connection_from_file (filename=0x7fe4fec7c800 "/etc/sysconfig/network-scripts/ifcfg-Wi-Fi-1", out_unhandled=0x7fff1c7ab1f8, error=0x0) at reader.c:4834
#5 0x00007fe4f057b4a6 in nm_ifcfg_connection_new (source=0x0, full_path=0x7fe4fec7c800 "/etc/sysconfig/network-scripts/ifcfg-Wi-Fi-1", error=0x0) at nm-ifcfg-connection.c:119
#6 0x00007fe4f0579c1d in _internal_new_connection (self=0x7fe4fec6cd00, path=0x7fe4fec7c800 "/etc/sysconfig/network-scripts/ifcfg-Wi-Fi-1", source=0x0, error=0x0) at plugin.c:136
#7 0x00007fe4f0579256 in connection_new_or_changed (self=0x7fe4fec6cd00, path=0x7fe4fec7c800 "/etc/sysconfig/network-scripts/ifcfg-Wi-Fi-1", existing=0x0, out_old_path=0x7fff1c7ab458) at plugin.c:265
#8 0x00007fe4f0578f61 in read_connections (plugin=0x7fe4fec6cd00) at plugin.c:462
#9 0x00007fe4f0578839 in get_connections (config=0x7fe4fec6cd00) at plugin.c:497
#10 0x00007fe4fdc9affb in nm_system_config_interface_get_connections (config=0x7fe4fec6cd00) at settings/nm-system-config-interface.c:143
#11 0x00007fe4fdc9764f in load_connections (self=0x7fe4fec6ca40) at settings/nm-settings.c:201
#12 0x00007fe4fdc96d74 in nm_settings_new (error=0x7fff1c7abb18) at settings/nm-settings.c:1802
#13 0x00007fe4fdc37146 in main (argc=1, argv=0x7fff1c7abcd8) at main.c:415
Fixes: 356849f70c
Fixes: 12bfaf5a8d
(cherry picked from commit ffe0fde235)
The out_keyfile, out_routefile, and out_route6file args were just
based on trivial calls to utils.h functions, and could just as easily
be done by the caller directly. So do that.
(cherry picked from commit 335dbda16b)
Don't pass &keyfile, &routefile, and &route6file if we aren't going to
use the return value.
Don't pass &unmanaged if we aren't going to check it. (And when we do
check it, don't g_free() it if we've asserted that it's NULL.)
(cherry picked from commit a564dafc35)
A bunch of tests appear to have copy-and-pasted the same unnecessary
check for route6file having been created. Remove them.
(cherry picked from commit 1600ed9c68)
Instead of having connection_from_file() return a flag telling its
caller whether to log a warning or not, just have it log the warning
(or not) itself.
(cherry picked from commit 12bfaf5a8d)
Rather than having the "real" users of connection_from_file() have to
pass a dozen NULL arguments, add a separate
connection_from_file_test() for use by test-ifcfg-rh. (Likewise, since
no test cases care about ignore_error, remove that argument from
connection_from_file_test().)
(cherry picked from commit 356849f70c)
conn_name can be NULL now as the connections are tracked by UUID
(see commit 689dadaffb)
Sep 29 21:20:34 Jdeapad NetworkManager[1339]: <info> getting unmanaged specs...
Sep 29 21:20:34 Jdeapad NetworkManager[1339]: <info> Checking unmanaged: (null)
Sep 29 21:20:38 Jdeapad kernel: NetworkManager[1339]: segfault at 0 ip
00007f1bfffbedd0 sp 00007fff98daa628 error 4 in
libglib-2.0.so.0.4002.0[7f1bfff86000+130000]
https://bugzilla.gnome.org/show_bug.cgi?id=737645
(cherry picked from commit 91fd36e166)
refresh_object() raised a spurious change event for the route we
are about to delete. Suppress that by adding an internal reason flag.
Fixes: 41e6c4fac1
(cherry picked from commit 96c099de09)
Deleting routes with metric 0 might end up deleting other
routes with a different metric.
Workaround this in platform to only delete a route with
metric 0 if such a route can be found prior to deletion.
Don't only look into the cache (which might be out of date).
Instead refetch the route we are about to delete to be sure.
There is still a race that we might end up deleting the wrong
route.
https://bugzilla.gnome.org/show_bug.cgi?id=741871https://bugzilla.redhat.com/show_bug.cgi?id=1172780
(cherry picked from commit 41e6c4fac1)
This match-any behavior ignoring metric is nowhere used. And even if we
would need such a behavior, using 0 is wrong because IPv4 routes can
have a metric of zero.
(cherry picked from commit 2cb3c7e8a0)
Handling a route with metric 0 effectively means
a metric of 1024 (user default). Adjust the add(),
delete() and exist() functions to consider routes
with metric 0 as 1024.
(cherry picked from commit 06e4eee0ce)
Write ipv4.route-metric and ipv6.route-metric property of
NMSettingConnection as IPV4_ROUTE_METRIC and IPV6_ROUTE_METRIC,
respectively.
(cherry picked from commit 3e33a5a6c5)
Conflicts:
src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh.c
On resume configured interfaces are unmanaged to clear their pre-resume
state and then re-managed. Eventually the interface should end up moving
to the DISCONNECTED state, which should trigger an auto-activate check in
the Policy. If connectivity checking was enabled, that auto-activate check
would fail because the Manager's state was still NM_STATE_ASLEEP.
This caused bridge slaves not to auto-activate on resume, which left bridges
without connectivity.
The manager never left NM_STATE_ASLEEP when connectivity checking was
enabled due to nm_manager_update_state() returning early when kicking
off a connectivity check. Instead, the manager's state should always
be updated to accurately reflect the current state.
https://bugzilla.redhat.com/show_bug.cgi?id=1162636https://bugzilla.gnome.org/show_bug.cgi?id=742675
(cherry picked from commit a687d1f9e0)
If a device assumes a connection without activating a user-requested or
NM-requested connection, then disable_ipv6 is not touched. When the device
is deactivated, it still isn't touched even though userspace IPv6LL
is enabled. This could lead to an user-requested activation with
IPv6 configuration, but disable_ipv6=1.
Whenever userspace IPv6LL is turned on, we should also set disable_ipv6=0
to ensure IPv6 can function. Userspace IPv6LL will ensure that the
interface does not have an address until the user/connection requests
it, which was the only reason that NM touched disable_ipv6 anyway.
fixes:NetworkManager_Test203_testcase_286589
fixes:NetworkManager_Test204_testcase_286590
https://bugzilla.gnome.org/show_bug.cgi?id=741773
(cherry picked from commit 984b0763d9)
