This is a follow-on to the issue discussed in this thread:
On slow/congested networks, Bisq never progresses past step 3/4 of the startup sequence, due to a timeout occurring in the initial connection to seed nodes.
One of the compulsory steps in the Bisq client startup sequence is a special handshake with a seed node, consisting in a two-way exchange of large data packets in the 1.5 MB size range (PreliminaryGetDataRequest in the debug log). On slow networks, specifically when the network output channel is degraded, this handshake fails systematically, resulting in an inability to start up (the “3/4” problem).
Bisq versions tested: 0.8.1, 0.9.3, 0.9.4, 0.9.5
Test platform: Tails 3.10, 3.11, 3.12 (Debian 9)
To reproduce the bug, use a working Bisq installation and limit the network output bandwidth to a small value (100 kbps in my example) using the Linux TBF qdisc.
Steps to reproduce:
- start with a correctly installed and tested operational copy of Bisq
- close the application
- in a terminal, execute (replace eth0 with name of default route interface):
sudo tc qdisc add dev eth0 root tbf rate 100kbit burst 1540 latency 50ms
- start the application as usual
Bisq should complete the startup sequence and operate (with some lag due to network bandwidth limitation).
Bisq never progresses past step 3/4 of startup sequence, resulting in complete no-op.
The 2 log file fragments in post 22 of the original thread illustrate well the “expected” vs “actual” scenarios.
Happy to assist with any debugging information, just let me know.