← Back to team overview

kernel-packages team mailing list archive

  1. kernel-packages team
  2. Mailing list archive
  3. Message #155546

[Bug 1533304] [NEW] Kernel Bug: IPv6 Neighbor Discovery

  Thread Previous • Date Previous • • Thread Next 
Public bug reported:

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.

** Affects: linux (Ubuntu)
     Importance: Undecided
         Status: Incomplete


** Tags: kernel-bug

** Attachment added: "Contains the scripts used in the writeup"
   https://bugs.launchpad.net/bugs/1533304/+attachment/4548681/+files/scripts.tgz

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1533304

Title:
  Kernel Bug: IPv6 Neighbor Discovery

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533304/+subscriptions

Follow ups

  Thread Previous • Date Previous • • Thread Next