Ask HN: Has T-mobile started blocking NPM? | Hacker News Reader

Ask HN: Has T-mobile started blocking NPM?

Getting EHOSTUNREACH over cell hotspot (and tether). Any T-mo subs out there care to switch to the hotspot, try 'npm -g outdated' or similar, and post results?

Edit: Correct errno code. Ubuntu 18.04; current and ~6-month old npm distros both fail.

View on HN

Just quickly tried running the command on T-mobile hotspot and also couldn't connect. I didn't try debugging much, so it could've been another issue, but just adding myself as a data point.

I tend to get bizarre and seemingly incorrect network errors randomly from various npm packages from time to time. Yarn does it too (sometimes worse). They will fail with a network error yet I can reach both the package repository and the package files themselves just fine using a browser, and the problem will persist for a while. It might be that.

That's indeed the case with my failures, persisting for two days now. I suspected filtering based on something in HTTP headers, but spoofing the User-Agent string with one copy-pasted from Firefox yielded no change. Command-line NPM has an option for the User-Agent spoof -- but not much otherwise, and I guess there's plenty of other metadata for T-mo to fingerprint on.

Worked for me. Turned on my T-Mobile hotspot in Santa Monica, CA, connected to it, and ran `npm -g outdated` as suggested. It ran successfully.

Seeing the failure in San Diego area, from Ubuntu 18.04. Happens with current npm stable distro, as well as one two major revs back.

Will enable tcpdump et al. Not a network specialist here -- suggestions for debug strategy/tools would be welcome.

Relevant lines from 'strace' output:

  [pid   678] 18:17:52 socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 18
  [pid   678] 18:17:52 setsockopt(18, SOL_TCP, TCP_NODELAY, [1], 4) = 0
  [pid   678] 18:17:52 connect(18, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("104.16.22.35")}, 16) = -1 EINPROGRESS (Operation now in progress)
  [pid   678] 18:17:52 epoll_ctl(13, EPOLL_CTL_ADD, 18, {EPOLLOUT, {u32=18, u64=18}}) = 0
  [pid   678] 18:17:52 epoll_wait(13, [{EPOLLOUT|EPOLLERR|EPOLLHUP, {u32=18, u64=18}}], 1024, 7523) = 1
  [pid   678] 18:17:52 getsockopt(18, SOL_SOCKET, SO_ERROR, [101], [4]) = 0
  [pid   678] 18:17:52 epoll_ctl(13, EPOLL_CTL_DEL, 18, 0x7ffcc1878020) = 0
  [pid   678] 18:17:52 close(18)          = 0
  ...
  [pid   678] 18:17:52 write(2, "npm", 3npm) = 3
  [pid   678] 18:17:52 write(2, " ", 1 )   = 1
  [pid   678] 18:17:52 write(2, "ERR!", 4ERR!) = 4
  [pid   678] 18:17:52 write(2, " ", 1 )   = 1
  [pid   678] 18:17:52 write(2, "code", 4code) = 4
  [pid   678] 18:17:52 write(2, " ENETUNREACH\n", 13 ENETUNREACH

) = 13

The failing call is the 'connect()'. It's asynchronous -- the following calls collect its failure status of ENETUNREACH.

I am able to download packages even now. Greater NYC

Hmmm, one possibility is local office bandwidth-throttling, specific to downloads running amok.

FWIW, on _German_ T-Mobile access to npmjs.com works just fine.

Could you try over VPN?

Good idea. Don't have one handy, but WireGuard might be in my future.

Reply on news.ycombinator.com