Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unreachable local Bisq onion takes way too long to detect #6142

Closed
JeremyRand opened this issue Apr 11, 2022 · 8 comments · Fixed by #6147
Closed

Unreachable local Bisq onion takes way too long to detect #6142

JeremyRand opened this issue Apr 11, 2022 · 8 comments · Fixed by #6147

Comments

@JeremyRand
Copy link

Description

If the local Bisq P2P onion service is unreachable due to a firewall misconfiguration, it takes a week for Bisq to notify the user of this, while it should be trivially easy to detect immediately.

Version

Bisq v1.8.4

Steps to reproduce

  1. Install Bisq on Whonix as per the instructions on the Whonix wiki, but forget to configure the firewall on the Whonix-Workstation VM (thus, incoming onion connections from the Tor daemon to Bisq will be dropped).
  2. Create an open offer.

Expected behaviour

Bisq should immediately try to open a TCP connection to the local Bisq P2P onion service (routed through Tor), and when it finds that the connection is dropped, it should quickly convey this to the user.

Actual behaviour

Bisq waits 1 week before displaying the following error:

Important private notification!

You might need to clear your tor cache / restart your Bisq instance, as your 2 offers have not been reachable for at least a week.

To do that from the Bisq application menus:
Settings -> Network Info -> Open Tor Settings -> Delete Outdated Tor Files and Shutdown

That's a long delay to notify the user about a problem that can be detected instantly.

Screenshots

N/A; issue is in timing of graphical display, not the contents of the graphical display.

Device or machine

Haswell i7; Whonix 16 inside Qubes 4.1.

Additional info

N/A.

@ghost
Copy link

ghost commented Apr 11, 2022

Dear Jeremy. That was what we call a "love letter" from support. I sent it earlier today. Your onion is still rejecting incoming connections at the moment, FWIW.

Yes perhaps the Bisq software could automatically detect this. I'll take a look.

@JeremyRand
Copy link
Author

Dear Jeremy. That was what we call a "love letter" from support. I sent it earlier today.

Ah, I see. That explains the latency. :D Apologies for whatever hassle my misconfiguration caused for the support team, but at least it yielded a useful bug report I guess.

Your onion is still rejecting incoming connections at the moment, FWIW.

I opened the port on my firewall right before I filed this bug, and someone took one of my offers shortly afterward, so I think it's fixed -- but let's keep this issue focused on improving Bisq rather than my incompetence setting up firewalls.

Yes perhaps the Bisq software could automatically detect this. I'll take a look.

+1. Only important thing to be careful about is that the probe needs to be routed through Tor (to the onion), not routed directly to localhost, since firewalls will behave differently for each.

@ghost
Copy link

ghost commented Apr 12, 2022

@JeremyRand, I have written PR #6147 that does the self connect over Tor to test incoming connectivity. It succeeds with normal Bisq setups and complains when run on Whonix. I do not know how to configure Whonix to allow incoming Tor connections, spent quite some time with the documentation and opened up all the firewalls I could find, but without success.

In your particular example since your node is still unreachable, I posit the theory that your Bisq just happened to have an outgoing connection to a peer that took your offer. Bisq randomly connects to 8 or so peers to propagate P2P messaging the same way Bitcoin core does, and these connections change over time.

If you can provide any suggestion on how to configure Whonix, I would be glad to hear it. It looks like the Whonix Bisq guide may have overlooked this issue.

@JeremyRand
Copy link
Author

@jmacxx Are you using the Qubes or non-Qubes variant of Whonix to test this? (The instructions vary slightly.)

@ghost
Copy link

ghost commented Apr 12, 2022

I used the non-Qubes variant with VirtualBox as the VM manager.

@JeremyRand
Copy link
Author

JeremyRand commented Apr 13, 2022

@jmacxx Okay, so, on the Gateway VM, make sure you've run sudo onion-grater-add 40_bisq, and on the Workstation VM, make sure that /usr/local/etc/whonix_firewall.d/50_user.conf contains EXTERNAL_OPEN_ALL=true . You may need to restart both the Gateway and the Workstation to make them take effect. If you already did both of those and it still fails, let me know. (Also please post the exact command-line that you're using to run Bisq in the Workstation.)

@ghost
Copy link

ghost commented Apr 13, 2022

@JeremyRand That looks the same as what I followed. Just to be sure I ran them again and rebooted both Gateway and Workstation.
Cmd line = ./bisq-desktop --torControlPort=9051 --torControlPassword=notrequired --socks5ProxyBtcAddress=127.0.0.1:9050 --useTorForBtc=true --daoActivated=false

(daoActivated=false because I only have 8Gb RAM and was experiencing memory exhaustion with the overhead of the VM).

It still is not reachable from outside, just as your Bisq is not reachable.
If you'd like to check, here is a test offer I'm holding open:

image

image

@JeremyRand
Copy link
Author

JeremyRand commented Apr 13, 2022

@jmacxx I've just filed #6149 , which I'm 90% certain is the cause (I've debugged a similar issue in Ricochet before, so this was familiar territory for me).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant