[BUG] Fix IPv6 records for npm #4163
Comments
EduApps-CDG
added
Bug
|
I'm not in a proxy and websocket connections are okay in web browsers |
EduApps-CDG
changed the title
|
|
|
deleted |
|
Everything fine on a Google Colab machine (outdated versions). But I still have the issue can someone help me? I can't figure out why it works on 7.18 and not in 8.X. Reinstalled npm, same problem (this happens with yarn too) |
Important Update:Installed latest LTS version of |
|
I see that registry.npmjs.com is advertising IPv6 addresses in DNS. I'm guessing that they are only serving over IPv4 and the problem you are seeing is due to a breaking change in Node.js 17.0.0's dns module. If I'm right about this, the thing to do would be to either enable the registry to serve over IPv6 or else do not advertise the DNS records over IPv6. |
|
|
Oops, sorry for the ping, @aduh95. I thought it was you that made the change, but I see it wasn't. Refs: nodejs/node#39987 |
|
I'm back, It looks like there is something wrong with npm registry domain: |
EduApps-CDG
changed the title
|
After running some tests at nodejs/node#41145, I think the problem now is npm registry's ipv6 record. |
EduApps-CDG
changed the title
|
Hey @EduApps-CDG! I work on the npm registry team and just had a look at this. It seems like your DNS resolves to 2606:4700::6810:1223 which is valid entry in our DNS record. It appears however, that somehow, you're not able to connect to that IP address. When I manually pin my local |
|
That's the thing, I can reach every other IPv6 website including google:
*[eduardo]:**~/proj/DescicloBot/ai**$* curl -v6 https://google.com
* Trying 2800:3f0:4001:820::200e:443...
* Connected to google.com (2800:3f0:4001:820::200e) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.google.com
* start date: Nov 8 02:25:05 2021 GMT
* expire date: Jan 31 02:25:04 2022 GMT
* subjectAltName: host "google.com" matched cert's "google.com"
* issuer: C=US; O=Google Trust Services LLC; CN=GTS CA 1C3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x56276de5c5a0)
GET / HTTP/2
Host: google.com
user-agent: curl/7.74.0
accept: */*
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 301
< location: https://www.google.com/
< content-type: text/html; charset=UTF-8
< date: Tue, 14 Dec 2021 03:00:47 GMT
< expires: Thu, 13 Jan 2022 03:00:47 GMT
< cache-control: public, max-age=2592000
< server: gws
< content-length: 220
< x-xss-protection: 0
< x-frame-options: SAMEORIGIN
< alt-svc: h3=":443"; ma=2592000,h3-29=":443";
ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443";
ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000;
v="46,43"
<
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>
* Connection #0 to host google.com left intact.
Em seg., 13 de dez. de 2021 às 20:38, Lukas Spieß ***@***.***>
escreveu:
… Hey @EduApps-CDG <https://github.com/EduApps-CDG>! I work on the npm
registry team and just had a look at this. It seems like your DNS resolves
to 2606:4700::6810:1223 which is valid entry in our DNS record.
It appears however, that somehow, you're not able to connect to that IP
address. When I manually pin my local curl to resolve to this IP address
however, it does work without problems. This leads me to believe that this
is a local routing problem, either with your ISP or some part of their
backbone infrastructure.
❯ curl -v -6 https://registry.npmjs.org --resolve registry.npmjs.org:443:2606:4700::6810:1323
* Added registry.npmjs.org:443:2606:4700::6810:1323 to DNS cache
* Hostname registry.npmjs.org was found in DNS cache
* Trying 2606:4700::6810:1323:443...
* Connected to registry.npmjs.org (2606:4700::6810:1323) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-ECDSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=sni.cloudflaressl.com
* start date: Aug 18 00:00:00 2021 GMT
* expire date: Aug 17 23:59:59 2022 GMT
* subjectAltName: host "registry.npmjs.org" matched cert's "*.npmjs.org"
* issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x15500ca00)
> GET / HTTP/2
> Host: registry.npmjs.org
> user-agent: curl/7.77.0
> accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 200
< date: Mon, 13 Dec 2021 23:33:21 GMT
< content-type: application/json
< cf-ray: 6bd2ff38fd406931-FRA
< cache-control: must-revalidate
< strict-transport-security: max-age=2592000000; includeSubDomains; preload;
< vary: Accept-Encoding
< cf-cache-status: DYNAMIC
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
<
* Connection #0 to host registry.npmjs.org left intact
{"db_name":"registry","engine":"couch_bt_engine","doc_count":2562809,"doc_del_count":334,"update_seq":12122919,"purge_seq":0,"compact_running":false,"sizes":{"active":68374523314,"external":152661465294,"file":69647919115},"disk_size":69647919115,"data_size":68374523314,"other":{"data_size":152661465294},"instance_start_time":"1639385342006465","disk_format_version":7,"committed_update_seq":12122918,"compacted_seq":12078594,"uuid":"964c127ddcbbd59982db296a0f9e8a56"}%
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4163 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHY5WGRMPH7PUBRZHGWMEZLUQZ7XHANCNFSM5J2YP3VQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
By the way, If that's the issue, how can I check if it's true? |
|
I asked for people in my country to see if they have the same problem: |
Using a different network/a different ISP for example can help narrow this down. If you can tether through your phone and that supports IPv6 as well, it might yield different results. |
This unfortunately does not tell us anything, visiting an IP address directly in the browser will not work due to SSL reasons but your screenshot seems to suggest that the other user is at the very least able to connect to the IP address, even if it results in an (expected) certificate mismatch. We have also run a RIPE measurement that does not show any systemic issues connecting to npm from Brazil: https://atlas.ripe.net/measurements/34456285/ |
|
As I think we're confident that there is no issue with npm's DNS records, I'm going to close this issue. |
|
hay guys I had the same issue just when i run docker, if any one find the solution pls let me know |
|
@lumaxis upgrading to the latest npm, I am definitely broken. npm is attempting to connect to the registry over ipv6 and the connection is getting a ECONNREFUSED error. $ dig aaaa registry.npmjs.org
-- snip --
registry.npmjs.org. 265 IN AAAA 2606:4700::6810:1223
-- snip --
$ env 'DEBUG=*' npm -d -d ping
npm info using npm@8.3.0
npm info using node@v17.3.1
npm timing npm:load:whichnode Completed in 1ms
npm timing config:load:defaults Completed in 1ms
npm timing config:load:file:/usr/local/lib/node_modules/npm/npmrc Completed in 1ms
npm timing config:load:builtin Completed in 1ms
npm timing config:load:cli Completed in 3ms
npm timing config:load:env Completed in 0ms
npm timing config:load:file:/src/qix-/umbrel-auth/.npmrc Completed in 3ms
npm timing config:load:project Completed in 4ms
npm timing config:load:file:/home/anonymous/.npmrc Completed in 1ms
npm timing config:load:user Completed in 1ms
npm timing config:load:file:/usr/local/etc/npmrc Completed in 0ms
npm timing config:load:global Completed in 0ms
npm timing config:load:validate Completed in 1ms
npm timing config:load:credentials Completed in 1ms
npm timing config:load:setEnvs Completed in 1ms
npm timing config:load Completed in 13ms
npm timing npm:load:configload Completed in 13ms
npm timing npm:load:setTitle Completed in 0ms
npm timing config:load:flatten Completed in 2ms
npm timing npm:load:display Completed in 9ms
npm timing npm:load:logFile Completed in 5ms
npm timing npm:load:timers Completed in 0ms
npm timing npm:load:configScope Completed in 0ms
npm timing npm:load Completed in 30ms
npm notice PING http://registry.npmjs.org/
agentkeepalive sock[0#registry.npmjs.org:80:] create, timeout 300001ms +0ms
agentkeepalive sock[0#registry.npmjs.org:80:](requests: 1, finished: 0) error: Error: connect ECONNREFUSED 2606:4700::6810:1223:80
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1157:16) {
errno: -111,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '2606:4700::6810:1223',
port: 80
}, listenerCount: 2 +21s
agentkeepalive sock[0#registry.npmjs.org:80:](requests: 1, finished: 0) close, isError: true +2msForcing node to list ipv4 first fixes this, but this is an issue of You can work around this if you're facing this issue: node --dns-result-order=ipv4first "$(which npm)"
# or simply
alias npm="node --dns-result-order=ipv4first $(which npm)"For example: $ env 'DEBUG=*' node --dns-result-order=ipv4first "$(which npm)" -d -d ping
npm info using npm@8.3.0
npm info using node@v17.3.1
npm timing npm:load:whichnode Completed in 0ms
npm timing config:load:defaults Completed in 1ms
npm timing config:load:file:/usr/local/lib/node_modules/npm/npmrc Completed in 1ms
npm timing config:load:builtin Completed in 1ms
npm timing config:load:cli Completed in 3ms
npm timing config:load:env Completed in 0ms
npm timing config:load:file:/src/qix-/umbrel-auth/.npmrc Completed in 3ms
npm timing config:load:project Completed in 4ms
npm timing config:load:file:/home/anonymous/.npmrc Completed in 1ms
npm timing config:load:user Completed in 1ms
npm timing config:load:file:/usr/local/etc/npmrc Completed in 0ms
npm timing config:load:global Completed in 0ms
npm timing config:load:validate Completed in 1ms
npm timing config:load:credentials Completed in 1ms
npm timing config:load:setEnvs Completed in 0ms
npm timing config:load Completed in 13ms
npm timing npm:load:configload Completed in 13ms
npm timing npm:load:setTitle Completed in 0ms
npm timing config:load:flatten Completed in 2ms
npm timing npm:load:display Completed in 10ms
npm timing npm:load:logFile Completed in 5ms
npm timing npm:load:timers Completed in 0ms
npm timing npm:load:configScope Completed in 0ms
npm timing npm:load Completed in 31ms
npm notice PING http://registry.npmjs.org/
agentkeepalive sock[0#registry.npmjs.org:80:] create, timeout 300001ms +0ms
agentkeepalive sock[0#registry.npmjs.org:80:](requests: 1, finished: 1) free +88ms
agentkeepalive sock[0#registry.npmjs.org:443::::::::true:::::::::::::] create, timeout 300001ms +64ms
agentkeepalive sock[0#registry.npmjs.org:443::::::::true:::::::::::::](requests: 1, finished: 1) free +313ms
npm notice PONG 487ms
npm timing command:ping Completed in 487ms
npm timing npm Completed in 647ms
npm info okPlease re-open this issue. |
|
@Qix- The DNS record is definitely valid and this IP address is correct and does belong to npmjs.org. It seems like your ISP or somewhere in between has issues routing to our IP address, please reach out to them to fix this issue. As you can see on https://atlas.ripe.net/measurements/34781715/#probes, the vast majority of providers can reach the IP address without issues. |
I'm not arguing that.
Kind of strange that Telekom, Europe's biggest ISP, isn't routing to your servers correctly. Note that Either way, there is no way to configure npm to force ipv4 resolution, and thus my local ecosystem is entirely broken. I realize this is a Node thing, but there is no permanent workaround. There is nothing I, as a user, can do to fix npm in a way that works with scripts and the rest of the ecosystem ( The only viable workaround is to manually manhandle the NPM has four options here:
Either way, the combination of node/npm moving to ipv6 first has broken people in ways they cannot just simply fix, besides perhaps completely disabling IPv6 on their systems - which helps absolutely nobody and works against the IPv6 adoption efforts clearly in motion. "Contact your ISP" is not valid support advice, sorry. |
Wouldn't be the craziest thing I've seen them do but it does seem unusual. There's of course other hops in between that could be the culprit. Have you tried to see what e.g. the output of a
I can't speak to the latter two options but I can connect to Even though it is weird that Have you by any chance also double checked whether one of the various npm config files that are loaded might be overriding the registry address and if that could be interfering with your connection? |
|
@treysis not sure what happened, but the issue is gone: This is through my router's Wifi. With P.S. We had a strong storm in our region -> causing electricity to disappear a couple of times -> causing the router to be restarted a couple of times. Maybe there is a relation :D |
|
Maybe, who knows :) Glad it got sorted out and hopefully you learned some things. |
absolutely the best advice ive found all night. immediately solved. still a little curious why logging in as root and running the same thing worked thanks a bunch tho |
|
@dhenson02 IPv6 isn't broken in WSL. Works out of the box. In WSL2 it's a bit difficult to set up, though. However, it shoudn't return IPv6 address first if there is no valid route. I think it's a different problem. Would be worth checking, actually. |
|
I'm in Ubuntu. Also I was talking about having a different route chosen based on my user login. Doesn't seem relevant to networking. |
|
Shouldn't have relevance, yes. So yeah, seems weird. |
|
This finally resolved this issue for me after many hours. 🙏 |
|
This may sound silly, but I hope it saves someone else from googling an hour to solve this issue (like I did...). I had the exact same |
|
I first disabled ipv6 via sysctl on the interface used, then applied It works now. However, this can't be the solution. It's not cool that I have to change my local os-level configuration just because node can't handle ipv6 correctly. Now, if I understand right, this is not an npm issue but a node one. Since I found the (temporary) solution here though, I respectfully ask here where I should report this. Because it surely looks like a bug to me. And wherever it actually is, I want to report it. |
|
I'm so glad I found this issue because I have been experiencing this for a few days now. Here's the gist of it Versions earlier to lts/hydrogen do not seem to have this problem.
The only way I can update npm or install packages is through activating a VPN on my laptop Go figure... |
from: #4163 (comment) |
|
@markojak Yep I had to do exactly this as well, thanks for your comment. On NodeJS version 18.16.0 my terminal would constantly hang on sill idealtree buildDeps and never proceed from there. I ran a traceroute and this is what I got back: C:\WINDOWS\system32>tracert registry.npmjs.org Tracing route to registry.npmjs.org [2606:4700::6810:1123] 1 1 ms <1 ms <1 ms 2603-8080-8700-b2fe-0000-0000-0000-0001.res6.spectrum.com [2603:8080:8700:b2fe::1] Trace complete. C:\WINDOWS\system32> After seeing your comment I downgraded to 16.20 LTS and now everything is working just fine again. Seems to be some sort of IPv6 issue since Node version prior to 17 give precedence to IPv4 instead of IPv6. Until things get sorted out I guess I'm stuck on v16 for the time being. |
|
Yeah this is a major problem for me and it started a few days ago, Eventually I tracked the problem down to ipv6 being enabled on my Router Since npm does not have a configuration flag to enable ipv4 only I decided to disable ipv6 entirely on my network. This has "fixed" things I can categorically say that Node 18 onwards does not work with some ISP IPv6 configurations. Since it would be near impossible to debug this with an ISP I would think the fix should be applied on Nodejs side / npm configuration |
|
As this is a routing problem on ISP side, it definitely should be fixed by the ISP. A normal ISP should look into routing-related problems if made aware by its clients. |
|
@lumaxis any chance you can shed more light on the above? I've only ever had issues with this recently (and it seems several others are in that boat). Re: your comment above about trying different networks, I can resolve the domain from phone's connection via a tether but not through my ISP. I've tried 3 different DNS providers and none can resolve when I try |
|
I don't work on the npm team directly anymore but in general, possible issues with IPv6 can be manifold. All objective measurements indicate that this is not widespread issue with npm's DNS records or published routes. From what I've read in earlier comments here, this is most likely not a DNS issue but rather a problem with a user's IPv6 setup or the routing with the ISP. You can also reach out to https://www.npmjs.com/support for help with a specific issue or try your ISP's tech support if everything looks good on e.g. https://ipv6-test.com. |
|
I agree entirely @lumaxis but if the issue is widespread enough it might make sense to just built in IPv6 AND IPv4 Routing into "npm doctor" or "npm ping" so that when a user is debugging they can immediately understand where their issues is. This would be my design suggestion for the npm team. |
|
@markojak That sounds like a reasonable idea to me and would probably be useful 👍🏼 |
|
Also I might be misunderstanding, but is there a reason there isn't some sort of fallback to ipv4 if ipv6 fails? |
|
I posted it. Feel free to add comments and upvote on the issue @SpencerKaiser Yeah I agree it would be nice for a fallback but failing that even just enhanced debugging will be very helpful Also there are literally ZERO online resources to help with this. The thing is that it's easy to assume that npm is making an IPv4 connection so you don't know to check "curl -6" and then when you run curl you get an appropriate response so then it's a "wtf" kinda situation |
Yes, because Happy Eyeballs isn't really available by default in Node as of now. Node v19 makes a huge step forward by giving a global configuration option. This will hopefully be available from Node v20, but I haven't checked the current progress. |
@markojak same.............. I literally opened a PR against
SAME. There are an absurd amount of threads all over the place but NONE are helpful. The only other thread I found that had anything meaningful was this one and specifically this comment that helped me realize the issue was ipv6.
Just made another corepack PR to address this; hopefully the same can be done here. |
Is there an existing issue for this?
This issue exists in the latest npm version
Current Behavior
I'm trying to install
naturalpackage, but npm freezes insill idealTree buildDeps(Not the same behavior as #3257, so I suppose it's another bug). After some minutes it returnsETIMEDOUT.Expected Behavior
npm should install the package (it's also unable to update npm itself).
Steps To Reproduce
npm i [any package]Environment
7.19.1(OK),8.0.0(Not OK),8.1.4(Not OK),8.3.0(Not OK)17.0.1,17.2.0(npm8.1.4)The text was updated successfully, but these errors were encountered: