Bug 234067

It comes up _very_ briefly with the proper IPv6 address, but NetworkManager
seems to _delete_ the address received by RA when it gets a DHCPv4 response.

Or sometimes, it associates and comes up with the correct IPv6 address, but then
asks me for a new WEP key -- and then starts trying to do DHCP without actually
bringing the interface _up_. Which doesn't work too well.

At least the IPv6 bit seems to be a kernel problem. When I add addresses, they
seem to be marked 'tentative' and not actually work.

shinybook /home/dwmw2 # ip -6 addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:8b0:10b:1:20a:95ff:fef3:9992/64 scope global tentative 
       valid_lft forever preferred_lft forever
    inet6 fec0::1/64 scope site tentative 
       valid_lft forever preferred_lft forever
    inet6 fe80::20a:95ff:fef3:9992/64 scope link tentative 
       valid_lft forever preferred_lft forever

Is this the 3017 kernel?  If so, can you try the 3016 or 3023 kernels?  I've had
general networking issues with 3017, and either upgrading or downgrading fixes
it for me.

I see it on 3109 and 2982 too. I'm definitely blaming the kernel -- the trick we
play of removing the link-local address and then adding it back again when we're
ready to play leaves us with a 'tentative' address, which doesn't work.

shinybook /home/dwmw2 # ip -6 addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:8b0:10b:1:20a:95ff:fef3:9992/64 scope global dynamic 
       valid_lft 294sec preferred_lft 114sec
    inet6 fe80::20a:95ff:fef3:9992/64 scope link 
       valid_lft forever preferred_lft forever
shinybook /home/dwmw2 # ip link set eth1 downshinybook /home/dwmw2 # ip link set
eth1 up ; ip -6 addr del fe80::20a:95ff:fef3:9992/64 dev eth1
shinybook /home/dwmw2 # ip -6 addr list1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
shinybook /home/dwmw2 # ip -6 addr add fe80::20a:95ff:fef3:9992/64 dev eth1
shinybook /home/dwmw2 # ip -6 addr list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 fe80::20a:95ff:fef3:9992/64 scope link tentative 
       valid_lft forever preferred_lft forever

Reverting commit c7ababbdc647e67e953d153ddf62cbdc9fe3297e makes it work again.

http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=c7ababbdc647e67e953d153ddf62cbdc9fe3297e

That is a bug fix though, so reverting that isn't the answer only
a potential clue :)

Why are we messing around with the link-local addresses at all
in userspace?  If NetworkManager is doing this, that is a very
major bug.

Link-local addresses are assigned by the kernel and should be left
alone by userspace.  They are based upon the MAC address, are
permanent, and allow the host to speak on the local link without
being assigned a global address.

As I understand it, NetworkManager wants a state which is _not_ IFF_UP; not
ready to carry traffic; but in which power is applied to the wireless interface
and we can scan for networks and attempt to associate. Once we've chosen to use
the device in question and associated with an access point, _then_ we want to
enter the normal 'IFF_UP' state, at which point the link-local address gets
added to the device and the autoconf starts.

Such a state doesn't exist; we used to fake it by _removing_ the link-local
address when we're in the 'just-scanning' mode, and then adding the link-local
address back again once the interface is really intended to be live. An
alternative plan may be required; perhaps just disabling autoconf for the
interface in question and re-enabling it later, while leaving the link-local
address active at all times.

This is now fixed in the kernel. It's still not clear that removing the
link-local address and putting it back again is the "right" thing to do, but at
least it's working again for now.