Skip to content
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

Network issues with node@17.2.0 #41145

Closed
EduApps-CDG opened this issue Dec 12, 2021 · 18 comments
Closed

Network issues with node@17.2.0 #41145

EduApps-CDG opened this issue Dec 12, 2021 · 18 comments

Comments

@EduApps-CDG
Copy link

EduApps-CDG commented Dec 12, 2021

Version

v17.2.0

Platform

Linux EduApps 5.11.0-41-generic #45-Ubuntu SMP Fri Nov 5 11:37:01 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

No response

What steps will reproduce the bug?

  • With node@17.2.0 installed, try executing:
$ DEBUG=* npm ping
  • With node@16.13.1 installed, execute:
$ DEBUG=* npm ping

How often does it reproduce? Is there a required condition?

I dont know.

What is the expected behavior?

The expected behavior is the same behavior from node@16.13.1.

What do you see instead?

npm won't ping registry.npmjs.org. It also affects npm installs and yarn installs.

Additional information

Additional information in npm/cli#4163

@Trott
Copy link
Member

Trott commented Dec 12, 2021

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.

@nodejs/npm 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.

Adding @aduh95 @richardlau for additional comments/context.

I'll also post this over in npm/cli#4163. (This issue can probably be closed.)

@Trott
Copy link
Member

Trott commented Dec 12, 2021

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.

@nodejs/npm 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.

Adding @aduh95 @richardlau for additional comments/context.

I'll also post this over in npm/cli#4163. (This issue can probably be closed.)

Ref: nodejs/build#2822

@Trott
Copy link
Member

Trott commented Dec 12, 2021

Oops, sorry for the ping, @aduh95. I thought it was you that made the change, but I see it wasn't.

Refs: #39987

@richardlau
Copy link
Member

AFAICT npm ping attempts to contact https://registry.npmjs.org and that has valid IPv4 and IPv6 addresses:

test-rackspace-fedora32-x64-1 tmp]# curl -v -6 https://registry.npmjs.org
*   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/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (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 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 0x5625e943aa40)
> GET / HTTP/2
> Host: registry.npmjs.org
> user-agent: curl/7.69.1
> accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 200 
< date: Sun, 12 Dec 2021 16:26:21 GMT
< content-type: application/json
< cf-ray: 6bc8505a39f06a5d-SYD
< 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":2560340,"doc_del_count":334,"update_seq":12067689,"purge_seq":0,"compact_running":false,"sizes":{"active":48427611093,"external":148952122296,"file":48636428083},"disk_size":48636428083,"data_size":48427611093,"other":{"data_size":148952122296},"instance_start_time":"1639039381935941","disk_format_version":7,"committed_update_seq":12067688,"compacted_seq":12060579,"uuid":"3a4ad341a4111dd254daa731f37b37ae"}
[root@test-rackspace-fedora32-x64-1 tmp]#
[root@test-rackspace-fedora32-x64-1 tmp]# curl -v -4 https://registry.npmjs.org
*   Trying 104.16.21.35:443...
* Connected to registry.npmjs.org (104.16.21.35) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (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 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 0x561e10166a40)
> GET / HTTP/2
> Host: registry.npmjs.org
> user-agent: curl/7.69.1
> accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
< HTTP/2 200 
< date: Sun, 12 Dec 2021 16:26:27 GMT
< content-type: application/json
< cf-ray: 6bc8507e8d8062ea-SYD
< 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":2560339,"doc_del_count":334,"update_seq":12069382,"purge_seq":0,"compact_running":false,"sizes":{"active":48427503774,"external":148951973639,"file":48636997872},"disk_size":48636997872,"data_size":48427503774,"other":{"data_size":148951973639},"instance_start_time":"1639199685143077","disk_format_version":7,"committed_update_seq":12069382,"compacted_seq":12062278,"uuid":"964c127ddcbbd59982db296a0f9e8a56"}
[root@test-rackspace-fedora32-x64-1 tmp]# 

It's entirely possible though that there is something local that is preventing IPv6 addresses being reachable. If you want the old default behaviour, where Node.js reordered addresses so it would prefer IPv4 addresses (starting with Node.js 17 the default is whatever order the operating system returns the IP adresses in), run Node.js with --dns-result-order=ipv4first, e.g. for npm try NODE_OPTIONS=--dns-result-order=ipv4first npm ping.

@EduApps-CDG
Copy link
Author

EduApps-CDG commented Dec 12, 2021

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 it helps, I'm over CGNAT. I have private IPv6 but IPv4 is shared over the entire ISP. But the future will be only IPv6 🤔

@EduApps-CDG
Copy link
Author

It's entirely possible though that there is something local that is preventing IPv6 addresses being reachable.

Impossible, I already hosted IPv6-only websites with no-ip. Now I'm in a mobile internet, but soon I'll show you the tests 👍

@EduApps-CDG
Copy link
Author

okay, here is the results:
google test:
image

npm registry:
image

the only one ipv6 website that doesn't works is npmjs

@EduApps-CDG
Copy link
Author

after some time running, here is the output
image

@EduApps-CDG
Copy link
Author

EduApps-CDG commented Dec 13, 2021

@richardlau I noticed your npm registry's IPv6 are different from mine.
Your's from USA
Mine from Brazil.
(Copied the wrong IPv6, sorry)

So it looks like Brazil's DNS record are messed up (what a shame).
What should I do?

@richardlau
Copy link
Member

@EduApps-CDG Sorry, I have no idea -- have you tried the --dns-result-order option. FWIW I think those IPv6 addresses belong to Cloudflare, which npm are presumably using.

@EduApps-CDG
Copy link
Author

image
@richardlau here it is, but still not going

@Trott
Copy link
Member

Trott commented Dec 13, 2021

Based on npm/cli#4163, it seems like this is believed to be an issue with the npm registry, so I'm going to optimistically close this. However, if it turns out I'm wrong, or if you'd just prefer this stay open until the issue is resolved even if it's not believed to be in Node.js, please comment or re-open the issue (if the GitHub interface provides you with a Reopen button). Thanks!

@Trott Trott closed this as completed Dec 13, 2021
@richardlau
Copy link
Member

image @richardlau here it is, but still not going

@EduApps-CDG --dns-result-order is a Node.js option, not an npm option, so you'd have to specify it either as:

NODE_OPTIONS=--dns-result-order=ipv4first npm ping

(as I mentioned previously in #41145 (comment)) or

export NODE_OPTIONS=--dns-result-order=ipv4first
npm ping

@EduApps-CDG
Copy link
Author

image @richardlau here it is, but still not going

@EduApps-CDG --dns-result-order is a Node.js option, not an npm option, so you'd have to specify it either as:

NODE_OPTIONS=--dns-result-order=ipv4first npm ping

(as I mentioned previously in #41145 (comment)) or

export NODE_OPTIONS=--dns-result-order=ipv4first
npm ping

Yeah, it's working. But that means I'll have to use these flags everytime?

@richardlau
Copy link
Member

Yeah, it's working. But that means I'll have to use these flags everytime?

Yes, at least until whatever is blocking you from accessing the npm registry via IPv6 is resolved.

@EduApps-CDG
Copy link
Author

Okay, thanks for the help!

@EduApps-CDG
Copy link
Author

EduApps-CDG commented Jan 10, 2022

Just an update:
Today I changed my ISP, they forget to setup IPv6, but after, I did a "post-setup" to work with IPv6 and now even npm and P2P are working. Thanks for your help!

@antoniopresto
Copy link

For someone searching, Starlink (at least in Brazil) is causing this issue too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants