Cannot connect to tunneled proxy: Cannot connect to server #14

unclamped · 2022-12-27T03:05:23Z

Hey, I'm trying to run 2b2w with my free ngrok.io token, and I can see an URL being displayed in the console output and Discord spam webhook, but when I try to connect to it, it just doesn't look as if a server actually existed, giving the error "Cannot connect to server". Judging by the output, there are no visible errors, and the proxy is connected to 2b2t, so that's odd.
On a side note, would it be possible to create a Discord or Matrix or anything server for easier and faster troubleshooting and discussion? Thanks :)

Enchoseon · 2022-12-27T06:27:45Z

Not sure what the problem could be, but you could try these checks to start:

Check that the full tunnel addres is being copied correctly with the port number (e.g. 0.tcp.ngrok.io:12345)
If you are running the proxy from a release (e.g. v1.0.3, v1.0.4)...
- ... upgrade to the latest stable release (at the time of writing that is v1.0.4)
Or, if you are running the proxy from the main branch...
- ... make sure that 2based2wait was installed with npm ci and not npm install
- ... or switch to a stable release

Some additional checks:

Check if your machine is displayed on the Ngrok dashboard while 2based2wait is running.
- If so, then the Ngrok tunnel is alive and valid.
Check if TCP connections to ngrok.io are being blocked by your firewall
- If so, then you'll have to cut out an exception for TCP connections to ngrok.io
Check if anything shows up in ./log/errors

Offsetpanda701 · 2022-12-27T11:28:27Z

i had the same problem! when im not using my VPN. when I turn on VPN this problem no longer problem and I can join to the server.

unclamped · 2022-12-27T17:39:25Z

Not sure what the problem could be, but you could try these checks to start:

1. Check that the full tunnel address is being copied correctly with the port number (e.g. `0.tcp.ngrok.io:12345`)

2. If you are running the proxy from a release (e.g. v1.0.3, v1.0.4)...
   
   * ... upgrade to the latest stable release (at the time of writing that is v1.0.4)

3. Or, if you are running the proxy from the main branch...
   
   * ... make sure that 2based2wait was installed with `npm ci` and not `npm install`
   * ... or switch to a stable release

Some additional checks:

* Check if your machine is displayed on the Ngrok dashboard while 2based2wait is running.
  
  * If so, then the Ngrok tunnel is alive and valid.

* Check if your firewall is blocking TCP connections to ngrok.io
  
  * If so, then you'll have to cut out an exception for TCP connections to ngrok.io

* Check if anything shows up in `./log/errors`

Yes, the full address is being used.
I am currently running the main branch.
2.1. I am using pnpm instead of npm, but it should, by default, already use the --frozen-lockfile option which is the equivalent to ci in npm. I included it in case, nothing has changed.
2.2. After trying to use the latest stable release, my Minecraft client got stuck on "Pinging" after adding the server, and after returning to the console output I now see the following:

/home/ducky/sta/2based2wait-1.0.4/node_modules/.pnpm/[email protected]/node_modules/prismarine-item/index.js:51
      if (registry.supportFeature('itemSerializationAllowsPresent')) {
                   ^

TypeError: registry.supportFeature is not a function
    at toNotch (/home/ducky/sta/2based2wait-1.0.4/node_modules/.pnpm/[email protected]/node_modules/prismarine-item/index.js:51:20)
    at /home/ducky/sta/2based2wait-1.0.4/node_modules/.pnpm/@[email protected]/node_modules/@rob9315/mcproxy/lib/packets.js:93:58
    at Array.map (<anonymous>)
    at generatePackets (/home/ducky/sta/2based2wait-1.0.4/node_modules/.pnpm/@[email protected]/node_modules/@rob9315/mcproxy/lib/packets.js:93:44)
    at Conn.generatePackets (/home/ducky/sta/2based2wait-1.0.4/node_modules/.pnpm/@[email protected]/node_modules/@rob9315/mcproxy/lib/conn.js:71:47)
    at Conn.sendPackets (/home/ducky/sta/2based2wait-1.0.4/node_modules/.pnpm/@[email protected]/node_modules/@rob9315/mcproxy/lib/conn.js:67:14)
    at createBridge (/home/ducky/sta/2based2wait-1.0.4/proxy.js:306:9)
    at Server.<anonymous> (/home/ducky/sta/2based2wait-1.0.4/proxy.js:236:4)
    at Server.emit (node:events:513:28)
    at loginClient (/home/ducky/sta/2based2wait-1.0.4/node_modules/.pnpm/[email protected]/node_modules/minecraft-protocol/src/server/login.js:207:12)

Node.js v18.12.1
 ELIFECYCLE  Command failed with exit code 1.

I can see my connection in the ngrok dashboard correctly.
My firewall is okay, I never had any trouble with other services which require TCP communication.
There aren't any relevant logs, neither in the stable release nor in the main branch.

Little side note, prismarine-chat is not included in the package.json file, and if not manually installed, the program immediately complains about the missing dependency and crashes.

Enchoseon · 2022-12-28T08:11:00Z

Thanks for pointing out the missing prismarine-chat dependency.

I totally forgot, that damned registry.supportFeature crash has plagued v1.0.4 thanks to unlocked dependencies that make the proxy totally unusable on random machines (see #1). Looks like I'll just have to bite the bullet and make a new release as a hotfix.

In summary:

Scratch using v1.0.4, it has a glaring issue that I forgot about. Please switch back to using the main branch for now.
- Making a new actually-stable stable release is a high priority.
I'll add the missing prismarine-chat dependency
Still unsure what the underlying issue could be.

Are you able to connect to the proxy normally (through localhost or ip) with Ngrok disabled in your config.json? (Ngrok must be disabled, or the port won't be accessible)

These networking problems are very hard for me to replicate, so any information about the environment you're running the proxy on could be helpful (e.g. distro, firewall daemon, docker/virtualbox, etc.)

unclamped · 2022-12-28T18:13:51Z

Looking at issue #1 it seems like my environment is pretty similar. The proxy is being hosted in my Raspberry Pi 4 with Debian/Raspi OS, and I'm connecting to the proxy from an Arch Linux machine.

The issue persists, even after disabling ngrok and trying to access my proxy locally from 192.168.0.171:25565 (the former being my proxy IP, pretty obvious but just in case) I still get a "Can't connect to server" error, and when I try to join it I get a connection refused error

From my Raspi, running the command # lsof -i:25565 outputs the following:

COMMAND   PID  USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
node    24210 ducky   21u  IPv4 9658897      0t0  TCP 192.168.0.171:36120->31.25.11.238:25565 (ESTABLISHED)
node    24210 ducky   23u  IPv4 9658893      0t0  TCP raspi:25565 (LISTEN)

The former seems to be the connection to 2b2t and the latter to connect to the proxy, so it doesn't seem to be a firewall issue (if it was, I'd probably not even be able to connect via ssh in the first place lmao)
As for information about my environment, my host is a Raspberry Pi model 4 B rev 1.2, with 4 GBs of RAM, running Raspberry Pi OS (Debian 11 bullseye) of 32 bits with kernel 5.15.76 in Armv7l. As for the firewall, I believe that Raspberry Pi OS uses iptables by default, and it's been like that since I installed it. I haven't containerized 2b2w in any way, it's running as a normal process and I'm executing it with pnpm (https://pnpm.io), which I don't think should be an issue. I think that's all I can think of that could be useful, if you know any other info I could give you lmk.

unclamped · 2023-01-11T04:23:13Z

Hey, any updates on this?

Enchoseon · 2023-01-11T06:08:46Z

Hey, I'm very grateful for your detailed bug report and sorry I haven't had time to work on this even though I really want to. Here's all the information I have so far in the meantime:

When you enable Ngrok in 2based2wait, it literally just runs the Ngrok binary in the background as a child process (src).
- So if you're able to connect to the proxy when running the Ngrok binary yourself, then this is likely a problem originating from the Ngrok wrapper I'm using. If not, then it could be a bug in the proprietary Ngrok binary, which would be a worst-case scenario.
The wrapper downloads the ngrok binary for your platform from the official CDN on install (source)
- According to the documentation, you can use the NGROK_ARCH environment variable to force a specific platform (e.g. env NGROK_ARCH=linuxia32), though I haven't tried this myself.

unclamped · 2023-01-17T15:57:38Z

Hey, I'm very grateful for your detailed bug report and sorry I haven't had time to work on this even though I really want to. Here's all the information I have so far in the meantime:

* When you enable Ngrok in 2based2wait, it literally just runs the Ngrok binary in the background as a child process ([src](https://github.com/bubenshchykov/ngrok/blob/d2f70ff4776e14ca2e00ae4eb7651ba14a274b5c/src/process.js#L49)).
  
  * So if you're able to connect to the proxy when running the Ngrok binary _yourself_, then this is likely a problem originating from the [Ngrok wrapper](https://github.com/bubenshchykov/ngrok) I'm using. If not, then it could be a bug in the proprietary Ngrok binary, which would be a worst-case scenario.

* The wrapper downloads the ngrok binary for your platform from the official CDN on install ([source](https://github.com/bubenshchykov/ngrok/blob/92f1fe6c3f391966510d3605cda2802287f775c0/download.js))
  
  * According to the documentation, you can use the `NGROK_ARCH` environment variable to force a specific platform (e.g. `env NGROK_ARCH=linuxia32`), though I haven't tried this myself.

The issue doesn't seem to be about ngrok, since I can't connect to the server with ngrok disabled either

Enchoseon · 2023-01-17T22:31:35Z

Hmm, based on what Offset said about a VPN, this may be caused by differences in Ipv4 and Ipv6 loopback addresses. We previously came across and attempted to address the problem with #11, but I've added a new config option to set the loopback address yourself with proxy.loopbackAddress in the latest commit.

You can clone the main branch again and try the different loopback addresses to see if any of them work (localhost, 127.0.0.1, 0.0.0.0, ::1).

unclamped · 2023-01-22T01:37:34Z

Hmm, based on what Offset said about a VPN, this may be caused by differences in Ipv4 and Ipv6 loopback addresses. We previously came across and attempted to address the problem with #11, but I've added a new config option to set the loopback address yourself with proxy.loopbackAddress in the latest commit.

You can clone the main branch again and try the different loopback addresses to see if any of them work (localhost, 127.0.0.1, 0.0.0.0, ::1).

I'm glad to say that setting the loopback address to 0.0.0.0 fixes the issue, and that now I can successfully connect to the proxy server without any issues. Nice :)
We should see if this is also the fix for other people running their proxy on Linux, hopefully, to get more info on whether or not this is a user-specific issue or something related to all of Linux.
How much would change if the default address was set to 0.0.0.0 instead of localhost?

unclamped · 2023-01-22T02:00:05Z

Hold on, I just realized I was testing this without ngrok enabled. Enabling ngrok again still returns a "Can't connect to server" error. Whoops

unclamped · 2023-02-05T04:37:07Z

After several attempts with Encho in Discord DMs trying to figure this out (for the sake of not filling this issue with unnecessary info), we found out that loopback addresses are hell. Sometimes they work, sometimes they don't. In my case, localhost didn't work when I first tried it, not even for local connections, but now it works perfectly fine even with an ngrok tunnel. So, the main issue is already fixed, setting the address to localhost works.
We found some other issues as well, some fixed, others still unresolved, although they are out of scope for this issue and should have their own issue number for convenience and cleanness.

unclamped closed this as completed Feb 5, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Cannot connect to tunneled proxy: Cannot connect to server #14

Cannot connect to tunneled proxy: Cannot connect to server #14

unclamped commented Dec 27, 2022

Enchoseon commented Dec 27, 2022

Offsetpanda701 commented Dec 27, 2022

unclamped commented Dec 27, 2022

Enchoseon commented Dec 28, 2022

unclamped commented Dec 28, 2022

unclamped commented Jan 11, 2023

Enchoseon commented Jan 11, 2023

unclamped commented Jan 17, 2023

Enchoseon commented Jan 17, 2023

unclamped commented Jan 22, 2023

unclamped commented Jan 22, 2023

unclamped commented Feb 5, 2023

Cannot connect to tunneled proxy: Cannot connect to server #14

Cannot connect to tunneled proxy: Cannot connect to server #14

Comments

unclamped commented Dec 27, 2022

Enchoseon commented Dec 27, 2022

Offsetpanda701 commented Dec 27, 2022

unclamped commented Dec 27, 2022

Enchoseon commented Dec 28, 2022

unclamped commented Dec 28, 2022

unclamped commented Jan 11, 2023

Enchoseon commented Jan 11, 2023

unclamped commented Jan 17, 2023

Enchoseon commented Jan 17, 2023

unclamped commented Jan 22, 2023

unclamped commented Jan 22, 2023

unclamped commented Feb 5, 2023