Bug 234067 - IPv6 connection fails
IPv6 connection fails
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
: Regression
Depends On:
Blocks: FC7Blocker
  Show dependency treegraph
 
Reported: 2007-03-26 16:40 EDT by David Woodhouse
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-19 17:44:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2007-03-26 16:40:13 EDT
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.
Comment 1 David Woodhouse 2007-03-26 16:54:25 EDT
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.
Comment 2 David Woodhouse 2007-03-26 16:58:39 EDT
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.
Comment 3 David Woodhouse 2007-03-26 17:51:33 EDT
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
Comment 4 Christopher Aillon 2007-03-26 18:21:13 EDT
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.
Comment 5 David Woodhouse 2007-03-26 18:27:44 EDT
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
Comment 6 David Woodhouse 2007-03-27 09:58:58 EDT
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
Comment 7 David Miller 2007-03-27 16:23:14 EDT
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.
Comment 8 David Woodhouse 2007-03-27 16:55:58 EDT
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.
Comment 9 David Woodhouse 2007-04-19 17:44:33 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.