Description of problem: Network Manager crashed hard when IPv6 is disabled. This happened when adding "ipv6.disable=1" to the bootparams line. The relevant error in the journal is: sep 25 07:48:54 localhost.localdomain NetworkManager[443]: <info> (wlp12s0): device state change: config -> ip-config (reason 'none') [50 70 sep 25 07:48:54 localhost.localdomain NetworkManager[443]: <info> Activation (wlp12s0) Beginning DHCPv4 transaction (timeout in 45 seconds) sep 25 07:48:54 localhost.localdomain NetworkManager[443]: <info> dhclient started with pid 749 sep 25 07:48:54 localhost.localdomain NetworkManager[443]: libndp: ndp_sock_open: Failed to create ICMP6 socket. sep 25 07:48:54 localhost.localdomain NetworkManager[443]: ** sep 25 07:48:54 localhost.localdomain NetworkManager[443]: ERROR:rdisc/nm-lndp-rdisc.c:601:nm_lndp_rdisc_init: assertion failed: (!error) ) This suggests the bug is in libndp which is at version 1.0-2.fc20 in this system. Version-Release number of selected component: NetworkManager-0.9.9.0-12.git20130913.fc20 Additional info: reporter: libreport-2.1.7 backtrace_rating: 4 cmdline: /usr/sbin/NetworkManager --no-daemon crash_function: _g_log_abort executable: /usr/sbin/NetworkManager kernel: 3.11.1-300.fc20.x86_64 runlevel: N 5 type: CCpp uid: 0 Truncated backtrace: Thread no. 1 (9 frames) #2 _g_log_abort at gmessages.c:255 #5 nm_lndp_rdisc_init at rdisc/nm-lndp-rdisc.c:601 #6 g_type_create_instance at gtype.c:1868 #7 g_object_new_internal at gobject.c:1746 #10 nm_lndp_rdisc_new at rdisc/nm-lndp-rdisc.c:53 #11 addrconf6_start at devices/nm-device.c:3169 #12 act_stage3_ip6_config_start at devices/nm-device.c:3331 #13 nm_device_activate_stage3_ip6_start at devices/nm-device.c:3449 #14 nm_device_activate_stage3_ip_config_start at devices/nm-device.c:3526
Created attachment 803078 [details] File: backtrace
Created attachment 803079 [details] File: cgroup
Created attachment 803080 [details] File: core_backtrace
Created attachment 803081 [details] File: dso_list
Created attachment 803082 [details] File: environ
Created attachment 803083 [details] File: limits
Created attachment 803084 [details] File: maps
Created attachment 803085 [details] File: open_fds
Created attachment 803086 [details] File: proc_pid_status
"ipv6.disable=1" kernel parameter disables whole IPv6 stack. It results in failures creating IPv6 sockets, etc. You should consider using 'ipv6.disable_ipv6=1' instead, which keeps IPv6 stack functional but will not assign IPv6 addresses to any of your network devices. https://lists.fedoraproject.org/pipermail/kernel/2013-July/004323.html https://lists.fedoraproject.org/pipermail/kernel/2013-July/004325.html On the other hand, NetworkManager should cope with the situation and should not crash. I will attach a patch to fix the problem.
Created attachment 803310 [details] [PATCH] rdisc: do not crash on NDP init failures When an ICMPv6 socket cannot be opened for NDP, do not create NMRDisc at all. Pushed also to jklimes/rh1012151-rdisc-fix for review.
The patch looks good to me
Looks good to me too.
Pushed to upstream master: 469febc0d93b423d33d4ea0f010c63c981f3dbca
NetworkManager-0.9.9.0-13.git20131001.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-13.git20131001.fc20
NetworkManager-0.9.9.0-14.git20131003.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-14.git20131003.fc20
Package NetworkManager-0.9.9.0-14.git20131003.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.9.0-14.git20131003.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-18316/NetworkManager-0.9.9.0-14.git20131003.fc20 then log in and leave karma (feedback).
I just updated my test partition and tested it. No luck. On the one hand, ipv6_disable doesn't cause NetworkManager to crash anymore but on the other, while it starts up it doesn't do anything at all. ipv6.disable_ipv6=1 does work, however.
What do you mean with "doesn't do anything at all"? Can you please elaborate on what you are doing, what is happening as a result and what you would expect to happen instead? Thank you.
T. Haller, exactly what it means. In German, the expression is "Um überhaupt nichts zu tun". After the patch, Network Manager starts instead of crashing and dumping core, but is simply a useless binary blob sitting in RAM if I use "ipv6.disable=1". If I use "ipv6.disable_ipv6=1", Network Manager works. Therefore, the patch is half-way there: it fixes the crash but it doesn't restore lost functionality.
Hi, after testing (done by jklimes), the observed problem might be the following: When running with "ipv6.disable=1", you can not connect to a connection that has an IPv6 setting with method=auto and may_fail=true. The workaround to this problem is to set the method to "ignore". Could you please verify, that this is the problem you are seeing? And can you connect with IPv6 method=ignore? Thank you.
Testing this out, it appears that the previous patch is inadequate if the configured connection defaults to "automatic" for the IPv6 method. addrconf6_start() receives the error from libndp that it could not open an IPv6 socket, and then fails device activation. Instead of a hard failure, only IPv6 should fail and allow IPv4 to proceed, if configured. Proposed patch: diff --git a/src/devices/nm-device.c b/src/devices/nm-device.c index d99b3d7..6810afc 100644 --- a/src/devices/nm-device.c +++ b/src/devices/nm-device.c @@ -3325,16 +3325,16 @@ act_stage3_ip6_config_start (NMDevice *self, update_ip6_privacy_save (self); priv->dhcp6_mode = NM_RDISC_DHCP_LEVEL_NONE; if ( strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_AUTO) == 0 || strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_LINK_LOCAL) == 0) { if (!addrconf6_start (self)) { - *reason = NM_DEVICE_STATE_REASON_IP_CONFIG_UNAVAILABLE; - ret = NM_ACT_STAGE_RETURN_FAILURE; + /* IPv6 might be disabled; allow IPv4 to proceed */ + ret = NM_ACT_STAGE_RETURN_STOP; } else ret = NM_ACT_STAGE_RETURN_POSTPONE; } else if (strcmp (method, NM_SETTING_IP6_CONFIG_METHOD_DHCP) == 0) { /* Router advertisements shouldn't be used in pure DHCP mode */ if (priv->ip6_accept_ra_path) nm_utils_do_sysctl (priv->ip6_accept_ra_path, "0");
Patch acked by jklimes and pushed to master.
NetworkManager-0.9.9.0-14.git20131003.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Very close but no cigar. NetworkManager starts OK, GNOME's NetworkManager applet does too and then NM attempts to find a rs router in the network: NetworkManager[446]: <error> [1381348948.963407] [rdisc/nm-lndp-rdisc.c:194] send_rs(): (wlp12s0): cannot s end router solicitation: -101. Please note that I have been using NetworkManager with the default configuration. The only data I have fed it are the SSID and the shared key to my access point plus disabling the ipv6 stack because I don't have ipv6 capable networking hardware nor does my ISP, yet. This works with Arch Linux with vanilla NM 0.9.8.6. I guess NM should disable its IPv6 functionality if there is no stack to talk to? Having to turn it off by hand in the NM applet is not obvious.
(In reply to P. A. López-Valencia from comment #25) Which version of NetworkManager did you test? Did you apply the patch from comment #22 (or did you use the current master branch that includes the commit 9543e45afe0746ac1c9c10e4f78f43264fd288b4)? Also, when you see the issue, did you boot the kernel with "ipv6.disable=1"? And then the "only" issue left is the error message in the logfile? Thank you.
I used NetworkManager-0.9.9.0-14.git20131003.fc20 (reported as closing the bug in comment 24, I guess it includes the patch in comment 22) and booted the kernel with ipv6.disable=1. The error message and failed connection happens when I don't disable IPv6 in GNOME's NM applet, hence my comment about ipv6 stack detection.
(In reply to P. A. López-Valencia from comment #27) > I used NetworkManager-0.9.9.0-14.git20131003.fc20 (reported as closing the > bug in comment 24, I guess it includes the patch in comment 22) and booted > the kernel with ipv6.disable=1. > Unfortunately NetworkManager-0.9.9.0-14.git20131003.fc20 doesn't include the patch from comment #22 yet (note the dates: rpm: Oct 3, patch: Oct 7) It only contains the crash fix.
*** Bug 999176 has been marked as a duplicate of this bug. ***
Any ETA on a new snapshot build to actually get this working? Thanks.
Still applies - and I've spend quite a while to figure out this reason after my todays rawhide upgrade and I'd to remove my ipv6 disable options to get it usable again on wireless. Logging from NetworkManager is quite useless and error messages from wifi are misleading.... NetworkManager-0.9.9.0-14.git20131003.fc21.x86_64
NetworkManager-0.9.9.0-15.git20131003.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/NetworkManager-0.9.9.0-15.git20131003.fc20
Package NetworkManager-0.9.9.0-15.git20131003.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing NetworkManager-0.9.9.0-15.git20131003.fc20' as soon as you are able to, then reboot. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-20932/NetworkManager-0.9.9.0-15.git20131003.fc20 then log in and leave karma (feedback).
All seems to work as expected. I have ipv6.disabled=1 in bootparams and I have as well enabled IPv6 in the NetworkManager configuration options for my network interface; finally I get a stable connection instead of an endless loop of failed connection attempts. I'd venture to say this bug is fixed but let's wait for others to confirm it so.
NetworkManager-0.9.9.0-15.git20131003.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.