
Ask HN: Has T-mobile started blocking NPM? - everybodyknows
Getting EHOSTUNREACH over cell hotspot (and tether).  Any T-mo subs out there care to switch to the hotspot, try &#x27;npm -g outdated&#x27; or similar, and post results?<p>Edit: Correct errno code.  Ubuntu 18.04; current and ~6-month old npm distros both fail.
======
nyc640
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.

------
sli
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.

~~~
everybodyknows
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.

------
a1pulley
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.

~~~
everybodyknows
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.

~~~
everybodyknows
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.

------
avi_avi
I am able to download packages even now. Greater NYC

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

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

------
Hnrobert42
Could you try over VPN?

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

