Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 234067 - IPv6 connection fails
Summary: IPv6 connection fails
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks: FC7Blocker
TreeView+ depends on / blocked
 
Reported: 2007-03-26 20:40 UTC by David Woodhouse
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-04-19 21:44:33 UTC


Attachments (Terms of Use)

Description David Woodhouse 2007-03-26 20:40:13 UTC
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 20:54:25 UTC
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 20:58:39 UTC
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 21:51:33 UTC
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 22:21:13 UTC
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 22:27:44 UTC
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 13:58:58 UTC
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 20:23:14 UTC
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 20:55:58 UTC
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 21:44:33 UTC
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.