New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection timed out #4142

Closed
stevekessler opened this Issue Jun 13, 2015 · 45 comments

Comments

Projects
None yet
@stevekessler

stevekessler commented Jun 13, 2015

I am getting the following error when trying to install Composer.

Download failed: file_get_contents(https://getcomposer.org/composer.phar): failed to open stream: Connection timed out

I have checked and I can download the composer.phar from the URL above but for some reason when running the installer script it fails.

I am on Ubuntu 14.04 LTS with PHP 5..5.9 installed.

Any help with this is greatly appreciated.

Jump to [https://github.com//issues/4142#issuecomment-117648869] for a solution.

@florentchaboud

This comment has been minimized.

Show comment
Hide comment
@florentchaboud

florentchaboud Jun 15, 2015

I have the same issue while launching a composer self-update or composer update.
Thanks for your help !

florentchaboud commented Jun 15, 2015

I have the same issue while launching a composer self-update or composer update.
Thanks for your help !

@hisem

This comment has been minimized.

Show comment
Hide comment
@hisem

hisem Jun 15, 2015

+1

php composer.phar self-update

[Composer\Downloader\TransportException]
  The "https://getcomposer.org/version" file could not be downloaded: failed to open
   stream: Operation timed out

hisem commented Jun 15, 2015

+1

php composer.phar self-update

[Composer\Downloader\TransportException]
  The "https://getcomposer.org/version" file could not be downloaded: failed to open
   stream: Operation timed out
@andrerom

This comment has been minimized.

Show comment
Hide comment
@andrerom

andrerom Jun 16, 2015

Contributor

Same issue on travis the last few days, random issue on composer self-update and composer install.

Contributor

andrerom commented Jun 16, 2015

Same issue on travis the last few days, random issue on composer self-update and composer install.

@andrerom

This comment has been minimized.

Show comment
Hide comment
@andrerom

andrerom Jun 17, 2015

Contributor

Found one occurrence where exception is in output before Travis times out the job, seems to point to Packagist issues, ping @Seldaek.

Loading composer repositories with package information
Installing dependencies (including require-dev)

  [Composer\Downloader\TransportException]                                     
  The "https://packagist.org/p/provider-2015-04$09216eba37b88a33b285255b42471  
  233978e280e3574316a65d6534cd8a11c1c.json" file could not be downloaded: SSL  
  : Connection reset by peer                                                   
  failed to open stream: HTTP request failed!                                  

https://travis-ci.org/ezsystems/ezpublish-legacy/jobs/66584042

Trying to access the packagist url gives a 404 now.

Contributor

andrerom commented Jun 17, 2015

Found one occurrence where exception is in output before Travis times out the job, seems to point to Packagist issues, ping @Seldaek.

Loading composer repositories with package information
Installing dependencies (including require-dev)

  [Composer\Downloader\TransportException]                                     
  The "https://packagist.org/p/provider-2015-04$09216eba37b88a33b285255b42471  
  233978e280e3574316a65d6534cd8a11c1c.json" file could not be downloaded: SSL  
  : Connection reset by peer                                                   
  failed to open stream: HTTP request failed!                                  

https://travis-ci.org/ezsystems/ezpublish-legacy/jobs/66584042

Trying to access the packagist url gives a 404 now.

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Jun 17, 2015

Member

Those files live quite temporarily so the 404 now is normal. The connection reset by peer though isn't normal, and I believe this one might be our fault as there are a few (like 10 out of the 20+ million requests yesterday) nginx errors in the log. That seems to be a very sporadic failure when we swap the files though, and I doubt it relates at all to the timeout problems. Those I'd imagine are more network related and harder to debug.

Member

Seldaek commented Jun 17, 2015

Those files live quite temporarily so the 404 now is normal. The connection reset by peer though isn't normal, and I believe this one might be our fault as there are a few (like 10 out of the 20+ million requests yesterday) nginx errors in the log. That seems to be a very sporadic failure when we swap the files though, and I doubt it relates at all to the timeout problems. Those I'd imagine are more network related and harder to debug.

@mtarvainen

This comment has been minimized.

Show comment
Hide comment
@mtarvainen

mtarvainen Jun 17, 2015

Would it be something IPv6 related? I'm working in cloud environment and as soon as I got rid of IPv6, composers self-update started working again. Actually I ran into same kind of problems with apt, which there are luckily workaround available.

So whatever the root cause turns out to be, that's what helped to solve problem here.

mtarvainen commented Jun 17, 2015

Would it be something IPv6 related? I'm working in cloud environment and as soon as I got rid of IPv6, composers self-update started working again. Actually I ran into same kind of problems with apt, which there are luckily workaround available.

So whatever the root cause turns out to be, that's what helped to solve problem here.

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Jun 17, 2015

Member

That'd be interesting.. I only enabled IPv6 last week though so I doubt it's that as these issues have been cropping up here and there randomly for ages.

Member

Seldaek commented Jun 17, 2015

That'd be interesting.. I only enabled IPv6 last week though so I doubt it's that as these issues have been cropping up here and there randomly for ages.

@gmarquet

This comment has been minimized.

Show comment
Hide comment
@gmarquet

gmarquet Jun 18, 2015

Same over here on a fresh VM with Ubuntu 14.04 and PHP 5.5.9.

php composer.phar self-update
[Composer\Downloader\TransportException]
  The "https://getcomposer.org/version" file could not be downloaded: failed
  to open stream: Connection timed out

gmarquet commented Jun 18, 2015

Same over here on a fresh VM with Ubuntu 14.04 and PHP 5.5.9.

php composer.phar self-update
[Composer\Downloader\TransportException]
  The "https://getcomposer.org/version" file could not be downloaded: failed
  to open stream: Connection timed out

@andrerom

This comment has been minimized.

Show comment
Hide comment
@andrerom

andrerom Jun 18, 2015

Contributor

That'd be interesting.. I only enabled IPv6 last week though so I doubt it's that as these issues have been cropping up here and there randomly for ages.

On our end we started getting major issues on travis last week, afaik on Friday. So this could explain it for our case.

FYI, possible clue: We didn't use composer.lock on dev branches, and only way to solve the problem was either use composer cache (but mysql is super slow on travis containers), or use composer.lock, so I assume both have a severe impact on traffic needed to go to packagist.

Those files live quite temporarily so the 404 now is normal. The connection reset by peer though isn't normal, and I believe this one might be our fault as there are a few (like 10 out of the 20+ million requests yesterday) nginx errors in the log.

Ok, may I suggest some simple status page is added to that would show such things? :) If there was one showing that there where some minor issues, then I wouldn't have lost 3 days loosing my sanity over now knowing where the issue was (between travis, github, and packagist).. :/
Travis seems to be using StatusPage.io, so might be simple setting one up.

Contributor

andrerom commented Jun 18, 2015

That'd be interesting.. I only enabled IPv6 last week though so I doubt it's that as these issues have been cropping up here and there randomly for ages.

On our end we started getting major issues on travis last week, afaik on Friday. So this could explain it for our case.

FYI, possible clue: We didn't use composer.lock on dev branches, and only way to solve the problem was either use composer cache (but mysql is super slow on travis containers), or use composer.lock, so I assume both have a severe impact on traffic needed to go to packagist.

Those files live quite temporarily so the 404 now is normal. The connection reset by peer though isn't normal, and I believe this one might be our fault as there are a few (like 10 out of the 20+ million requests yesterday) nginx errors in the log.

Ok, may I suggest some simple status page is added to that would show such things? :) If there was one showing that there where some minor issues, then I wouldn't have lost 3 days loosing my sanity over now knowing where the issue was (between travis, github, and packagist).. :/
Travis seems to be using StatusPage.io, so might be simple setting one up.

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Jun 18, 2015

Member

@andrerom using composer.lock turns off packagist entirely so yes that would help if the connection issue is there. Regarding the errors I am not sure if I was clear but we had 10 failed requests out of 20million, not 10million out of 20 :) So even if you saw a few glitches on a graph I doubt it would help identify anything in this case.

Member

Seldaek commented Jun 18, 2015

@andrerom using composer.lock turns off packagist entirely so yes that would help if the connection issue is there. Regarding the errors I am not sure if I was clear but we had 10 failed requests out of 20million, not 10million out of 20 :) So even if you saw a few glitches on a graph I doubt it would help identify anything in this case.

@hisem

This comment has been minimized.

Show comment
Hide comment
@hisem

hisem Jun 18, 2015

Would it be something IPv6 related? I'm working in cloud environment and as soon as I got rid of IPv6, composers self-update started working again. Actually I ran into same kind of problems with apt, which there are luckily workaround available.

So whatever the root cause turns out to be, that's what helped to solve problem here.

I deactivated IPv6 on our network router and the problem went away as well. Activating it again brought the Connection Timeout error back. So it does seem that the problem is linked in some way to IPv6... Hope this helps!

hisem commented Jun 18, 2015

Would it be something IPv6 related? I'm working in cloud environment and as soon as I got rid of IPv6, composers self-update started working again. Actually I ran into same kind of problems with apt, which there are luckily workaround available.

So whatever the root cause turns out to be, that's what helped to solve problem here.

I deactivated IPv6 on our network router and the problem went away as well. Activating it again brought the Connection Timeout error back. So it does seem that the problem is linked in some way to IPv6... Hope this helps!

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Jun 18, 2015

Member

Well.. it "helps" in the sense that we probably know what is broken, but it doesn't really help to fix it or identify exactly why it fails. I definitely don't know enough about low level network or IPv6 to dig into this.

Member

Seldaek commented Jun 18, 2015

Well.. it "helps" in the sense that we probably know what is broken, but it doesn't really help to fix it or identify exactly why it fails. I definitely don't know enough about low level network or IPv6 to dig into this.

@johannes

This comment has been minimized.

Show comment
Hide comment
@johannes

johannes Jun 18, 2015

Works nicely from my IPv6 host.

$ host packagist.org
packagist.org has address 87.98.253.214
packagist.org has IPv6 address 2001:41d0:a:7b19::
[...]
$ host getcomposer.org
getcomposer.org has address 87.98.253.108
getcomposer.org has IPv6 address 2001:41d0:a:7b19::
[..]
$ ping6 2001:41d0:a:7b19::
PING 2001:41d0:a:7b19::(2001:41d0:a:7b19::) 56 data bytes
64 bytes from 2001:41d0:a:7b19::: icmp_seq=1 ttl=56 time=48.3 ms
$ php -r 'echo file_get_contents("http://packagist.org");'
[long output cut]
$ php -a
Interactive mode enabled

php > $ch = curl_init();
php > curl_setopt($ch, CURLOPT_URL, "http://packagist.org/");
php > curl_setopt($ch, CURLOPT_HEADER, 0);
php > curl_exec($ch);
<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="refresh" content="1;url=https://packagist.org/" />

        <title>Redirecting to https://packagist.org/</title>
    </head>
    <body>
        Redirecting to <a href="https://packagist.org/">https://packagist.org/</a>.
    </body>
</html>
php > curl_close($ch);
php > $ch = curl_init();
php > curl_setopt($ch, CURLOPT_URL, "http://[2001:41d0:a:7b19::]/");
php > curl_setopt($ch, CURLOPT_HEADER, 0);
php > curl_exec($ch);
<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
$ php composer.phar self-update
You are already using composer version 75c501251dd0f161ffd488de8e966579785b6cb8.
$ php composer.phar update --dry-run
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Updating monolog/monolog (1.11.0) to monolog/monolog (1.13.1)
[....]

So it isn't IPv6 alone.

johannes commented Jun 18, 2015

Works nicely from my IPv6 host.

$ host packagist.org
packagist.org has address 87.98.253.214
packagist.org has IPv6 address 2001:41d0:a:7b19::
[...]
$ host getcomposer.org
getcomposer.org has address 87.98.253.108
getcomposer.org has IPv6 address 2001:41d0:a:7b19::
[..]
$ ping6 2001:41d0:a:7b19::
PING 2001:41d0:a:7b19::(2001:41d0:a:7b19::) 56 data bytes
64 bytes from 2001:41d0:a:7b19::: icmp_seq=1 ttl=56 time=48.3 ms
$ php -r 'echo file_get_contents("http://packagist.org");'
[long output cut]
$ php -a
Interactive mode enabled

php > $ch = curl_init();
php > curl_setopt($ch, CURLOPT_URL, "http://packagist.org/");
php > curl_setopt($ch, CURLOPT_HEADER, 0);
php > curl_exec($ch);
<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="refresh" content="1;url=https://packagist.org/" />

        <title>Redirecting to https://packagist.org/</title>
    </head>
    <body>
        Redirecting to <a href="https://packagist.org/">https://packagist.org/</a>.
    </body>
</html>
php > curl_close($ch);
php > $ch = curl_init();
php > curl_setopt($ch, CURLOPT_URL, "http://[2001:41d0:a:7b19::]/");
php > curl_setopt($ch, CURLOPT_HEADER, 0);
php > curl_exec($ch);
<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
$ php composer.phar self-update
You are already using composer version 75c501251dd0f161ffd488de8e966579785b6cb8.
$ php composer.phar update --dry-run
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Updating monolog/monolog (1.11.0) to monolog/monolog (1.13.1)
[....]

So it isn't IPv6 alone.

@pilif

This comment has been minimized.

Show comment
Hide comment
@pilif

pilif Jun 18, 2015

after @Seldaek has asked on twitter: I too can confirm that I can reach getcomposer.org over IPv6. The problem is likely on your end.

Can you post a traceroute (using traceroute6 of course)

pilif commented Jun 18, 2015

after @Seldaek has asked on twitter: I too can confirm that I can reach getcomposer.org over IPv6. The problem is likely on your end.

Can you post a traceroute (using traceroute6 of course)

@till

This comment has been minimized.

Show comment
Hide comment
@till

till Jun 18, 2015

Contributor

👍 to these and I also just tried it: IPv6 seems to work as expected.

Contributor

till commented Jun 18, 2015

👍 to these and I also just tried it: IPv6 seems to work as expected.

@hisem

This comment has been minimized.

Show comment
Hide comment
@hisem

hisem Jun 18, 2015

Sorry, I don't have much network knowledge myself... my conclusion was probably way too hasty.

I ran some tests, though I'm not sure if they'll be useful to understand if this problem is only on my side or not. If it is, sorry for wasting your time!

With IPv4:

traceroute getcomposer.org                                                                                                                                             
traceroute to getcomposer.org (87.98.253.108), 64 hops max, 52 byte packets
 1  192.168.0.254 (192.168.0.254)  1.760 ms  1.193 ms  1.188 ms
 2  82.235.37.254 (82.235.37.254)  47.296 ms  34.924 ms  32.431 ms
 3  213.228.21.254 (213.228.21.254)  28.506 ms  31.776 ms  29.416 ms
 4  lyon-crs8-1-be1011.intf.routers.proxad.net (78.254.249.197)  32.788 ms  28.533 ms  32.435 ms
 5  lyon-crs8-2-be1000.routers.proxad.net (212.27.56.158)  44.724 ms  30.051 ms  37.999 ms
 6  p11-crs16-1-be1101.intf.routers.proxad.net (78.254.249.25)  43.217 ms  43.332 ms  45.068 ms
 7  cbv-9k-1-be1001.intf.routers.proxad.net (194.149.161.14)  38.813 ms  49.340 ms  39.542 ms
 8  * gsw-1-6k.fr.eu (213.186.32.169)  82.265 ms *
 9  gsw-g1-a9.fr.eu (213.186.32.157)  42.844 ms  37.096 ms  35.989 ms
10  gra-g1-a9.fr.eu (178.33.103.234)  42.681 ms
    gra-g1-a9.fr.eu (37.187.36.217)  43.689 ms  41.843 ms
11  gra-3a-a9.fr.eu (37.187.231.86)  42.745 ms  49.926 ms  48.635 ms
12  getcomposer.org (87.98.253.108)  39.995 ms  40.158 ms  40.391 ms
~/Sites ❯ php composer.phar self-update
Updating to version 75c501251dd0f161ffd488de8e966579785b6cb8.
    Downloading: 100%
Use composer self-update --rollback to return to version 9fb2d4f2d642a0749decb41bc2fe4be2bf8bef7a

Then I switched to IPv6:

~/Sites ❯ php composer.phar self-update

  [Composer\Downloader\TransportException]
  The "https://getcomposer.org/version" file could not be downloaded: failed to open stream: Operation timed out

self-update [-r|--rollback] [--clean-backups] [--no-progress] [version]

~/Sites ❯ traceroute getcomposer.org                                                                                                                                             
traceroute to getcomposer.org (87.98.253.108), 64 hops max, 52 byte packets
 1  192.168.0.254 (192.168.0.254)  73.776 ms  4.845 ms  2.691 ms
 2  82.235.37.254 (82.235.37.254)  29.335 ms  30.154 ms  30.089 ms
 3  213.228.21.254 (213.228.21.254)  44.415 ms  31.478 ms  30.365 ms
 4  lyon-crs8-1-be1011.intf.routers.proxad.net (78.254.249.197)  30.951 ms  37.446 ms  31.714 ms
 5  lyon-crs8-2-be1000.routers.proxad.net (212.27.56.158)  33.641 ms  30.109 ms  31.966 ms
 6  p11-crs16-1-be1101.intf.routers.proxad.net (78.254.249.25)  40.764 ms  38.581 ms  40.266 ms
 7  cbv-9k-1-be1001.intf.routers.proxad.net (194.149.161.14)  44.218 ms  40.357 ms  35.714 ms
 8  * * *
 9  gsw-g1-a9.fr.eu (213.186.32.157)  37.311 ms  38.841 ms  37.516 ms
10  gra-g1-a9.fr.eu (37.187.36.217)  43.762 ms  39.753 ms
    gra-g1-a9.fr.eu (178.33.103.234)  41.361 ms
11  gra-3a-a9.fr.eu (37.187.231.86)  42.524 ms  43.650 ms  39.829 ms
12  getcomposer.org (87.98.253.108)  42.504 ms  41.005 ms  41.099 ms

~/Sites ❯ traceroute6 getcomposer.org
traceroute6 to getcomposer.org (2001:41d0:a:7b19::) from 2a01:e35:2eb2:57e0:4e7:f968:b2c:418e, 64 hops max, 12 byte packets
 1  2a01:e35:2eb2:57e0::1  1.813 ms  1.364 ms  1.036 ms
 2  2a01:e00:18::25  42.022 ms !N  48.733 ms  42.525 ms !N

Any other tests I could run? Btw, is it safe for me to give out this much info?

Many thanks for your help.

hisem commented Jun 18, 2015

Sorry, I don't have much network knowledge myself... my conclusion was probably way too hasty.

I ran some tests, though I'm not sure if they'll be useful to understand if this problem is only on my side or not. If it is, sorry for wasting your time!

With IPv4:

traceroute getcomposer.org                                                                                                                                             
traceroute to getcomposer.org (87.98.253.108), 64 hops max, 52 byte packets
 1  192.168.0.254 (192.168.0.254)  1.760 ms  1.193 ms  1.188 ms
 2  82.235.37.254 (82.235.37.254)  47.296 ms  34.924 ms  32.431 ms
 3  213.228.21.254 (213.228.21.254)  28.506 ms  31.776 ms  29.416 ms
 4  lyon-crs8-1-be1011.intf.routers.proxad.net (78.254.249.197)  32.788 ms  28.533 ms  32.435 ms
 5  lyon-crs8-2-be1000.routers.proxad.net (212.27.56.158)  44.724 ms  30.051 ms  37.999 ms
 6  p11-crs16-1-be1101.intf.routers.proxad.net (78.254.249.25)  43.217 ms  43.332 ms  45.068 ms
 7  cbv-9k-1-be1001.intf.routers.proxad.net (194.149.161.14)  38.813 ms  49.340 ms  39.542 ms
 8  * gsw-1-6k.fr.eu (213.186.32.169)  82.265 ms *
 9  gsw-g1-a9.fr.eu (213.186.32.157)  42.844 ms  37.096 ms  35.989 ms
10  gra-g1-a9.fr.eu (178.33.103.234)  42.681 ms
    gra-g1-a9.fr.eu (37.187.36.217)  43.689 ms  41.843 ms
11  gra-3a-a9.fr.eu (37.187.231.86)  42.745 ms  49.926 ms  48.635 ms
12  getcomposer.org (87.98.253.108)  39.995 ms  40.158 ms  40.391 ms
~/Sites ❯ php composer.phar self-update
Updating to version 75c501251dd0f161ffd488de8e966579785b6cb8.
    Downloading: 100%
Use composer self-update --rollback to return to version 9fb2d4f2d642a0749decb41bc2fe4be2bf8bef7a

Then I switched to IPv6:

~/Sites ❯ php composer.phar self-update

  [Composer\Downloader\TransportException]
  The "https://getcomposer.org/version" file could not be downloaded: failed to open stream: Operation timed out

self-update [-r|--rollback] [--clean-backups] [--no-progress] [version]

~/Sites ❯ traceroute getcomposer.org                                                                                                                                             
traceroute to getcomposer.org (87.98.253.108), 64 hops max, 52 byte packets
 1  192.168.0.254 (192.168.0.254)  73.776 ms  4.845 ms  2.691 ms
 2  82.235.37.254 (82.235.37.254)  29.335 ms  30.154 ms  30.089 ms
 3  213.228.21.254 (213.228.21.254)  44.415 ms  31.478 ms  30.365 ms
 4  lyon-crs8-1-be1011.intf.routers.proxad.net (78.254.249.197)  30.951 ms  37.446 ms  31.714 ms
 5  lyon-crs8-2-be1000.routers.proxad.net (212.27.56.158)  33.641 ms  30.109 ms  31.966 ms
 6  p11-crs16-1-be1101.intf.routers.proxad.net (78.254.249.25)  40.764 ms  38.581 ms  40.266 ms
 7  cbv-9k-1-be1001.intf.routers.proxad.net (194.149.161.14)  44.218 ms  40.357 ms  35.714 ms
 8  * * *
 9  gsw-g1-a9.fr.eu (213.186.32.157)  37.311 ms  38.841 ms  37.516 ms
10  gra-g1-a9.fr.eu (37.187.36.217)  43.762 ms  39.753 ms
    gra-g1-a9.fr.eu (178.33.103.234)  41.361 ms
11  gra-3a-a9.fr.eu (37.187.231.86)  42.524 ms  43.650 ms  39.829 ms
12  getcomposer.org (87.98.253.108)  42.504 ms  41.005 ms  41.099 ms

~/Sites ❯ traceroute6 getcomposer.org
traceroute6 to getcomposer.org (2001:41d0:a:7b19::) from 2a01:e35:2eb2:57e0:4e7:f968:b2c:418e, 64 hops max, 12 byte packets
 1  2a01:e35:2eb2:57e0::1  1.813 ms  1.364 ms  1.036 ms
 2  2a01:e00:18::25  42.022 ms !N  48.733 ms  42.525 ms !N

Any other tests I could run? Btw, is it safe for me to give out this much info?

Many thanks for your help.

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Jun 18, 2015

Member

Can you traceroute6 google.com for example? Just to see if there is a difference, that one you posted definitely seems broken.

Member

Seldaek commented Jun 18, 2015

Can you traceroute6 google.com for example? Just to see if there is a difference, that one you posted definitely seems broken.

@hisem

This comment has been minimized.

Show comment
Hide comment
@hisem

hisem Jun 19, 2015

Here's a traceroute6 to google.com :

traceroute6 google.com
traceroute6 to google.com (2a00:1450:400c:c00::65) from 2a01:e35:2eb2:57e0:6990:5337:a6d9:2391, 64 hops max, 12 byte packets
 1  2a01:e35:2eb2:57e0::1  1.076 ms  9.157 ms  3.468 ms
 2  2a01:e00:18::25  59.600 ms  38.136 ms  35.459 ms
 3  bzn-crs16-2-be2000.intf.routers.proxad.net  36.967 ms  53.036 ms  39.423 ms
 4  *
    2a01:e00:17:2::6  40.150 ms *
 5  2001:4860:1:1::3022:0:2  40.182 ms  39.163 ms  39.400 ms
 6  2001:4860::1:0:9f2  36.839 ms
    2001:4860::1:0:4a3a  40.170 ms
    2001:4860::1:0:9f2  36.424 ms
 7  2001:4860::8:0:5e18  36.250 ms  46.163 ms  38.741 ms
 8  2001:4860::8:0:507c  40.911 ms  41.273 ms  41.844 ms
 9  2001:4860::2:0:76e8  41.965 ms  46.431 ms  40.988 ms
10  * * *
11  wg-in-x65.1e100.net  60.137 ms  42.389 ms  42.044 ms

And one to facebook.com (btw it was interesting to see many big services don't seem to use ipv6, for example twitter, github, yahoo...) :

traceroute6 facebook.com
traceroute6 to facebook.com (2a03:2880:2130:cf05:face:b00c::1) from 2a01:e35:2eb2:57e0:6990:5337:a6d9:2391, 64 hops max, 12 byte packets
 1  2a01:e35:2eb2:57e0::1  1.116 ms  2.591 ms  4.236 ms
 2  2a01:e00:18::25  39.588 ms  40.386 ms  46.061 ms
 3  2a01:e00:18::e  41.025 ms  36.130 ms  38.736 ms
 4  ae8.pr01.cdg1.tfbnw.net  75.506 ms  45.709 ms  42.209 ms
 5  be2.bb01.cdg1.tfbnw.net  142.604 ms  136.878 ms  133.332 ms
 6  be14.bb02.dca1.tfbnw.net  133.311 ms  128.947 ms  129.228 ms
 7  ae33.bb04.frc3.tfbnw.net  129.588 ms  142.574 ms
    ae23.bb04.frc3.tfbnw.net  128.490 ms
 8  ae31.dr06.frc3.tfbnw.net  129.833 ms  129.952 ms
    ae32.dr06.frc3.tfbnw.net  127.898 ms
 9  po1019.csw12d.frc3.tfbnw.net  131.226 ms  129.277 ms  127.990 ms
10  * * *
11  edge-star6-shv-12-frc3.facebook.com  135.199 ms  132.138 ms  128.189 ms

Oh and I get the same kind of result on packagist.org as getcomposer.org :

traceroute6 packagist.org
traceroute6 to packagist.org (2001:41d0:a:7b19::) from 2a01:e35:2eb2:57e0:6990:5337:a6d9:2391, 64 hops max, 12 byte packets
 1  2a01:e35:2eb2:57e0::1  1.660 ms  2.258 ms  1.034 ms
 2  2a01:e00:18::25  35.884 ms  41.384 ms !N  59.435 ms !N

hisem commented Jun 19, 2015

Here's a traceroute6 to google.com :

traceroute6 google.com
traceroute6 to google.com (2a00:1450:400c:c00::65) from 2a01:e35:2eb2:57e0:6990:5337:a6d9:2391, 64 hops max, 12 byte packets
 1  2a01:e35:2eb2:57e0::1  1.076 ms  9.157 ms  3.468 ms
 2  2a01:e00:18::25  59.600 ms  38.136 ms  35.459 ms
 3  bzn-crs16-2-be2000.intf.routers.proxad.net  36.967 ms  53.036 ms  39.423 ms
 4  *
    2a01:e00:17:2::6  40.150 ms *
 5  2001:4860:1:1::3022:0:2  40.182 ms  39.163 ms  39.400 ms
 6  2001:4860::1:0:9f2  36.839 ms
    2001:4860::1:0:4a3a  40.170 ms
    2001:4860::1:0:9f2  36.424 ms
 7  2001:4860::8:0:5e18  36.250 ms  46.163 ms  38.741 ms
 8  2001:4860::8:0:507c  40.911 ms  41.273 ms  41.844 ms
 9  2001:4860::2:0:76e8  41.965 ms  46.431 ms  40.988 ms
10  * * *
11  wg-in-x65.1e100.net  60.137 ms  42.389 ms  42.044 ms

And one to facebook.com (btw it was interesting to see many big services don't seem to use ipv6, for example twitter, github, yahoo...) :

traceroute6 facebook.com
traceroute6 to facebook.com (2a03:2880:2130:cf05:face:b00c::1) from 2a01:e35:2eb2:57e0:6990:5337:a6d9:2391, 64 hops max, 12 byte packets
 1  2a01:e35:2eb2:57e0::1  1.116 ms  2.591 ms  4.236 ms
 2  2a01:e00:18::25  39.588 ms  40.386 ms  46.061 ms
 3  2a01:e00:18::e  41.025 ms  36.130 ms  38.736 ms
 4  ae8.pr01.cdg1.tfbnw.net  75.506 ms  45.709 ms  42.209 ms
 5  be2.bb01.cdg1.tfbnw.net  142.604 ms  136.878 ms  133.332 ms
 6  be14.bb02.dca1.tfbnw.net  133.311 ms  128.947 ms  129.228 ms
 7  ae33.bb04.frc3.tfbnw.net  129.588 ms  142.574 ms
    ae23.bb04.frc3.tfbnw.net  128.490 ms
 8  ae31.dr06.frc3.tfbnw.net  129.833 ms  129.952 ms
    ae32.dr06.frc3.tfbnw.net  127.898 ms
 9  po1019.csw12d.frc3.tfbnw.net  131.226 ms  129.277 ms  127.990 ms
10  * * *
11  edge-star6-shv-12-frc3.facebook.com  135.199 ms  132.138 ms  128.189 ms

Oh and I get the same kind of result on packagist.org as getcomposer.org :

traceroute6 packagist.org
traceroute6 to packagist.org (2001:41d0:a:7b19::) from 2a01:e35:2eb2:57e0:6990:5337:a6d9:2391, 64 hops max, 12 byte packets
 1  2a01:e35:2eb2:57e0::1  1.660 ms  2.258 ms  1.034 ms
 2  2a01:e00:18::25  35.884 ms  41.384 ms !N  59.435 ms !N
@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Jun 19, 2015

Member

Seems like the second hop is common to all of them so that must still be within your close network and likely where the routing hickup happens if it stops there for composer sites.

Interestingly I can ping and trace that 2nd hop from our server:

PING 2a01:e00:18::25(2a01:e00:18::25) 56 data bytes
64 bytes from 2a01:e00:18::25: icmp_seq=1 ttl=59 time=5.03 ms
64 bytes from 2a01:e00:18::25: icmp_seq=2 ttl=59 time=11.8 ms
64 bytes from 2a01:e00:18::25: icmp_seq=3 ttl=59 time=9.74 ms
64 bytes from 2a01:e00:18::25: icmp_seq=4 ttl=59 time=8.39 ms

traceroute to 2a01:e00:18::25 (2a01:e00:18::25) from 2001:41d0:a:7b19::, 30 hops max, 24 byte packets
 1  2001:41d0:a:7bff:ff:ff:ff:fe (2001:41d0:a:7bff:ff:ff:ff:fe)  0.742 ms  0.646 ms  0.555 ms
 2  pcc-2b-n7.fr.eu (2001:41d0::b9d)  0.793 ms  0.77 ms  1.807 ms
 3  gsw-g1-a9.fr.eu (2001:41d0::154)  5.141 ms  4.752 ms  4.648 ms
 4  * * *
 5  free.as12322.fr.eu (2001:41d0::542)  5.38 ms  5.148 ms  4.969 ms
 6  2a01:e00:18::25 (2a01:e00:18::25)  7.573 ms  8.362 ms  7.937 ms

I am not sure what this tells us, except maybe that you could ping free.fr about this problem to see if they can help.

Member

Seldaek commented Jun 19, 2015

Seems like the second hop is common to all of them so that must still be within your close network and likely where the routing hickup happens if it stops there for composer sites.

Interestingly I can ping and trace that 2nd hop from our server:

PING 2a01:e00:18::25(2a01:e00:18::25) 56 data bytes
64 bytes from 2a01:e00:18::25: icmp_seq=1 ttl=59 time=5.03 ms
64 bytes from 2a01:e00:18::25: icmp_seq=2 ttl=59 time=11.8 ms
64 bytes from 2a01:e00:18::25: icmp_seq=3 ttl=59 time=9.74 ms
64 bytes from 2a01:e00:18::25: icmp_seq=4 ttl=59 time=8.39 ms

traceroute to 2a01:e00:18::25 (2a01:e00:18::25) from 2001:41d0:a:7b19::, 30 hops max, 24 byte packets
 1  2001:41d0:a:7bff:ff:ff:ff:fe (2001:41d0:a:7bff:ff:ff:ff:fe)  0.742 ms  0.646 ms  0.555 ms
 2  pcc-2b-n7.fr.eu (2001:41d0::b9d)  0.793 ms  0.77 ms  1.807 ms
 3  gsw-g1-a9.fr.eu (2001:41d0::154)  5.141 ms  4.752 ms  4.648 ms
 4  * * *
 5  free.as12322.fr.eu (2001:41d0::542)  5.38 ms  5.148 ms  4.969 ms
 6  2a01:e00:18::25 (2a01:e00:18::25)  7.573 ms  8.362 ms  7.937 ms

I am not sure what this tells us, except maybe that you could ping free.fr about this problem to see if they can help.

@ip512

This comment has been minimized.

Show comment
Hide comment
@ip512

ip512 Jun 22, 2015

Hi, I have exactly the same kinds of problems, since at least one week. I get lot of timeouts when I composer update a project.
This is the result of traceroute :

traceroute6 packagist.org
traceroute to packagist.org (2001:41d0:a:7b19::) from 2a01:e35:2efa:2e80:1d55:c81c:ea19:8f31, 30 hops max, 24 byte packets
 1  2a01:e35:2efa:2e80::1 (2a01:e35:2efa:2e80::1)  0.688 ms  0.664 ms  0.645 ms
 2  2a01:e00:18::25 (2a01:e00:18::25)  48.014 ms !N  47.592 ms !N  48.262 ms !N

a ping6 packagist.org stucks but ping packagist.org works fine (~45ms).
My ISP is free too, so there is maybe something wrong with a router between them and packagist server...
With another ISP (Bouygtel) I have no issue.

ip512 commented Jun 22, 2015

Hi, I have exactly the same kinds of problems, since at least one week. I get lot of timeouts when I composer update a project.
This is the result of traceroute :

traceroute6 packagist.org
traceroute to packagist.org (2001:41d0:a:7b19::) from 2a01:e35:2efa:2e80:1d55:c81c:ea19:8f31, 30 hops max, 24 byte packets
 1  2a01:e35:2efa:2e80::1 (2a01:e35:2efa:2e80::1)  0.688 ms  0.664 ms  0.645 ms
 2  2a01:e00:18::25 (2a01:e00:18::25)  48.014 ms !N  47.592 ms !N  48.262 ms !N

a ping6 packagist.org stucks but ping packagist.org works fine (~45ms).
My ISP is free too, so there is maybe something wrong with a router between them and packagist server...
With another ISP (Bouygtel) I have no issue.

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Jun 22, 2015

Member

Maybe try to reach out to them? http://postmaster.free.fr/ lists an email at the very bottom, that's for email blacklists though but might get you closer to the network engineer team than calling on the phone, although you probably can try both, I don't know how they respond to that on the phone.

Member

Seldaek commented Jun 22, 2015

Maybe try to reach out to them? http://postmaster.free.fr/ lists an email at the very bottom, that's for email blacklists though but might get you closer to the network engineer team than calling on the phone, although you probably can try both, I don't know how they respond to that on the phone.

@andrerom

This comment has been minimized.

Show comment
Hide comment
@andrerom

andrerom Jun 22, 2015

Contributor

is travis-ci also routing traffic via Free.fr?

Contributor

andrerom commented Jun 22, 2015

is travis-ci also routing traffic via Free.fr?

@ip512

This comment has been minimized.

Show comment
Hide comment
@ip512

ip512 Jun 24, 2015

@Seldaek thank for the link. I sent an email, but have few hope to get an answer.
I sent a message to proxad.free.adsl.degroupage newsgroup, where I found someone that had trouble to access some site on Ubuntu. Probably same kind of issue.

ip512 commented Jun 24, 2015

@Seldaek thank for the link. I sent an email, but have few hope to get an answer.
I sent a message to proxad.free.adsl.degroupage newsgroup, where I found someone that had trouble to access some site on Ubuntu. Probably same kind of issue.

@LionsAd

This comment has been minimized.

Show comment
Hide comment
@LionsAd

LionsAd Jun 24, 2015

@Seldaek We also have very many problems with travis-ci and composer. Many many tests time out or take a looong time. I don't assume there is anything you can do on your end?

LionsAd commented Jun 24, 2015

@Seldaek We also have very many problems with travis-ci and composer. Many many tests time out or take a looong time. I don't assume there is anything you can do on your end?

@bamper

This comment has been minimized.

Show comment
Hide comment
@bamper

bamper Jun 28, 2015

@stevekessler for Ubuntu I made Composer work again this way:

sudo gedit /etc/gai.conf

And comment out:
#precedence ::ffff:0:0/96 100

This would prefer prefer IPv4 connections prior to IPv6.

bamper commented Jun 28, 2015

@stevekessler for Ubuntu I made Composer work again this way:

sudo gedit /etc/gai.conf

And comment out:
#precedence ::ffff:0:0/96 100

This would prefer prefer IPv4 connections prior to IPv6.

@phreditor

This comment has been minimized.

Show comment
Hide comment
@phreditor

phreditor Jun 28, 2015

I haven't been able to access anything from composer for hours today. Tried from several Composer ready computers. Now I wish I wasn't so dependent. : (

phreditor commented Jun 28, 2015

I haven't been able to access anything from composer for hours today. Tried from several Composer ready computers. Now I wish I wasn't so dependent. : (

@stevekessler

This comment has been minimized.

Show comment
Hide comment
@stevekessler

stevekessler commented Jun 29, 2015

Thanks @bamper

@h3r2on

This comment has been minimized.

Show comment
Hide comment
@h3r2on

h3r2on Jun 30, 2015

I also have this issue on OSX, traceroute6 and ping6 timeout to packagist.org.
I'm on AT&T in the US.
Disabled IPv6 and works like a charm.

h3r2on commented Jun 30, 2015

I also have this issue on OSX, traceroute6 and ping6 timeout to packagist.org.
I'm on AT&T in the US.
Disabled IPv6 and works like a charm.

@Seldaek

This comment has been minimized.

Show comment
Hide comment
@Seldaek

Seldaek Jul 1, 2015

Member

On affected systems (at least linux), it seems that running this command helps to make ipv4 traffic have a higher prio than ipv6, which is a better alternative than disabling ipv6 entirely:

sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"

On windows the only way is to disable ipv6 entirely I am afraid (either in windows or in your home router).

That said, if this fixes your problem, please talk to your ISP about it to try and resolve the routing errors. That's the best way to get things resolved for everyone.

Member

Seldaek commented Jul 1, 2015

On affected systems (at least linux), it seems that running this command helps to make ipv4 traffic have a higher prio than ipv6, which is a better alternative than disabling ipv6 entirely:

sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"

On windows the only way is to disable ipv6 entirely I am afraid (either in windows or in your home router).

That said, if this fixes your problem, please talk to your ISP about it to try and resolve the routing errors. That's the best way to get things resolved for everyone.

@Tuurlijk

This comment has been minimized.

Show comment
Hide comment
@Tuurlijk

Tuurlijk Oct 7, 2015

I have these issues since I installed OSx el Capitan, which favours ipv6 over ipv4.

Tuurlijk commented Oct 7, 2015

I have these issues since I installed OSx el Capitan, which favours ipv6 over ipv4.

@till

This comment has been minimized.

Show comment
Hide comment
@till

till Oct 7, 2015

Contributor

@Tuurlijk does disabling the device in network preferences help?

Contributor

till commented Oct 7, 2015

@Tuurlijk does disabling the device in network preferences help?

@Tuurlijk

This comment has been minimized.

Show comment
Hide comment
@Tuurlijk

Tuurlijk Oct 7, 2015

Disabling ipv6 fixes the issue. But is's ugly and hackish.

Tuurlijk commented Oct 7, 2015

Disabling ipv6 fixes the issue. But is's ugly and hackish.

@joltmode

This comment has been minimized.

Show comment
Hide comment
@joltmode

joltmode Oct 15, 2015

Guys, make sure your local configuration is IPv6 ready. I had the same issue, my VPS tech support told that it's a problem on my end and that I should alter my network configuration.

Altered it - works like a charm!

joltmode commented Oct 15, 2015

Guys, make sure your local configuration is IPv6 ready. I had the same issue, my VPS tech support told that it's a problem on my end and that I should alter my network configuration.

Altered it - works like a charm!

@francisbesset

This comment has been minimized.

Show comment
Hide comment
@francisbesset

francisbesset Oct 18, 2015

Contributor

Hello, I have same problem with IPv6 :(

With IPv4 I have no problem:

$ traceroute getcomposer.org 
traceroute to getcomposer.org (87.98.253.108), 64 hops max, 52 byte packets
 1  192.168.1.254 (192.168.1.254)  1.563 ms  0.771 ms  0.806 ms
 2  88.123.253.254 (88.123.253.254)  25.751 ms  26.122 ms  26.965 ms
 3  213.228.37.62 (213.228.37.62)  27.721 ms  25.896 ms  26.993 ms
 4  * mours-6k-1-v800.intf.routers.proxad.net (212.27.56.61)  26.685 ms  26.622 ms
 5  cbv-6k-2-v826.intf.routers.proxad.net (212.27.51.85)  27.829 ms  36.398 ms  28.529 ms
 6  bzn-crs16-2-be1009.intf.routers.proxad.net (194.149.161.9)  33.117 ms  33.041 ms  32.230 ms
 7  bzn-crs16-2-be1005.routers.proxad.net (78.254.249.77)  28.673 ms  27.313 ms  29.062 ms
 8  gsw-1-a9.fr.eu (213.186.32.169)  27.331 ms  29.081 ms  28.443 ms
 9  gra-g1-a9.fr.eu (94.23.122.84)  31.416 ms  32.379 ms  34.620 ms
10  gra-3a-a9.fr.eu (37.187.231.86)  35.211 ms  34.935 ms  33.689 ms
11  getcomposer.org (87.98.253.108)  31.669 ms  32.530 ms  33.151 ms

But with IPv6:

traceroute6 to getcomposer.org (2001:41d0:a:7b19::1) from 2a01:e35:87bf:d470:dcb:e565:88e4:c1fe, 64 hops max, 12 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *

Please fix this issue.

Contributor

francisbesset commented Oct 18, 2015

Hello, I have same problem with IPv6 :(

With IPv4 I have no problem:

$ traceroute getcomposer.org 
traceroute to getcomposer.org (87.98.253.108), 64 hops max, 52 byte packets
 1  192.168.1.254 (192.168.1.254)  1.563 ms  0.771 ms  0.806 ms
 2  88.123.253.254 (88.123.253.254)  25.751 ms  26.122 ms  26.965 ms
 3  213.228.37.62 (213.228.37.62)  27.721 ms  25.896 ms  26.993 ms
 4  * mours-6k-1-v800.intf.routers.proxad.net (212.27.56.61)  26.685 ms  26.622 ms
 5  cbv-6k-2-v826.intf.routers.proxad.net (212.27.51.85)  27.829 ms  36.398 ms  28.529 ms
 6  bzn-crs16-2-be1009.intf.routers.proxad.net (194.149.161.9)  33.117 ms  33.041 ms  32.230 ms
 7  bzn-crs16-2-be1005.routers.proxad.net (78.254.249.77)  28.673 ms  27.313 ms  29.062 ms
 8  gsw-1-a9.fr.eu (213.186.32.169)  27.331 ms  29.081 ms  28.443 ms
 9  gra-g1-a9.fr.eu (94.23.122.84)  31.416 ms  32.379 ms  34.620 ms
10  gra-3a-a9.fr.eu (37.187.231.86)  35.211 ms  34.935 ms  33.689 ms
11  getcomposer.org (87.98.253.108)  31.669 ms  32.530 ms  33.151 ms

But with IPv6:

traceroute6 to getcomposer.org (2001:41d0:a:7b19::1) from 2a01:e35:87bf:d470:dcb:e565:88e4:c1fe, 64 hops max, 12 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *

Please fix this issue.

@pilif

This comment has been minimized.

Show comment
Hide comment
@pilif

pilif Oct 19, 2015

this is not a composer issue. As multiple people here in this thread have shown: the composer ipv6 config is correct and the host is reachable. When it isn't for your machine, then this is a configuration issue of your machine or, more likely, your ISP.

Ask them to fix it.

Also: Don't disable IPv6 - have your hosting provider fix it for you - it's their job after all.

pilif commented Oct 19, 2015

this is not a composer issue. As multiple people here in this thread have shown: the composer ipv6 config is correct and the host is reachable. When it isn't for your machine, then this is a configuration issue of your machine or, more likely, your ISP.

Ask them to fix it.

Also: Don't disable IPv6 - have your hosting provider fix it for you - it's their job after all.

@till

This comment has been minimized.

Show comment
Hide comment
@till

till Oct 30, 2015

Contributor

You can test this locally or from a server by pointing a web browser at a website like: http://test-ipv6.com

Contributor

till commented Oct 30, 2015

You can test this locally or from a server by pointing a web browser at a website like: http://test-ipv6.com

@aerth

This comment has been minimized.

Show comment
Hide comment
@aerth

aerth commented Nov 2, 2015

Related: #4292 #4247 #4142

@aerth

This comment has been minimized.

Show comment
Hide comment
@aerth

aerth Nov 2, 2015

in my case it was firewall related, FIXED by copying a working copy of before6.rules to /etc/ufw/

aerth commented Nov 2, 2015

in my case it was firewall related, FIXED by copying a working copy of before6.rules to /etc/ufw/

@dexterns88

This comment has been minimized.

Show comment
Hide comment
@dexterns88

dexterns88 Nov 2, 2015

Same problem on debian server and fixed with:
sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"

https://getcomposer.org/doc/articles/troubleshooting.md
Degraded Mode#

dexterns88 commented Nov 2, 2015

Same problem on debian server and fixed with:
sudo sh -c "echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf"

https://getcomposer.org/doc/articles/troubleshooting.md
Degraded Mode#

@aerth

This comment has been minimized.

Show comment
Hide comment
@aerth

aerth Nov 3, 2015

Personally, I'd rather set IPv6 over IPv4, and just correctly configure IPv6. "default" VPS may just have IPv6 disabled for security (because most people aren't familiar with it quite yet). So if you have this problem try looking at your firewall logs before switching precedence. Worked for me!

aerth commented Nov 3, 2015

Personally, I'd rather set IPv6 over IPv4, and just correctly configure IPv6. "default" VPS may just have IPv6 disabled for security (because most people aren't familiar with it quite yet). So if you have this problem try looking at your firewall logs before switching precedence. Worked for me!

@rodx1977

This comment has been minimized.

Show comment
Hide comment
@rodx1977

rodx1977 Dec 30, 2015

I managed to solve the php composer.phar install connection timeout issue in my case working on a linux box . Though it is not the best workaround, maybe this will help others: I took the /etc/hosts file and typed this entry
87.98.253.214 packagist.org
then tried againg php composer.phar -v install
and it went smoothly.

rodx1977 commented Dec 30, 2015

I managed to solve the php composer.phar install connection timeout issue in my case working on a linux box . Though it is not the best workaround, maybe this will help others: I took the /etc/hosts file and typed this entry
87.98.253.214 packagist.org
then tried againg php composer.phar -v install
and it went smoothly.

@till

This comment has been minimized.

Show comment
Hide comment
@till

till Dec 31, 2015

Contributor

@rodx1977 you are just overriding DNS and not fixing anything but your ISP's broken DNS servers. I suggest you remove that entry again and instead use OpenDNS oder Google's DNS server instead (e.g. via DHCP or /etc/resolv.conf)

@naderman @Seldaek — can we close/lock this topic? ;)

Contributor

till commented Dec 31, 2015

@rodx1977 you are just overriding DNS and not fixing anything but your ISP's broken DNS servers. I suggest you remove that entry again and instead use OpenDNS oder Google's DNS server instead (e.g. via DHCP or /etc/resolv.conf)

@naderman @Seldaek — can we close/lock this topic? ;)

@naderman

This comment has been minimized.

Show comment
Hide comment
@naderman

naderman Jan 2, 2016

Member

Yeah will close this.

To anyone with IP configuration problems they would like to discuss, the best place is probably https://groups.google.com/forum/#!forum/composer-users

Member

naderman commented Jan 2, 2016

Yeah will close this.

To anyone with IP configuration problems they would like to discuss, the best place is probably https://groups.google.com/forum/#!forum/composer-users

@cgrossde

This comment has been minimized.

Show comment
Hide comment
@cgrossde

cgrossde Jan 26, 2016

Contributor

Please consider a config options to disable composers use of IPv6. It seems a lot of people don't have a working IPv6 setup and composer should not force them to fix their IPv6 setup (which can be time consuming or just impossible) but instead give them an alternative (IPv4). In my case we have local IPv6 but no working IPv6 uplink. This leads to a timeout and currently composer does not fallback to IPv4.

Workaround for Mac OS X:

Get name of your network device:

networksetup -listallnetworkservices

Disable IPv6 on that device (in my case "Wi-Fi")

networksetup -setv6off Wi-Fi

Do your composer thingy ....

You can enable IPv6 again with:

networksetup -setv6automatic Wi-Fi
Contributor

cgrossde commented Jan 26, 2016

Please consider a config options to disable composers use of IPv6. It seems a lot of people don't have a working IPv6 setup and composer should not force them to fix their IPv6 setup (which can be time consuming or just impossible) but instead give them an alternative (IPv4). In my case we have local IPv6 but no working IPv6 uplink. This leads to a timeout and currently composer does not fallback to IPv4.

Workaround for Mac OS X:

Get name of your network device:

networksetup -listallnetworkservices

Disable IPv6 on that device (in my case "Wi-Fi")

networksetup -setv6off Wi-Fi

Do your composer thingy ....

You can enable IPv6 again with:

networksetup -setv6automatic Wi-Fi
@naderman

This comment has been minimized.

Show comment
Hide comment
@naderman

naderman Jan 27, 2016

Member

@cgrossde documentation issue is here: #4748

Would be great if you could improve the documentation as proposed, and send a pull request.

No need to send a notification to everyone who posted in here everytime someone runs into IPv6 problems, so please stick to that issue.

Member

naderman commented Jan 27, 2016

@cgrossde documentation issue is here: #4748

Would be great if you could improve the documentation as proposed, and send a pull request.

No need to send a notification to everyone who posted in here everytime someone runs into IPv6 problems, so please stick to that issue.

@composer composer locked and limited conversation to collaborators Jan 27, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.