Cannot connect to local node from host but can from external

[ghost]

reopening #873

OS:
Debian 11

Can you explain this. Why is http://localhost:3030/status success and NEAR_ENV=local near state local.test fail

nw.mp4

[ghost]

But I can connect from external machine

wn.mp4

Please fix this bug

[ghost]

To reproduce

Please install Debian 11 Bullseye from fresh. Make sure lsb_release -a shows

No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 11 (bullseye)
Release:        11
Codename:       bullseye

Install Nodejs v17 and near API cli

Install Rust 1.56 (and maybe more system dependencies) and run local near-indexer 1.22

If it work show video

[ghost]

specifying --nodeUrl http://127.0.0.1:3030 works but not great

po.mp4

[volovyks]

@evergreen-trading-systems local.test is not a valid acc name. For standard local setup please use test.near.

[ghost]

That was a typo but it doesn't change anything because if it was working, it would say local.test does not exist instead ECONREFUSED. On local node I believe root account name is configurable.

[volovyks]

@nikurt since you are working a lot with local nodes, maybe you can suggest something here?

[nikurt]

Is the video in the description is taken on a Windows machine?
Crazy idea. Can it be that localhost is resolved to an ipv6 address but the node is only listening on ipv4 addresses?

[ghost]

Yes there are 2 machines, windows and debian. I can connect from windows to debian. Also from debian but using http://127.0.0.1:3030 not http://localhost:3030. I don't think so because curl http://localhost:3030/status works, it is near cli commands that are not working.

[nikurt]

Actually, my crazy idea seems to be correct.
In the original video, at 0:47, you can see that a connection refused comes from ::1:3030 which is indeed the ipv6 localhost.
Different systems resolve localhost using different methods.
Two possible solutions:

1. near-cli should connect to 127.0.0.1 rather than localhost
2. nodes should also listen on ipv6 addresses, such as :: in addition to 0.0.0.0.

[volovyks]

@evergreen-trading-systems
Please, try to override all config values that have localhost to IPv4 addresses. It's possible by changing this env variables:

near-cli/config.js

Line 48 in 6931906

case 'localnet':

[marcelo-gonzalez]

@evergreen-trading-systems I was able to reproduce your issue actually..

@volovyk-s I'm not sure exactly what's going on, but I think it has something to do with the use of node-fetch in near-api-js. I'm reproducing this by running docker run --rm -it --entrypoint /bin/bash --network host debian:bullseye and (after running apt install for a few things) running the command NEAR_ENV=local near state test.near. I get the same conn refused error, so I tried with the following saved to ./fetch.mjs from inside a near-api-js repo:

import fetch from 'node-fetch';
import http from 'http';
import https from 'https';

const httpAgent = new http.Agent({ keepAlive: true });
const httpsAgent = new https.Agent({ keepAlive: true });

function agent(_parsedURL) {
    if (_parsedURL.protocol === 'http:') {
        return httpAgent;
    } else {
        return httpsAgent;
    }
}

function fetch2(resource, init) {
    return fetch(resource, {
        agent: agent(new URL(resource.toString())),
        ...init,
    });
}

let json = null;

console.log(await fetch2("http://localhost:3030", {
    method: json ? 'POST' : 'GET',
    body: json ? json : undefined,
    headers: { 'Content-Type': 'application/json; charset=utf-8' }
}));

This is basically what is in https:/near/near-api-js/blob/master/src/utils/setup-node-fetch.ts and I get the same error, so there seems to be some problem with that.

[marcelo-gonzalez]

@volovyk-s I took another look at this, and I'm quite sure it's the same as this issue: nodejs/node#40702

The reproducer given in that issue seems to work on Debian 10 but fails on Debian 11, also the snippet in this comment gives an IPv4 addr on Debian 10 but an IPv6 one on Debian 11: require('dns').lookup('localhost', null, (e,a,f) => console.log(e,a,f))

In that case I think changing near-cli to use 127.0.0.1 instead of localhost would probably be the way to go.

[volovyks]

Thanks @marcelo-gonzalez ! Let's ask @evergreen-trading-systems to double-check if it will work. I'm afraid that localhost -> 127.0.0.1 can create more problems.
@evergreen-trading-systems please, try to use env variables to override RPC Url and tell us if it worked for you.
https:/near/near-cli/blob/master/config.js#L48

[treysis]

I'm afraid that localhost -> 127.0.0.1 can create more problems.

Could you elaborate why? Because actually changing localhost to 127.0.0.1 should be the way to go. Or even better make sure you're also listening on IPv6 as well. Alternatively you can downgrade NodeJS to v16 which is LTS version.

The reason why it's working with curl is that curl supports "Happy Eyeballs", i.e. it tries to connect to the IPv6 address, will failover and use the IPv4 address instead. Unfortunately, NodeJS doesn't support Happy Eyeballs. Either it succeeds on first try or it fails.

[nikurt]

Given that all IP addresses in the protocol are IPv4-only, such as node's rpc_addr and network peer addresses - it totally makes sense to me to have IPv4-only addresses in near-cli