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
Comments
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. |
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.
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.
+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. |
@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. |
@jmacxx Are you using the Qubes or non-Qubes variant of Whonix to test this? (The instructions vary slightly.) |
I used the non-Qubes variant with VirtualBox as the VM manager. |
@jmacxx Okay, so, on the Gateway VM, make sure you've run |
@JeremyRand That looks the same as what I followed. Just to be sure I ran them again and rebooted both Gateway and Workstation. (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. |
@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). |
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
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:
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.
The text was updated successfully, but these errors were encountered: