Bug 1069633 - NetworkManager IPv6 web browser stalls to some sites
Summary: NetworkManager IPv6 web browser stalls to some sites
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 20
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-25 12:40 UTC by Richard Chan
Modified: 2015-06-29 19:05 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-29 19:05:12 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1045118 0 unspecified CLOSED IPv6 SLAAC addresses are added with a /128 prefix [was: IPv6 SLAAC does not work on Fedora 20] 2021-02-22 00:41:40 UTC

Description Richard Chan 2014-02-25 12:40:28 UTC
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

Comment 1 Richard Chan 2014-02-25 12:52:19 UTC
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

Comment 2 Fedora End Of Life 2015-05-29 11:03:06 UTC
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.

Comment 3 Fedora End Of Life 2015-06-29 19:05:12 UTC
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.


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