After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 740096 - core: bounce disable_ipv6 when setting userspace IPv6 link-local
core: bounce disable_ipv6 when setting userspace IPv6 link-local
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: IP and DNS config
unspecified
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
Depends on:
Blocks: nm-1.0
 
 
Reported: 2014-11-14 02:22 UTC by Dan Williams
Modified: 2014-12-01 11:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
0001-core-bounce-disable_ipv6-when-setting-userspace-IPv6.patch (4.12 KB, patch)
2014-11-14 02:22 UTC, Dan Williams
reviewed Details | Review

Description Dan Williams 2014-11-14 02:22:35 UTC
Created attachment 290677 [details] [review]
0001-core-bounce-disable_ipv6-when-setting-userspace-IPv6.patch

The kernel does not terminate an ongoing IPv6LL address process when
the IPv6LL address generation mode is set to 'none' (indicating that
userspace wishes to handle IPv6LL).  This means that when the kernel
is done with DAD for that address, it announces the address, and
if the device is in the DISCONNECTED state, NetworkManager will
generate an assume an IPv6LL-only connection on the device.

Unfortunately, that behavior also happens if the following is true:

1) IPv6LL addressing takes a while (eg, dad_transmits is high or
the kernel takes a while for some reason)

2) the activated connection fails quickly (dhclient fails or some
other fatal error terminates the activation attempt)

3) the activated connection has ipv6.method=ignore

In this case, when the device is brought up and ipv6.method=ignore,
NetworkManager re-enabled kernel IPv6LL and resets the IPv6 sysctl
properties.  The kernel then generates an IPv6LL address and begins
DAD.  SELinux prevented dhclient from running, and thus the connection
quickly failed.  NM then turned off kernel IPv6LL when deactivating
the device after the activation failed, but the kernel does not
terminate the ongoing DAD.  Some time after the device entered the
DISCONNECTED state, the kernel finished DAD and announced the address,
and NetworkManager emitted the 'recheck-assume' signal.  This
generated a new IPv6LL-only connection which was then assumed.

Bouncing 'disable_ipv6' when re-enabling userspace IPv6LL during
device deactivation flushes the tentative kernel IPv6LL address,
thus preventing the address from being announced after userspace
IPv6LL is re-enabled.

Reproducer:
- ifconfig eth0 down
- prepare a DHCPv4 connection with ipv6.method=ignore
- set /proc/sys/net/ipv6/conf/all/dad_transmits to "15"
- ensure that DHCPv4 will fail (turn on SELinux + change dhclient's
   context, or replace dhclient with a script that exits after 2 seconds)
- run NetworkManager
- activate the DHCP connection and watch it immediately fail
- wait for the kernel to announce the IPv6LL address after DAD finishes
- watch NM "assume" the new IPv6LL connection
Comment 1 Thomas Haller 2014-11-14 13:29:23 UTC
LGTM
Comment 2 Dan Winship 2014-11-15 14:10:05 UTC
Comment on attachment 290677 [details] [review]
0001-core-bounce-disable_ipv6-when-setting-userspace-IPv6.patch

the code looks good, I just have comments on the commit message

>The kernel does not terminate an ongoing IPv6LL address process when
>the IPv6LL address generation mode is set to 'none'

which seems like a kernel bug, though one that we have to work around for now of course

>generate an assume an IPv6LL-only connection on the device.

          ^^and

>2) the activated connection fails quickly (dhclient fails or some
>other fatal error terminates the activation attempt)

>In this case...
>...SELinux prevented dhclient from running

weird to suddenly blame SELinux here when the example was being agnostic up until this point
Comment 3 Dan Williams 2014-11-17 16:58:40 UTC
(In reply to comment #2)
> (From update of attachment 290677 [details] [review])
> the code looks good, I just have comments on the commit message
> 
> >The kernel does not terminate an ongoing IPv6LL address process when
> >the IPv6LL address generation mode is set to 'none'
> 
> which seems like a kernel bug, though one that we have to work around for now
> of course

Yeah, and it would be worth pinging Jiri Pirko about this I suppose.

> >generate an assume an IPv6LL-only connection on the device.
> 
>           ^^and

Fixed.

> >2) the activated connection fails quickly (dhclient fails or some
> >other fatal error terminates the activation attempt)
> 
> >In this case...
> >...SELinux prevented dhclient from running
> 
> weird to suddenly blame SELinux here when the example was being agnostic up
> until this point

Removed.

Pushed to git master with the commit message fixups.