Versions 1.2.7-1.3.4 not working with system Tor, unless a torControlPassword is specified

[agb19]

Description

There seems to be a regression in version 1.2.7 that breaks the option to use existing Tor instead of builtin.

Version

Bisq 1.2.7 - FAILS
Bisq 1.2.5 - works

OS = Tails 4.3

Steps to reproduce

• boot up an instance of Tails 4.3 with admin password enabled
• download and install onion grater configuration (modified for this issue):
  wget https://gist.githubusercontent.com/agb19/549eb605937ccda4c12ba5f621505299/raw/c59ea445e1de8ec468590a2ce4dd5c4ac4c71e37/bisq-debug.yml
sudo cp -fa bisq-debug.yml /etc/onion-grater.d/
• download and install Bisq versions 1.2.5 and 1.2.7
  wget https://github.com/bisq-network/bisq/releases/download/v1.2.7/Bisq-64bit-1.2.7.deb https://github.com/bisq-network/bisq/releases/download/v1.2.5/Bisq-64bit-1.2.5.deb
sudo dpkg --install Bisq-64bit-1.2.5.deb
sudo mv -f /opt/Bisq /opt/Bisq-1.2.5
sudo dpkg --install Bisq-64bit-1.2.7.deb
sudo mv -f /opt/Bisq /opt/Bisq-1.2.7
• at this point, we can run the two different versions and compare the results:
  • /opt/Bisq-1.2.5/Bisq --logLevel=INFO --torControlPort=9051, or
  • /opt/Bisq-1.2.7/Bisq --logLevel=INFO --torControlPort=9051

Expected behaviour

Versions 1.2.5 as well as 1.2.7 should start up and operate as intended.

Actual behaviour

Version 1.2.5 starts up and runs OK.

Version 1.2.7 appears to time out connecting to system Tor.
tcpdump running on the loopback interface doesn't show any connection attempts to port 9051.

Logs

Feb-18 13:43:03.765 [JavaFX Application Thread] INFO  bisq.core.app.BisqSetup: onInitP2pNetwork 
Feb-18 13:43:03.812 [NetworkNode-9999] INFO  b.n.p2p.network.RunningTor: Connecting to running tor 
Feb-18 13:43:03.816 [JavaFX Application Thread] INFO  bisq.core.app.BisqSetup: walletInitialized=false, p2pNetWorkReady=false 
[... several lines concerning b.n.p.s.p.StoreService removed ...]
Feb-18 13:43:13.612 [readFromResourcesThread] INFO  bisq.core.app.SetupUtils: readFromResources took 27547 ms 
Feb-18 13:43:13.613 [JavaFX Application Thread] INFO  bisq.core.app.BisqSetup: onInitP2pNetwork 
Feb-18 13:43:13.613 [JavaFX Application Thread] INFO  bisq.core.app.BisqSetup: onInitP2pNetwork 
Feb-18 13:43:13.614 [JavaFX Application Thread] WARN  b.n.p2p.network.NetworkNode: Try to add a setupListener which was already added. 
Feb-18 13:43:13.625 [JavaFX Application Thread] INFO  bisq.core.app.BisqSetup: walletInitialized=false, p2pNetWorkReady=false 
Feb-18 13:43:13.626 [NetworkNode-9999] INFO  b.n.p2p.network.RunningTor: Connecting to running tor 
Feb-18 13:47:03.771 [JavaFX Application Thread] WARN  bisq.core.app.BisqSetup: startupTimeout called 
Feb-18 13:47:04.216 [JavaFX Application Thread] INFO  bisq.core.app.BisqSetup: Set log level for org.berndpruenster.netlayer classes to DEBUG to show more details for Tor network connection issues 

Device or machine

Tails 4.3 (Debian 10.3)

[ripcurlx]

@agb19 Actually we didn't change anything in the tor setup from v1.2.5 to v1.2.7. The only thing that changed that could be related to this is that we changed how the commandline arguments and config files are parsed. Maybe something went wrong there.

[ripcurlx]

Just had a look at the NetworkNodeProvider when using the --torControlPort argument and it is passed in the same way to the RunningTor class as with v1.2.5 (debugged it on Mainnet). So there might be a problem somewhere else. Do you also have the connection issue with v1.2.7 without having the argument set?

[agb19]

Hi ripcurlx, thanks for looking. Without the torControlPort argument, both 1.2.5 and 1.2.7 fail (because Tails prohibits Tor inside Tor), but they fail in identical ways so it's no problem on Bisq-side.
The only problem is when I try to use the system Tor via torControlPort.

---

I only had limited time, but I've made one more test to isolate the issue:
sudo strace -f -e trace=connect -u amnesia /opt/Bisq-1.2.5/Bisq --logLevel=INFO --torControlPort=9051

I did a little cleanup on the output and pulled the following relevant snippet (note that this is a successful run of 1.2.5, showing the "expected" behaviour"):

strace: Process 29362 attached
[pid 29362] connect(32, {sa_family=AF_INET, sin_port=htons(8333), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 29362] +++ exited with 0 +++
(...)
Feb-19 09:51:49.969 [JavaFX Application Thread] INFO  bisq.core.app.BisqSetup: onInitP2pNetwork 
Feb-19 09:51:49.970 [JavaFX Application Thread] INFO  bisq.core.app.BisqSetup: onInitP2pNetwork 
strace: Process 29365 attached
Feb-19 09:51:49.993 [NetworkNode-9999] INFO  b.n.p2p.network.RunningTor: Connecting to running tor 
Feb-19 09:51:50.003 [JavaFX Application Thread] INFO  bisq.core.app.BisqSetup: walletInitialized=false, p2pNetWorkReady=false 
[pid 29365] connect(32, {sa_family=AF_INET, sin_port=htons(9051), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
strace: Process 29367 attached
Feb-19 09:51:50.261 [NetworkNode-9999] INFO  b.n.p2p.network.RunningTor: 
################################################################
Connecting to Tor successful after 268 ms. Start publishing hidden service.
################################################################ 

There are two connect() calls, and from the context we understand that the first one is an attempt to probe for a Bitcoin node on the local machine port 8333, and the second one is the connection to Tor's control port (supplied via command-line as 9051). The software works correctly.

When I repeat the test with version 1.2.7, I see the first connect() call to port 8333, however after the message "Connecting to running tor" strace shows no connect() call - to port 9051 or any other. The timeout occurs 4 minutes later.

This is consistent with my observation from running tcpdump on loopback, and confirms that the issue is located within the Bisq app (not a firewall issue etc).

I hope this helps, and provides a portable test to reproduce the bug even on non-Tails Linuxes.

[brianddk]

I'm receiving similar failures with Bisq v1.3.4, on Tails v4.5, though I cannot reproduce the success of Bisq v1.2.5

Nevermind... found the fix at: https://bisq.wiki/Bisq_on_tails

[wiz]

@agb19 can you confirm this issue is resolved in v1.3.2 or later and close this bug if so? since Bisq now supports Tor v3 it should no longer be an issue

[agb19]

I have bad news and good news.
The bad news is that the issue originally introduced in 1.2.7 is still not fixed.
The really good news is that I just found a simple workaround for the problem, so simple in fact that I woldn't mind adopting it as standard procedure, as long as it's documented accordingly.

Per the original issue:
/opt/Bisq-1.2.7/Bisq --logLevel=INFO --torControlPort=9051 fails as described,
however:
/opt/Bisq-1.2.7/Bisq --logLevel=INFO --torControlPort=9051 --torControlPassword=. works well

So, by specifying a Tor control password even though one was not needed (remember we're using onion-grater which manages access control in a different way), Bisq started attempting to connect to the system Tor as intended.
However, without a password, the connection attempt does not occur.

Tested and confirmed for versions 1.2.7 and 1.3.4.

On this basis, I think this issue can be changed to lower severity. However, the failure condition still exists, is unexpected and with a non-obvious solution, so I believe some kind of fix is still necessary.

Changing title for clarity and leaving open for now.