Bug 587836

Summary:	IPv6 Link local doesn't work as advertised
Product:	[Fedora] Fedora	Reporter:	Scott Schmit <i.grok>
Component:	NetworkManager	Assignee:	Dan Williams <dcbw>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	12	CC:	dcbw
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	NetworkManager-0.8.1-0.1.git20100510.fc12	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	589830 (view as bug list)		Environment:
Last Closed:	2010-05-07 02:58:20 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Scott Schmit 2010-05-01 01:58:23 UTC

Description of problem:
IPv6 configuration allows for a "Link Local" connection method, but connecting a connection with IPv6 set to link-local configures more than just link local addresses on the interface.

Version-Release number of selected component (if applicable):
NetworkManager-0.8.0-9.git20100429.fc12.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Create a new connection
2. Set the IPv6 method to "Link Local"
3. Apply and connect to a network that has RA enabled
  
Actual results:
"ip addr" shows more than just the link local address. In my case, I have a private SLAAC address and a 6to4 address advertised from the router.

Expected results:
Just the link local address, as advertised, or if that's not possible, this connection method wouldn't be provided.

Additional info:
This is true for both wireless and wired, but it's hard to tell on ethernet if you don't restart NM every time, because after the first connection, NM stops picking up non-link-local SLAAC addresses on ethernet (which I *think* is related to Bug #587513).

Comment 1 Scott Schmit 2010-05-02 18:57:12 UTC

ip addr now just shows the link local address, but the IPv6 routing table is missing routes for that interface:
$  ping6 ff02::1%wlan0
connect: Network is unreachable

Comment 2 Scott Schmit 2010-05-02 19:38:30 UTC

However, this works if I remove all the IPv6 addresses from the interface while it's down (I'll file a separate bug that that doesn't happen normally).

Comment 3 Dan Williams 2010-05-03 09:26:10 UTC

Hmm; when I do that with latest git (there haven't been any fixes in this area since git20100502 builds) I get this:

wlan0     Link encap:Ethernet  HWaddr 00:22:FA:8C:D6:C2  
          inet addr:192.168.0.126  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::222:faff:fe8c:d6c2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:48463 errors:0 dropped:0 overruns:0 frame:0
          TX packets:46087 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:47494747 (45.2 MiB)  TX bytes:5365833 (5.1 MiB)

[dcbw@localhost NetworkManager (master)]$ ping6 -I wlan0 fe80::214:22ff:fefd:6e7
PING fe80::214:22ff:fefd:6e7(fe80::214:22ff:fefd:6e7) from fe80::222:faff:fe8c:d6c2 wlan0: 56 data bytes
64 bytes from fe80::214:22ff:fefd:6e7: icmp_seq=1 ttl=64 time=3.91 ms
64 bytes from fe80::214:22ff:fefd:6e7: icmp_seq=2 ttl=64 time=1.30 ms
64 bytes from fe80::214:22ff:fefd:6e7: icmp_seq=3 ttl=64 time=1.28 ms

and my routing table looks like this:

Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
fe80::214:22ff:fefd:6e7/128                 fe80::214:22ff:fefd:6e7                 UC    0      6        0 wlan0   
fe80::/64                                   ::                                      U     256    0        0 virbr0  
fe80::/64                                   ::                                      U     256    0        0 wlan0   
::1/128                                     ::                                      U     0      5        1 lo      
fe80::222:faff:fe8c:d6c2/128                ::                                      U     0      8        1 lo      
ff00::/8                                    ::                                      U     256    0        0 virbr0  
ff00::/8                                    ::                                      U     256    0        0 wlan0   


If you see this issue again, can you grab the 'route -A inet6 -n' output for me?

Comment 4 Scott Schmit 2010-05-03 12:02:30 UTC

Well, this is what happens (I guess my comments were a little cryptic):
Start with nothing:

# ip addr show dev wlan0
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
# ip -6 route
<empty>
# route -A inet6
Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
localhost6.localdomain6/128                 *                                       U     0      6        1 lo

Connect via connection with IPv6 set to link local (I kept IPv4 disabled for simplicity):
# ip addr show dev wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever
# ip -6 route
fe80::/64 dev wlan0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 4294967295
# route -A inet6 -n
Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
fe80::/64                                   ::                                      U     256    0        0 wlan0   
::1/128                                     ::                                      U     0      6        1 lo      
fe80::xxxx:xxxx:xxxx:xxxx/128                ::                                      U     0      0        1 lo      
ff02::1/128                                 ff02::1                                 UC    0      8        0 wlan0   
ff00::/8                                    ::                                      U     256    0        0 wlan0   
<I hate that they don't match>

disconnect
# ip addr show dev wlan0
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever
# ip -6 route
<empty>
# route -A inet6 -n
Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
::1/128                                     ::                                      U     0      6        1 lo      
fe80::xxxx:xxxx:xxxx:xxxx/128                ::                                      U     0      0        1 lo    

Then connect via the same connection
# ip addr show dev wlan0
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link 
       valid_lft forever preferred_lft forever
# ip -6 route
<empty>
# route -A inet6 -n
Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
::1/128                                     ::                                      U     0      6        1 lo      
fe80::xxxx:xxxx:xxxx:xxxx/128                ::                                      U     0      0        1 lo

Therefore ping6 doesn't work.

If I do ip addr del fe80::xxxx:xxxx:xxxx:xxxx/64 dev wlan0, it reverts back to the start of this comment.

Comment 5 Dan Williams 2010-05-03 12:27:58 UTC

Can you give:

https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-11.git20100503.fc13
https://admin.fedoraproject.org/updates/NetworkManager-0.8.0-11.git20100503.fc12

a try?  I don't specifically expect them to work but there have been fixes in that area over the past 24 hours.

Comment 6 Scott Schmit 2010-05-04 11:22:12 UTC

No change.

Comment 7 Dan Williams 2010-05-05 03:26:50 UTC

upstream fix is 17b49b957cb3d92a86ccdce0559e6b753bd7aa98.  This preserves the fe80::/64 routes that the kernel appears only to add when initially assigning the LL address to the interface.

Comment 8 Fedora Update System 2010-05-05 09:16:14 UTC

NetworkManager-0.8.0-12.git20100504.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/NetworkManager-0.8.0-12.git20100504.fc13

Comment 9 Fedora Update System 2010-05-05 09:18:56 UTC

NetworkManager-0.8.0-12.git20100504.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/NetworkManager-0.8.0-12.git20100504.fc12

Comment 10 Scott Schmit 2010-05-05 12:03:18 UTC

Using NetworkManager-0.8.0-12.git20100504.fc12.x86_64:
ip -6 route must be papering over some details or something.

$ ip -6 route
fe80::/64 dev wlan0  proto kernel  metric 256  mtu 1280 advmss 1220 hoplimit 4294967295
$ ping6 ff02::1%wlan0
connect: Network is unreachable
$ route -nA inet6
Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
fe80::/64                                   ::                                      U     256    0        0 wlan0   
::1/128                                     ::                                      U     0      8        1 lo      
fe80::xxxx:xxxx:xxxx:xxxx/128                ::                                      U     0      0        1 lo      

I guess it's also supposed to include:
ff02::1/128                                 ff02::1                                 UC    0      3        0 wlan0   
ff00::/8
::                                      U     256    0        0 wlan0

I think the better fix is to ensure that all addresses & routes are removed from the interface when the connection gets disconnected. Is there some reason you didn't want to do that?

Comment 11 Fedora Update System 2010-05-06 03:37:39 UTC

NetworkManager-0.8.0-12.git20100504.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/NetworkManager-0.8.0-12.git20100504.fc12

Comment 12 Fedora Update System 2010-05-06 03:44:31 UTC

NetworkManager-0.8.0-12.git20100504.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update NetworkManager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/NetworkManager-0.8.0-12.git20100504.fc13

Comment 13 Fedora Update System 2010-05-06 07:02:23 UTC

NetworkManager-0.8.0-12.git20100504.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 14 Scott Schmit 2010-05-06 10:45:38 UTC

Reopening, since the fix isn't 100% yet (see Comment 10)

Comment 15 Dan Williams 2010-05-06 23:33:56 UTC

(In reply to comment #10)
> Using NetworkManager-0.8.0-12.git20100504.fc12.x86_64:
> ip -6 route must be papering over some details or something.
> 
> $ ip -6 route
> fe80::/64 dev wlan0  proto kernel  metric 256  mtu 1280 advmss 1220 hoplimit
> 4294967295
> $ ping6 ff02::1%wlan0
> connect: Network is unreachable
> $ route -nA inet6
> Kernel IPv6 routing table
> Destination                                 Next Hop                           
>     Flags Metric Ref    Use Iface
> fe80::/64                                   ::                                 
>     U     256    0        0 wlan0   
> ::1/128                                     ::                                 
>     U     0      8        1 lo      
> fe80::xxxx:xxxx:xxxx:xxxx/128                ::                                
>      U     0      0        1 lo      
> 
> I guess it's also supposed to include:
> ff02::1/128                                 ff02::1                            
>     UC    0      3        0 wlan0   
> ff00::/8
> ::                                      U     256    0        0 wlan0

In my testing, these routes were not necessary to ping the other machine which was the original report's testcase.  Is that not the case for you?  My setup was:

<radvd/dhcp6s host> --- wired --- <WRT54G> --- wifi (WPA Enterprise) --- <test laptop>

In this setup after re-connecting the fe80::/64 route reappeared and I was able to ping from the test laptop to the radvd/dhcp6s host.

These are Multicast Link-Local (ff02::1) and Multicast (ff00::/8) routes and they actually appear to get removed by the kernel when the interface goes down even without NetworkManager involved; I tested allowing them but even without deleting them they didn't come back.

> I think the better fix is to ensure that all addresses & routes are removed
> from the interface when the connection gets disconnected. Is there some reason
> you didn't want to do that?    

NM doesn't add these routes; they are added by the kernel automagically and apparently if they get removed by something else they don't come back.

If you can ping6 the machine now, then lets close this bug and file another one because I don't think missing the MC/MC+LL routes are as critical as not being able to ping like the original report stated.  Is that OK?

If you can't ping6 between machines with the latest packages, then we'll keep this bug open and I'll try to re-verify the fix from earlier this week.

Comment 16 Scott Schmit 2010-05-07 00:24:44 UTC

I am able to ping6 link local addresses. But if I remove the local address when the interface is brought down, the next time it comes up, all the routes are restored correctly. Is there a reason to keep the link local address on the interface while it's down?

If we were to file a bug against something else, I'd think it would be against the kernel.

Comment 17 Dan Williams 2010-05-07 01:29:20 UTC

(In reply to comment #16)
> I am able to ping6 link local addresses. But if I remove the local address when
> the interface is brought down, the next time it comes up, all the routes are
> restored correctly. Is there a reason to keep the link local address on the
> interface while it's down?
> 
> If we were to file a bug against something else, I'd think it would be against
> the kernel.    

Mainly an artifact of the previous IPv6 support (or lack thereof).  NM wouldn't touch anything IPv6-related, and thus the LL address would always be assigned to the device.  Were NM to flush everything when the device went down that would be a behavioral change that I'm not 100% how we want to approach at this point.

So, not sure what we want to do here. Close this bug (since we can now ping6 LL hosts) and file an enhancement request for removing all IPv6 addressing and routes when the interface is down?  Or leave this one open and change it to be that?  Thoughts?

Comment 18 Scott Schmit 2010-05-07 02:58:20 UTC

You're right, it's a different bug. I've opened a new bug, bug 589830.

One thing I just noticed is that this bug only happens when connecting via link-local. Manual and automatic both don't get this result.

Comment 19 Fedora Update System 2010-05-11 06:54:59 UTC

NetworkManager-0.8.1-0.1.git20100510.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/NetworkManager-0.8.1-0.1.git20100510.fc12

Comment 20 Fedora Update System 2010-06-10 19:06:37 UTC

NetworkManager-0.8.1-0.1.git20100510.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.