Ubuntu
linux package

  1. Bug #894272
  2. Comment #3

Comment 3 for bug 894272

Revision history for this message
Sarah Newman (srn-f) wrote :

Hi,

I am using 12.04 and that particular sequence appears to be expected behavior due to duplicate address detection in ipv6 leading to the ipv6 address being tentative. I see similar behavior on an ethernet port which has never physically been connected to anything.

Before attaching anything to the bridge, it has NO-CARRIER and tentative ipv6 address, ping does not work:

$ ip addr show br0
26: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
    link/ether 00:16:3e:ff:00:01 brd ff:ff:ff:ff:ff:ff
    inet6 2605:2700:0:18::1/64 scope global tentative
       valid_lft forever preferred_lft forever

After attaching something which is itself up:
$ ip addr show br0
26: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:16:3e:ff:00:01 brd ff:ff:ff:ff:ff:ff
    inet6 2605:2700:0:18::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:feff:1/64 scope link
       valid_lft forever preferred_lft forever

ping works at this point.

Furthermore, after removing the interface, NO-CARRIER is back but the address is still no longer tentative and is still pingable:

$ ip addr show br0
26: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
    link/ether 00:16:3e:ff:00:01 brd ff:ff:ff:ff:ff:ff
    inet6 2605:2700:0:18::1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::216:3eff:feff:1/64 scope link
       valid_lft forever preferred_lft forever
$ ping6 -c1 2605:2700:0:18::1
PING 2605:2700:0:18::1(2605:2700:0:18::1) 56 data bytes
64 bytes from 2605:2700:0:18::1: icmp_seq=1 ttl=64 time=0.047 ms

With 3.5.0-43-generic, I set net.ipv6.conf.all.dad_transmits and net.ipv6.conf.all.accept_dad to 0 and that doesn't cause the addresses to no longer be tentative. It seems like redhat may have had a similar bug https://bugzilla.redhat.com/show_bug.cgi?id=709271 but it is not clear what they did to fix it. I have not yet tried more recent kernels to see if the problem is fixed there.