Kernel Bug: IPv6 Neighbor Discovery

[Joseph Ishac]

We have discovered what appears to be a bug with the handling of ICMP6 router solicitations on tun interfaces in the Linux kernel. In particular, if an application is not immediately bound to the tun interface, router solicitations are never sent out of the interface. This issue can be replicated easily using the attached scripts.

First, a tun interface is created with permissions for the local user, sudo is used so the script will prompt for the user password.

$ bash rftun0_create.sh
rftun0 created
16: rftun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 500
    link/none

Then the interface is configured, given an address, and brought "up" however since there is no application bound to the interface yet there is no carrier.

$ bash rftun0_up.sh
net.ipv6.conf.rftun0.forwarding = 0
net.ipv6.conf.rftun0.accept_ra = 1
net.ipv6.conf.rftun0.autoconf = 1
net.ipv6.conf.rftun0.accept_ra_rt_info_max_plen = 128
net.ipv6.conf.rftun0.accept_ra_rtr_pref = 1
net.ipv6.conf.rftun0.router_solicitation_delay = 1
net.ipv6.conf.rftun0.router_solicitation_interval = 2
net.ipv6.conf.rftun0.router_solicitations = 200
rftun0 up
16: rftun0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1400 qdisc pfifo_fast state DOWN group default qlen 500
    link/none
    inet6 fe80::600:4339:125f:760c/64 scope link
       valid_lft forever preferred_lft forever

A simple client is then run to bind to the tun interface and read the first three packets. If things are going well we should see 3 router solicitations, however we instead see no traffic.

$ python simple_tun_client.py
Timed out...
Timed out...
Timed out...

If we bring the interface down and try again with no delay between bringing the interface up and binding the application we see things work as expected.

$ bash rftun0_down.sh
rftun0 down
16: rftun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1400 qdisc pfifo_fast state DOWN group default qlen 500
    link/none

$ bash rftun0_up.sh && python simple_tun_client.py
net.ipv6.conf.rftun0.forwarding = 0
net.ipv6.conf.rftun0.accept_ra = 1
net.ipv6.conf.rftun0.autoconf = 1
net.ipv6.conf.rftun0.accept_ra_rt_info_max_plen = 128
net.ipv6.conf.rftun0.accept_ra_rtr_pref = 1
net.ipv6.conf.rftun0.router_solicitation_delay = 1
net.ipv6.conf.rftun0.router_solicitation_interval = 2
net.ipv6.conf.rftun0.router_solicitations = 200
rftun0 up
16: rftun0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1400 qdisc pfifo_fast state DOWN group default qlen 500
    link/none
    inet6 fe80::600:1512:6243:38fe/64 scope link
       valid_lft forever preferred_lft forever
Read packet from tunnel. 48 bytes.
6000000000083afffe8000000000000006001512624338feff0200000000000000000000000000028500c6e300000000
Read packet from tunnel. 48 bytes.
6000000000083afffe8000000000000006001512624338feff0200000000000000000000000000028500c6e300000000
Read packet from tunnel. 48 bytes.
6000000000083afffe8000000000000006001512624338feff0200000000000000000000000000028500c6e300000000

Furthermore, I can rerun the simple client and continue to receive router solicitations.

Attempting the same procedure again with a small delay replicates the original issue. Notice the sleep statement in between the rftun0_up script and the simple tun client.

$ bash rftun0_down.sh
rftun0 down
16: rftun0: <POINTOPOINT,MULTICAST,NOARP> mtu 1400 qdisc pfifo_fast state DOWN group default qlen 500
    link/none

$ bash rftun0_up.sh && sleep 5 && python simple_tun_client.py
net.ipv6.conf.rftun0.forwarding = 0
net.ipv6.conf.rftun0.accept_ra = 1
net.ipv6.conf.rftun0.autoconf = 1
net.ipv6.conf.rftun0.accept_ra_rt_info_max_plen = 128
net.ipv6.conf.rftun0.accept_ra_rtr_pref = 1
net.ipv6.conf.rftun0.router_solicitation_delay = 1
net.ipv6.conf.rftun0.router_solicitation_interval = 2
net.ipv6.conf.rftun0.router_solicitations = 200
rftun0 up
16: rftun0: <NO-CARRIER,POINTOPOINT,MULTICAST,NOARP,UP> mtu 1400 qdisc pfifo_fast state DOWN group default qlen 500
    link/none
    inet6 fe80::600:25f2:67d0:37fc/64 scope link
       valid_lft forever preferred_lft forever
Timed out...
Timed out...
Timed out...

This test can be repeated as necessary. On my system, sleep times of 2 seconds or larger seem to always produce the issue, while sleep times of 1 second seem to work most of the time.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1533304

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Joseph Ishac (jishac)]

This is not a kernel crash or panic but rather a behavior bug. Furthermore, our test machines do not have Internet access. If there is particular information that would aid in this report, please note it directly.

Kernel in use:
$ uname -srv
Linux 3.13.0-74-generic #118-Ubuntu SMP Thu Dec 17 22:52:10 UTC 2015

[penalvch (penalvch)]

Joseph Ishac, thank you for reporting this and helping make Ubuntu better.

Could you please provide an offline apport-collect uncompressed/untarred as outlined in https://help.ubuntu.com/community/ReportingBugs#Filing_bugs_when_offline_or_using_a_headless_setup ?

[Joseph Ishac (jishac)]

Relevant information from apport attached.

As a reminder this bug can be reproduced using the instructions and scripts in the original post.

Please look into that package.

[penalvch (penalvch)]

Joseph Ishac, to clarify, I'm not in need of a reminder as I read the report in full.

Despite this, the file posted contains very little value. Hence, could you please advise what terminal command you executed precisely, and then if you hand edited it before attaching it?

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]