After upgrading my laptop to rawhide, I don't seem to get IPv6 addresses by RA when I'm using NetworkManager. It seems to work OK when I'm bringing it up and down manually and using dhclient -- even when I play the trick that NM does with removing and replacing the link-local address.
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.