Description of problem: NetworkManager controlled IPv6 SLAAC/user space RA causes chrome and firefox to stall when accessing *some* websites, e.g., www.cisco.com, en.wikipedia.org. While the browser is stalling, the website is ping6-able Some websites like mail.google.com are unaffected. When I use manual network configuration, with kernel RA, all IPv6 sites work. Version-Release number of selected component (if applicable): NetworkManager-30.git20131003.fc20 How reproducible: Always, but to certain IPv6-enabled websites only. Steps to Reproduce: 1. Configure a static IPv6 interface + default gateway (using the router link-local address) 2. Point web browser to www.cisco.com en.wikipedia.org 3. Actual results: Browser stalls accessing the page. Website is ping6-able Expected results: Browser will load page. Additional info: With manual network configuration (no-NM, kernel RA) all IPv6 sites are accessible. I noticed in this case that the IPv6 route cache is filled with tonnes of stuff (see following comment). NM configuration (using keyfile plugin): [ethernet] mac-address=12:12:12:12:12:12 [connection] id=Wired connection 1 uuid=3824c2ed-e1b7-4aa5-b50a-7710ece31eab type=ethernet timestamp=1393259568 [ipv6] method=manual address1=1234:1234:1234:1234::7/64,fe80::1234:56ff:fe12:3456 [ipv4] method=manual dns=8.8.8.8;8.8.4.4; address1=192.168.1.7/24,192.168.1.1 sysctl: net.ipv6.conf.em1.accept_ra = 0 net.ipv6.conf.em1.autoconf = 1 ## looking good here # ip -6 addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 inet6 1234:1234:1234:1234::7/64 scope global valid_lft forever preferred_lft forever inet6 fe80::1212:12ff:fe12:1212/64 scope link valid_lft forever preferred_lft forever # ip -6 ro sh 1234:1234:1234:1234::/64 dev em1 proto kernel metric 256 fe80::/64 dev em1 proto kernel metric 256 default via fe80::1234:56ff:fe12:3456 dev em1 proto static metric 1024 ## chrome and firefox stall accessing: ## www.cisco.com ## en.wikipedia.org ## yet both sites are ping6-able # ping6 www.cisco.com PING www.cisco.com(2600:1417:9:193::90) 56 data bytes 64 bytes from 2600:1417:9:193::90: icmp_seq=1 ttl=55 time=239 ms 64 bytes from 2600:1417:9:193::90: icmp_seq=2 ttl=55 time=235 ms
1. An ubuntu machine 13.10, and Mac OS X on the same LAN have no problem. Ubuntu is using nm-0.9.8, net.ipv6.conf.wlan0.accept_ra = 2 2. This LAN is behind a Linksys EA6700 router using ISP IPv6 6rd. 3. Manual network setup (no-NM) works, i.e., no stalling to any IPv6 websites. nmcli c down "Wired connection 1" systemctl stop NetworkManager ifup em1 TYPE="Ethernet" BOOTPROTO=none DEFROUTE="yes" IPV4_FAILURE_FATAL="no" IPV6INIT="yes" IPV6_AUTOCONF=yes IPV6_DEFROUTE="yes" IPV6_FAILURE_FATAL="no" NAME="em1" UUID="7a778ff1-fc85-46a2-914a-3cdd2ba83652" ONBOOT="yes" IPADDR0=192.168.1.7 PREFIX0=24 GATEWAY0=192.168.1.1 GATEWAY=192.168.1.1 DNS1=8.8.8.8 DNS2=8.8.4.4 HWADDR=12:12:12:12:12:12 IPV6ADDR=1234;1234:1234:1234::7/64 ##IPV6_DEFAULTGW=fe80::1234:56ff:fe12:3456 ##IPV6_DEFAULTDEV=em1 sysctl: net.ipv6.conf.em1.accept_ra = 1 net.ipv6.conf.em1.autoconf = 1 Weirdness here, kernel RA seems to populate lots of unnecessary routes. $ ping6 www.cisco.com PING www.cisco.com(2600:1417:9:195::90) 56 data bytes 64 bytes from 2600:1417:9:195::90: icmp_seq=1 ttl=55 time=236 ms 64 bytes from 2600:1417:9:195::90: icmp_seq=2 ttl=55 time=228 ms 64 bytes from 2600:1417:9:195::90: icmp_seq=3 ttl=55 time=237 ms ^C --- www.cisco.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 228.497/234.246/237.311/4.087 ms $ ip -6 ro sh 2001:420:1101:4::a via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2001:420:1101:5::a via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2001:4860:4860::8888 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2404:6800:4001:c01::7d via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2404:6800:4003:c00::84 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2404:6800:4007:800::1010 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2404:6800:4007:801::1004 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2404:6800:4007:801::1006 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2404:6800:4007:801::100e via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2404:6800:4007:802::1018 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2404:6800:4007:803::1008 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2404:6800:4007:803::1017 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2404:e801:dad4:6dee::/64 dev em1 proto kernel metric 256 2600:1417:9:191::ad6 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2600:1417:9:195::90 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2607:f220:41e:4290::110 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2620:0:863:ed1a::1 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2620:0:863:ed1a::1:a via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2620:0:863:ed1a::2:b via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2620:114:d000:2716::200 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache 2a00:1a48:7805:112:2c13:65be:ff08:2e89 via fe80::1234:56ff:fe12:3456 dev em1 metric 0 cache fe80::/64 dev em1 proto kernel metric 256 default via fe80::1234:56ff:fe12:3456 dev em1 proto ra metric 1024 expires 3556sec
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.