No connection to backend: Gateway Timeout - ECONNREFUSED

[SpartanBit]

Hi all, I have followed the JAM installation guide for Raspibolt described here:
https://raspibolt.org/guide/bonus/bitcoin/Jam.html

however the webui on the local network shows the following message: No connection to backend: Gateway Timeout.
This seems a very similar issue, but on Raspiblitz: #88

If I have a look at the logs, every time I try to reach JAM I get the following:

Error occurred while proxying request 192.168.1.18:4020 to undefined [ECONNREFUSED] (https://nodejs.org/api/errors.html#errors_common_system_errors)
Error occurred while proxying request 192.168.1.18:4020/api/v1/session to https://localhost:28183/ [ECONNREFUSED] (https://nodejs.org/api/errors.html#errors_common_system_errors)
Error occurred while proxying request 192.168.1.18:4020/api/v1/wallet/all to https://localhost:28183/ [ECONNREFUSED] (https://nodejs.org/api/errors.html#errors_common_system_errors)

Not sure what's causing it, but i tried to get to the root cause of this, and the only thing I've found is that some of the other guides do specify in the .env file not only the port but also the host/server at 127.0.0.1:...
see https://raspibolt.org/guide/bonus/lightning/thunderhub.html#configuration or https://raspibolt.org/guide/bitcoin/blockchain-explorer.html#configuration

Could that be the cause behind this problem, and if so, how can i resolve it?

I would be truly grateful if someone could help.
Thanks!

[theborakompanioni]

Hey @SpartanBit, sorry for the late reply. Still figuring out what might be the problem.
It seems the JM API is refusing connections, so it might be that the daemon is not running in the first place?

It can be that JM creates a config file at first startup and subsequently exits. Have you tried restarting jmwalletd, e.g. with sudo systemctl restart jmwalletd?

jmwalletd listens on port 28183 by default.
After restarting, can you try to request data from the JM API directly?
e.g.

curl "https://localhost:28183/api/v1/session" --show-error --insecure

Sorry for shooting in the dark.

[SpartanBit]

Thanks for your feedback @theborakompanioni
I waited a bit to reply as I wanted to test the new version and see if that fixed it, but nothing changed :(

Also tried your curl request before and after updating to the version 1.5, but obtained the same output, not sure if that could help:

{"session": false, "maker_running": false, "coinjoin_in_process": false, "schedule": null, "wallet_name": "None", "offer_list": null, "nickname": null}

At this point the only conclusion I can think is that it's more likely to be an issue related to Raspibolt or the Raspibolt guide.

I wanted to thinker with either the .env file or the src/setupProxy.js and point it manually to 127.0.0.1 instead of localhost, but I'm not sure if that could cause any problem.

I'm making this observation solely on the comparison with some other Raspibolt guides linked previously, that seems to specify 127.0.0.1 instead of localhost (perhaps in some cases Raspibolt can't always resolve localhost??? - I remember having some problem with it in the past, although not sure if related)

You think that could work? I'm out of ideas, so any input is much appreciated.

[ghost]

I was getting the same errors while attempting to setup joinmarket + jam on freebsd. I solved it by replacing all occurrences of "localhost" to "127.0.0.1" in src/setupProxy.js".

[SpartanBit]

Thank you @bektar yea I was planning on doing that as well, but not sure of the security implication of doing so (silly point ik, but better be safe than sorry). Might try it anyway just to see if that's the underlying issue for me as well.

[theborakompanioni]

Hey, thanks @bektar and @SpartanBit . It seems this can be addressed here, see #611 for a fix. Might be included in the upcoming version and should do away with any manual adaptions on the user side.

Regarding security considerations, if anything, it should actually be safer now (localhost can theoretically resolve to remote machines, instead of the local one).

Thank you for bringing it up 🧡

The issue remains open till it is confirmed to work on your side.

[theborakompanioni]

@SpartanBit Would you be able to try adapting the nginx config according to raspibolt/raspibolt#1235 (comment) ?
After that, reloading nginx with sudo systemctl reload nginx. Reporting back if that solved the issue would be awesome! 🧡

[SpartanBit]

Hey @theborakompanioni
Haven't had much time to play around this issue but just recently tested out your feedback.
Here's a brief recap:

• manually changing the setupProxy.js file did work as expected, I can now interact and use Jam on the local network at 192.168... :4020 but I can't reach the Tor domain (not sure if related to this but likely is)

• then reverted to the default setupProxy.js with localhost and changed setting to listen [::]:4020 ssl as you advised, which made Jam on localhost unreachable but the ECONNREFUSED error did not reappear, not sure why.

• while at it I reverted to the manually modified setupProxy.js that previously worked but kept the listen [::]:4020 and to my surprise, JAM was again unreachable locally and log again clean.

p.s. after each step i did make sure to reload both nginx and jam

So your advice did solve the apparent problem, but for unknown reason JAM is still unreachable

As for the Tor issue, the very first time I installed JAM i was able to interact with the .onion link, although I was still facing the no connection to backend error. After the first reinstall, I've not been able to connect to it (Error: The connection was reset) ever again, but again not sure why.

[jambolo]

Hey @SpartanBit, sorry for the late reply. Still figuring out what might be the problem. It seems the JM API is refusing connections, so it might be that the daemon is not running in the first place?

I had the same problem (ECONNREFUSED). My problem was configuring jmwalletd. I mistakenly put the ssl directory in joinmarket and not .joinmarket.

[dutu]

It looks that localhost resolves to IPv6 address and the applications are only listening on IPv4. The issue can be solved by forwarding IPv6 requests on ports 28183, 28283 and 62601 to 127.0.0.1 (IPv4)

Here is the tested solution, which uses nginx to forward the ports:

• Create a config file:

 sudo nano /etc/nginx/conf.d/jam-ipv6to4-forwarding.conf

• Copy the configuration below to the file:

# JoinMarket API daemon: HTTPS, Port 28183
server {
    listen [::]:28183 ssl ipv6only=on; # Listen on IPv6 port 28183 with SSL

    # Add the correct paths to your certificate and key files
    ssl_certificate /home/joinmarket/.joinmarket/ssl/cert.pem;
    ssl_certificate_key /home/joinmarket/.joinmarket/ssl/key.pem;

    location / {
        proxy_pass https://127.0.0.1:28183; # Forward requests to IPv4 address and port with SSL
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# JoinMarket WebSocket: HTTPS, Port 28283
server {
    listen [::]:28283 ssl ipv6only=on; # Listen on IPv6 port 28283 with SSL

    # Add the correct paths to your certificate and key files
    ssl_certificate /home/joinmarket/.joinmarket/ssl/cert.pem;
    ssl_certificate_key /home/joinmarket/.joinmarket/ssl/key.pem;

    location / {
        proxy_pass https://127.0.0.1:28283; # Forward requests to IPv4 address and port with SSL
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

# JoinMarket Orderbook Watcher daemon: HTTP, Port 62601
server {
    listen [::]:62601 ipv6only=on; # Listen on IPv6 port 62601

    location / {
        proxy_pass http://127.0.0.1:62601; # Forward requests to IPv4 address and port
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

• Test and reload the configuration

sudo nginx -t
sudo nginx -s reload

[dutu]

@SpartanBit for ECONNREFUSED, see fix above that forwards IPv6 ports to IPv4.

As for your Tor issue, there is a problem in the RaspiBolt Jam guide were Tor is setup:

# Hidden Service Jam
HiddenServiceDir /var/lib/tor/hidden_service_jam/
HiddenServiceVersion 3
HiddenServicePort 80 127.0.0.1:4020

Jam is listening on SSL port (4020), hence Tor should listen on and forward port 443 rather than 80:

HiddenServicePort 443 127.0.0.1:4020

I've done PR: [UPDATE BONUS GUIDE] JoinMarket webui (Jam) v0.1.5, which is waiting for review.

[SpartanBit]

Thanks.

@jambolo I double checked it, and it's in the right directory, so likely not the underlying problem

@dutu changing the port to 443 worked! Jam is now reachable on TOR. Much appreciated!
In the following days I'll test your forwarding solution.

It looks that localhost resolves to IPv6 address

Mhhh, out of curiosity, do you know what could be the cause of this?

[dutu]

@SpartanBit, I'm glad Tor is working now.

Generally, it is possible for one application to resolve "localhost" to IPv4 and another to IPv6 on the same system. The actual behavior depends on the application and the underlying system libraries it uses, as well as the system's address resolution preferences.

In general, when an application resolves "localhost," it queries the system's DNS resolver, which then checks the /etc/hosts file and other system-specific configurations to determine the IP addresses associated with "localhost." The system might return both IPv4 and IPv6 addresses for "localhost" depending on the configuration.

However, applications and libraries might have different preferences when selecting which IP version to use. For example, some applications might prefer IPv6 over IPv4 when both are available, while others might prefer IPv4. This preference could be hard-coded in the application or configurable by the user.