# Browsers take forever to connect to servers

## NP_complete

I ran emerge --sync recently, and my Internet became viciously slow after that, both when using Firefox and Chromium.  Everything is fine about 30-40% of the time, and then suddenly the connections become very slow.  In some cases, the webpage eventually loads.  In others, the connection is silently dropped.  Once or twice, I caught the problem in the act by running, e.g.,

 *Quote:*   

> $ curl -v -6 --head "https://accounts.google.com/ServiceLogin"

 It immediately printed

 *Quote:*   

> *   Trying 2a00:1450:4001:808::200d...

 then it hung, then it came back with *Quote:*   

> * connect to 2a00:1450:4001:808::200d port 443 failed: Connection timed out
> 
> * Failed to connect to accounts.google.com port 443: Connection timed out
> 
> * Closing connection 0
> ...

 

What might be going wrong?  This does NOT look like a DNS issue, or does it???

Many thanks.

----------

## khayyam

 *NP_complete wrote:*   

> I ran emerge --sync recently, and my Internet became viciously slow after that, both when using Firefox and Chromium.

 

NP_complete ... whatever the reason I find it very difficult to believe that an 'emerge --sync' would play any part in it.

 *NP_complete wrote:*   

> Everything is fine about 30-40% of the time, and then suddenly the connections become very slow.  In some cases, the webpage eventually loads.  In others, the connection is silently dropped.

 

Without details relating to this network (ie, wired/wireless, devices, drivers/kernel, and infrastructure) its impossible to say.

 *NP_complete wrote:*   

> What might be going wrong?  This does NOT look like a DNS issue, or does it???

 

It could quite possibly be DNS, but as DNS is provided via TCP/IP, and as TCP/IP is dependent on hardware, the issue *could* be anywhere in that stack. Without details any attempt to pinpoint the cause would be speculation.

Also, if you are using 'curl' and the same issue occurs then the 'browser' isn't at issue.

best ... khay

----------

## NeddySeagoon

NP_complete,

I hate to say "me too" ... but I may have a snippet to add.

For me, it only happens with google.co.uk.  It may take over a minute to load.

However, in another Firefox tab google.fr just works.

That brings me to the conclusion that its not anything I'm doing as the difference.is the page I'm trying to browse.

That said,  google.co.uk is probably in my local DNS cache and google.fr probably isn't.

I also have a dual IPv6/IPv4 stack, the same as yourself.

----------

## khayyam

 *NeddySeagoon wrote:*   

> I hate to say "me too" ... 

 

.... oh, and me too, though I can't say for sure if its related ... I think my issues started with the GHOST fix for glibc. Similar timeframe Neddy? Oh, and for the record, I'm not using ipv6, its ipv4 entirely.

best ... khay

----------

## NP_complete

Thank you much, guys, for replying.

1. In my case, the system was upgraded on March 15th.  Prior to that, it was upgraded February 12th.

2. On March 15th, GLIBC was updated to glibc-2.21-r2.

3. What khayyam said convinces me that the problem is NOT IPv6-related.

4. khayyam, I'm on a wireless network, but I doubt this is relevant.  I tried installing a newer version of linux-firmware - didn't help.  I also got suspicious that networkmanager-1.0.10-r1 is only stable on AMD64.  Tried downgrading it - no profit.

5. For me, the problem happens across the board.  It is NOT tied to one (or several) particular website(s).

6. If you do nail it, can you please post it here?

Many thx!

----------

## gerdesj

NP_complete

There are quite a few variables here and most of them are IPv6 related.  I have been running dual stack for ages and it works fine until someone upstream buggers it up.  Unfortunately "Happy Eyeballs" (Google it and see https://tools.ietf.org/html/rfc6555) is not supported in Linux yet as such.  So until it is we all have to be a bit cute as end users.

```
You - router - ISP - target
```

When you do IPv6 then you have to take responsibility for rather more than you would with IPv4 which is generally working and monitored by all the components in the above diagram.  Note that of course your end might involve VLANs and internal routing and all sorts of exciting things.

DNS is a single protocol for IPv4 and 6 so you can't rely on a valid AAAA record coming back to be indicative of a valid IPv6 path to the destination because you could get a AAAA record back over IPv4 and/or 6.

There's a lot to cover here but if you are going to do dual stack then you have to suffer along with the rest of us  :Cool:   To diagnose where the fault is you need to go back to basics.  Google treat ipv6 as well as they do ipv4 so it is unlikely the fault is there.  

At your end you need to ensure that you allow a certain amount of icmpv6 to work and is not blocked in any way.  Packet fragmentation in ipv4 is allowed along the path or is broken, hence people setting MTU sizes manually.  In v6 it is only done at the client. See https://tools.ietf.org/html/rfc4890

I suggest that when you suspect an IPv6 related problem that you perform a basic test: ping6 Google's Public DNS - they are always available and they always respond

2001:4860:4860::8888

2001:4860:4860::8844

They are not just two boxes, there are lots of them but they are on the end of those addresses (anycast I think).

Now if that fails then you need to confirm that you can ping6 something in your ISP (that's up to you to work out)

Finally check that you can ping6 your own router - internal and external addresses 

Actually a first check would be to see if SLAAC/DHCPv6 addresses still exist on the system that you are using.  If you only use SLAAC then they will vanish pretty soon when the router stops giving them out. 

Cheers

Jon

PS I should mention that I have never managed to diagnose a fault in IPv6 at my Gentoo endpoint yet.  It's always other end - ISP - my router in that order.  My router (pfSense) is nowadays nearly infallible and so is my ISP these days.  Happy Eyeballs support in Linux generally would be nice but it's a user space thing really.

----------

