sparrowwallet
SOCKS proxy replies with general failure
Tor is installed, enabled, running, and has active circuits up, on 127.0.0.1:9050. I am actively using this system tor to connect to different services just fine. It is up and working:
#netstat -tunlap
tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN 2312598/tor
On Debian x86_64, in Sparrow 1.6.5 (deb from website), I go to File -> Preferences -> Server -> Private Electrum Under URL I enter my electrumserverreallylonghostname.onion and its port 50001
If I enable "Use proxy" and enter my tor socks proxy (127.0.0.1:9050), and click "Test connection" I get the following error message:
Connecting to tcp://electrumserverreallylonghostname.onion:50001...
Starting Tor
Jul 25 10:47:18.262 [notice] Tor 0.4.3.6 (git-30711296fd5b7f51) running on Linux with Libevent 2.1.11-stable, OpenSSL 1.1.1g, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Jul 25 10:47:18.262 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 25 10:47:18.262 [notice] Read configuration file "/tmp/tor8036162468937850980/torrc".
Jul 25 10:47:18.264 [notice] Opening Control listener on 127.0.0.1:0
Jul 25 10:47:18.264 [notice] Control listener listening on port 36563.
Jul 25 10:47:18.264 [notice] Opened Control listener on 127.0.0.1:36563
Jul 25 10:47:18.264 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
------------------
Could not connect:
Error reply: Unable to set option: Failed to bind one of the listener ports.
Is a Tor proxy already running on port 9050?
Yes one is. That's the point of using the "Use Proxy" option, is it not?
If I turn off "Use Proxy", this happens:
Connecting to tcp://electrumserverreallylonghostname.onion:50001...
Starting Tor
Jul 25 10:16:37.536 [notice] Tor 0.4.3.6 (git-30711296fd5b7f51) running on Linux with Libevent 2.1.11-stable, OpenSSL 1.1.1g, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Jul 25 10:16:37.536 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 25 10:16:37.536 [notice] Read configuration file "/tmp/tor939583139834442911/torrc".
Jul 25 10:16:37.538 [notice] Opening Control listener on 127.0.0.1:0
Jul 25 10:16:37.538 [notice] Control listener listening on port 37467.
Jul 25 10:16:37.538 [notice] Opened Control listener on 127.0.0.1:37467
Jul 25 10:16:37.538 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
Starting Tor
Jul 25 10:16:38.243 [notice] Tor 0.4.3.6 (git-30711296fd5b7f51) running on Linux with Libevent 2.1.11-stable, OpenSSL 1.1.1g, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Jul 25 10:16:38.243 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 25 10:16:38.243 [notice] Read configuration file "/tmp/tor15317891499259481748/torrc".
Jul 25 10:16:38.245 [notice] Opening Control listener on 127.0.0.1:0
Jul 25 10:16:38.245 [notice] Control listener listening on port 32941.
Jul 25 10:16:38.245 [notice] Opened Control listener on 127.0.0.1:32941
Jul 25 10:16:38.245 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
Stopping Tor
Tor is already running, using external instance...
Starting Tor...
------------------
Could not connect:
SOCKS server general failure. Check if the proxy server is running.
On another occasion with the same settings ("Use Proxy" disabled, but the system tor is up & running):
Connecting to tcp://electrumserverreallylonghostname.onion:50001...
CircuitStatus: 95 LAUNCHED
CircuitStatus: 85 CLOSED $96070698714DC07AE2B377864625B7EF64E33BF5~upsuperRelay2,$6600C560E7E2A7601F6F4B019942C9E4D47872CE~stimorol,$C4CE54BF7CF355433FF6E9D80240070F65B6B96E~ForPrivacyNET
CircuitStatus: 95 EXTENDED $509EAB4C5D10C9A9A24B4EA0CE402C047A2D64E6~toralf2
CircuitStatus: 95 EXTENDED $509EAB4C5D10C9A9A24B4EA0CE402C047A2D64E6~toralf2,$30EDD1504D77FA155B3FF0F49CA787E0F24AA865~agir6yah7Bahxolooqu
Starting Tor
Jul 25 10:49:01.832 [notice] Tor 0.4.3.6 (git-30711296fd5b7f51) running on Linux with Libevent 2.1.11-stable, OpenSSL 1.1.1g, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Jul 25 10:49:01.832 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 25 10:49:01.832 [notice] Read configuration file "/tmp/tor12873972795965718421/torrc".
Jul 25 10:49:01.834 [notice] Opening Control listener on 127.0.0.1:0
Jul 25 10:49:01.834 [notice] Control listener listening on port 33973.
Jul 25 10:49:01.834 [notice] Opened Control listener on 127.0.0.1:33973
Jul 25 10:49:01.834 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
CircuitStatus: 95 EXTENDED $509EAB4C5D10C9A9A24B4EA0CE402C047A2D64E6~toralf2,$30EDD1504D77FA155B3FF0F49CA787E0F24AA865~agir6yah7Bahxolooqu,$C92DE921C34ACB1C1B4EA7D2C1ECF4A0ACD2CA00~FileDitchExit2
CircuitStatus: 95 BUILT $509EAB4C5D10C9A9A24B4EA0CE402C047A2D64E6~toralf2,$30EDD1504D77FA155B3FF0F49CA787E0F24AA865~agir6yah7Bahxolooqu,$C92DE921C34ACB1C1B4EA7D2C1ECF4A0ACD2CA00~FileDitchExit2
------------------
Could not connect:
SOCKS server general failure. Check if the proxy server is running.
As stated before, the system tor definitely running, up and working. So if my system tor is running, but Use Proxy is off, so it attempts to use its own internal tor daemon, why is it failing to connect to the socks server it launched itself? To be fully pedantic, now I will shut down my system tor:
sudo systemtl stop tor
Back to Sparrow, with "Use Proxy" turned on, I "Test Connection"
Connecting to tcp://electrumserverreallylonghostname.onion:50001...
Could not connect:
Retries exhausted
Expected, good! Now I turn off "Use Proxy":
Connecting to tcp://electrumserverreallylonghostname.onion:50001...
Starting Tor
Jul 25 11:09:18.331 [notice] Tor 0.4.3.6 (git-30711296fd5b7f51) running on Linux with Libevent 2.1.11-stable, OpenSSL 1.1.1g, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Jul 25 11:09:18.331 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 25 11:09:18.331 [notice] Read configuration file "/tmp/tor2678724759637111846/torrc".
Jul 25 11:09:18.332 [notice] Opening Control listener on 127.0.0.1:0
Jul 25 11:09:18.332 [notice] Control listener listening on port 41049.
Jul 25 11:09:18.332 [notice] Opened Control listener on 127.0.0.1:41049
Jul 25 11:09:18.332 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
------------------
Could not connect:
SOCKS server general failure. Check if the proxy server is running.
Unexpected. Why couldn't Sparrow connect to its own built-in Tor? I have no firewalls running, no port restrictions.
I'm unable to reproduce this behaviour on Ubuntu 20.04, with a Tor proxy (0.4.2.7) running locally. Sparrow connects to a .onion server fine, using the external proxy. It's also the first time I've heard of an issue with this common configuration. I also tested this configuration on macOS again for good measure, and it worked there too (Tor 0.4.7.7).
The key question is why, when the 'Use Proxy' toggle is enabled on your side, Sparrow apparently appears to ignore this configuration. Possibly a UI issue?
The following two entries in ~/.sparrow/config are set by the relevant UI controls, and should appear as follows:
...
"useProxy": true,
"proxyServer": "127.0.0.1:9050",
....
Can you check the above, and if so determine if the problem happens consistently across fresh Sparrow restarts?
Thanks for the followup, Craig.
You might be on to something. On my Debian box, no matter what I do, even when I turn on Use Proxy and close and re-open Sparrow, the config is always set to:
"useProxy": false,
"proxyServer": "127.0.0.1:9050",
There are only two places that useProxy can be set to false:
- The toggle in the Server Preferences. Try toggling on/off and
cat ~/.sparrow/configeach time - the value should be changing in the file immediately. If not, there is a problem with the UI toggle itself. - If using a
.onionURL, and Sparrow fails to connect through the configured proxy, it will try to setup Tor itself after internally configuringuseProxytofalse.
It would be useful to know which of the two of these it is to troubleshoot further. Also, take a look in the Sparrow log file (~/.sparrow/sparrow.log) to see if there is any error when using the toggle.
useProxy's value is not changing from false when I toggle the UI switch.
Sparrow doesn't write anything to the log until I hit "Test Connection" (after enabling "Use Proxy"). It displays the error:
Could not connect:
Error reply: Unable to set option: Failed to bind one of the listener ports.
Is a Tor proxy already running on port 9050?
And writes the following to the log:
2022-07-27 15:12:09,929 ERROR [JavaFX Application Thread] c.s.s.p.ServerPreferencesController [null:-1] Connection error
com.sparrowwallet.sparrow.net.TorServerAlreadyBoundException: Tor server already bound
at [email protected]/com.sparrowwallet.sparrow.net.TorService$1.call(Unknown Source)
at [email protected]/com.sparrowwallet.sparrow.net.TorService$1.call(Unknown Source)
at javafx.graphics@18/javafx.concurrent.Task$TaskCallable.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at javafx.graphics@18/javafx.concurrent.Service.lambda$executeTask$6(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Unknown Source)
at javafx.graphics@18/javafx.concurrent.Service.lambda$executeTask$7(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: net.freehaven.tor.control.TorControlError: Error reply: Unable to set option: Failed to bind one of the listener ports.
at [email protected]/net.freehaven.tor.control.TorControlConnection.sendAndWaitForResponse(Unknown Source)
at [email protected]/net.freehaven.tor.control.TorControlConnection.setConf(Unknown Source)
at [email protected]/net.freehaven.tor.control.TorControlConnection.setConf(Unknown Source)
at [email protected]/org.berndpruenster.netlayer.tor.TorController.enableNetwork(Unknown Source)
at [email protected]/org.berndpruenster.netlayer.tor.NativeTor.<init>(Unknown Source)
at [email protected]/org.berndpruenster.netlayer.tor.NativeTor.<init>(Unknown Source)
at [email protected]/org.berndpruenster.netlayer.tor.NativeTor.<init>(Unknown Source)
... 10 common frames omitted
useProxy's value is not changing from false when I toggle the UI switch.
Ok, that's a pretty fundamental problem if the toggle isn't triggering changes. TBH I've never heard of this before, but there's a first time for everything.
Firstly, just to check - are you running on mainnet? If testnet, the config file is at ~/.sparrow/testnet/config
Does the toggle in the main window (status bar bottom right) appear to do anything? It should trigger attempts to connect and disconnect from the current server.
My other thought is that there might be an exception during initialization of the Server Preferences dialog - is there any logging when the Preferences are opened?
Finally, what window manager are you using - anything unusual?
Well this is wild. I left it open all day and at some point useProxy went to true in the config. Apparnetly it has been trying to connect all day, it continually says "Starting Tor..." at the bottom left and the switch in the bottom right is toggled on (though greyed out and untoggleable).
~/.sparrow/testnet/ does not exist.
Now, however, when I tailed the log and opened File -> Preferences -> Server -> Edit Existing Connection, Use Proxy toggle goes back to off instantly and useProxy in ~/.sparrow/config goes to false. This is what the log shows when I do that:
2022-07-27 02:23:32,247 ERROR [JavaFX Application Thread] c.s.s.MainApp [null:-1] Exception in thread "JavaFX Application Thread"
java.lang.IllegalStateException: Can only start a Service in the READY state. Was in state RUNNING
at javafx.graphics@18/javafx.concurrent.Service.start(Unknown Source)
at [email protected]/com.sparrowwallet.sparrow.AppServices$1.changed(Unknown Source)
at [email protected]/com.sparrowwallet.sparrow.AppServices$1.changed(Unknown Source)
at javafx.base@18/com.sun.javafx.binding.ExpressionHelper$Generic.fireValueChangedEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.binding.ExpressionHelper.fireValueChangedEvent(Unknown Source)
at javafx.base@18/javafx.beans.property.BooleanPropertyBase.fireValueChangedEvent(Unknown Source)
at javafx.base@18/javafx.beans.property.BooleanPropertyBase.markInvalid(Unknown Source)
at javafx.base@18/javafx.beans.property.BooleanPropertyBase.set(Unknown Source)
at [email protected]/com.sparrowwallet.sparrow.AppServices.requestConnect(Unknown Source)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at [email protected]/com.google.common.eventbus.Subscriber.invokeSubscriberMethod(Unknown Source)
at [email protected]/com.google.common.eventbus.Subscriber$SynchronizedSubscriber.invokeSubscriberMethod(Unknown Source)
at [email protected]/com.google.common.eventbus.Subscriber$1.run(Unknown Source)
at [email protected]/com.google.common.util.concurrent.DirectExecutor.execute(Unknown Source)
at [email protected]/com.google.common.eventbus.Subscriber.dispatchEvent(Unknown Source)
at [email protected]/com.google.common.eventbus.Dispatcher$PerThreadQueuedDispatcher.dispatch(Unknown Source)
at [email protected]/com.google.common.eventbus.EventBus.post(Unknown Source)
at [email protected]/com.sparrowwallet.sparrow.preferences.PreferencesDialog.lambda$new$0(Unknown Source)
at javafx.base@18/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventUtil.fireEventImpl(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventUtil.fireEvent(Unknown Source)
at javafx.base@18/javafx.event.Event.fireEvent(Unknown Source)
at javafx.controls@18/javafx.scene.control.Dialog.close(Unknown Source)
at javafx.controls@18/javafx.scene.control.Dialog.setResultAndClose(Unknown Source)
at javafx.controls@18/javafx.scene.control.DialogPane.lambda$createButton$3(Unknown Source)
at javafx.base@18/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventUtil.fireEventImpl(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventUtil.fireEvent(Unknown Source)
at javafx.base@18/javafx.event.Event.fireEvent(Unknown Source)
at javafx.graphics@18/javafx.scene.Node.fireEvent(Unknown Source)
at javafx.controls@18/javafx.scene.control.Button.fire(Unknown Source)
at javafx.controls@18/com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(Unknown Source)
at javafx.controls@18/com.sun.javafx.scene.control.inputmap.InputMap.handle(Unknown Source)
at javafx.base@18/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventUtil.fireEventImpl(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventUtil.fireEvent(Unknown Source)
at javafx.base@18/javafx.event.Event.fireEvent(Unknown Source)
at javafx.graphics@18/javafx.scene.Scene$MouseHandler.process(Unknown Source)
at javafx.graphics@18/javafx.scene.Scene.processMouseEvent(Unknown Source)
at javafx.graphics@18/javafx.scene.Scene$ScenePeerListener.mouseEvent(Unknown Source)
at javafx.graphics@18/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(Unknown Source)
at javafx.graphics@18/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Unknown Source)
at javafx.graphics@18/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$2(Unknown Source)
at javafx.graphics@18/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(Unknown Source)
at javafx.graphics@18/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(Unknown Source)
at javafx.graphics@18/com.sun.glass.ui.View.handleMouseEvent(Unknown Source)
at javafx.graphics@18/com.sun.glass.ui.View.notifyMouse(Unknown Source)
at javafx.graphics@18/com.sun.glass.ui.gtk.GtkApplication.enterNestedEventLoopImpl(Native Method)
at javafx.graphics@18/com.sun.glass.ui.gtk.GtkApplication._enterNestedEventLoop(Unknown Source)
at javafx.graphics@18/com.sun.glass.ui.Application.enterNestedEventLoop(Unknown Source)
at javafx.graphics@18/com.sun.glass.ui.EventLoop.enter(Unknown Source)
at javafx.graphics@18/com.sun.javafx.tk.quantum.QuantumToolkit.enterNestedEventLoop(Unknown Source)
at javafx.graphics@18/javafx.stage.Stage.showAndWait(Unknown Source)
at javafx.controls@18/javafx.scene.control.HeavyweightDialog.showAndWait(Unknown Source)
at javafx.controls@18/javafx.scene.control.Dialog.showAndWait(Unknown Source)
at [email protected]/com.sparrowwallet.sparrow.AppController.openPreferences(Unknown Source)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javafx.reflect.Trampoline.invoke(Unknown Source)
at jdk.internal.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at javafx.base@18/com.sun.javafx.reflect.MethodUtil.invoke(Unknown Source)
at javafx.fxml@18/com.sun.javafx.fxml.MethodHelper.invoke(Unknown Source)
at javafx.fxml@18/javafx.fxml.FXMLLoader$MethodHandler.invoke(Unknown Source)
at javafx.fxml@18/javafx.fxml.FXMLLoader$ControllerMethodEventHandler.handle(Unknown Source)
at javafx.base@18/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventUtil.fireEventImpl(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventUtil.fireEvent(Unknown Source)
at javafx.base@18/javafx.event.Event.fireEvent(Unknown Source)
at javafx.controls@18/javafx.scene.control.MenuItem.fire(Unknown Source)
at javafx.controls@18/com.sun.javafx.scene.control.ContextMenuContent$MenuItemContainer.doSelect(Unknown Source)
at javafx.controls@18/com.sun.javafx.scene.control.ContextMenuContent$MenuItemContainer.lambda$createChildren$12(Unknown Source)
at javafx.base@18/com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventUtil.fireEventImpl(Unknown Source)
at javafx.base@18/com.sun.javafx.event.EventUtil.fireEvent(Unknown Source)
at javafx.base@18/javafx.event.Event.fireEvent(Unknown Source)
at javafx.graphics@18/javafx.scene.Scene$MouseHandler.process(Unknown Source)
at javafx.graphics@18/javafx.scene.Scene.processMouseEvent(Unknown Source)
at javafx.graphics@18/javafx.scene.Scene$ScenePeerListener.mouseEvent(Unknown Source)
at javafx.graphics@18/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(Unknown Source)
at javafx.graphics@18/com.sun.javafx.tk.quantum.GlassViewEventHandler$MouseEventNotification.run(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Unknown Source)
at javafx.graphics@18/com.sun.javafx.tk.quantum.GlassViewEventHandler.lambda$handleMouseEvent$2(Unknown Source)
at javafx.graphics@18/com.sun.javafx.tk.quantum.QuantumToolkit.runWithoutRenderLock(Unknown Source)
at javafx.graphics@18/com.sun.javafx.tk.quantum.GlassViewEventHandler.handleMouseEvent(Unknown Source)
at javafx.graphics@18/com.sun.glass.ui.View.handleMouseEvent(Unknown Source)
at javafx.graphics@18/com.sun.glass.ui.View.notifyMouse(Unknown Source)
at javafx.graphics@18/com.sun.glass.ui.gtk.GtkApplication._runLoop(Native Method)
at javafx.graphics@18/com.sun.glass.ui.gtk.GtkApplication.lambda$runLoop$11(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
I still get the following error upon going into the server settings for electrum and hitting "Test Connection" even though tor is up and functioning just fine on 127.0.0.1:9050 for other apps:
Connecting to tcp://electrumserverreallylonghostname.onion:50001...
Stopping Tor
Tor is already running, using external instance...
Starting Tor...
Starting Tor
Jul 27 20:35:05.944 [notice] Tor 0.4.3.6 (git-30711296fd5b7f51) running on Linux with Libevent 2.1.11-stable, OpenSSL 1.1.1g, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Jul 27 20:35:05.944 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 27 20:35:05.944 [notice] Read configuration file "/tmp/tor17203376482810970843/torrc".
Jul 27 20:35:05.945 [notice] Opening Control listener on 127.0.0.1:0
Jul 27 20:35:05.945 [notice] Control listener listening on port 41829.
Jul 27 20:35:05.945 [notice] Opened Control listener on 127.0.0.1:41829
Jul 27 20:35:05.945 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
Starting Tor
Jul 27 20:35:06.205 [notice] Tor 0.4.3.6 (git-30711296fd5b7f51) running on Linux with Libevent 2.1.11-stable, OpenSSL 1.1.1g, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Jul 27 20:35:06.205 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jul 27 20:35:06.205 [notice] Read configuration file "/tmp/tor5277184224155638927/torrc".
Jul 27 20:35:06.207 [notice] Opening Control listener on 127.0.0.1:0
Jul 27 20:35:06.207 [notice] Control listener listening on port 33895.
Jul 27 20:35:06.207 [notice] Opened Control listener on 127.0.0.1:33895
Jul 27 20:35:06.207 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
-------------------------
Could not connect:
Error reply: Unable to set option: Failed to bind one of the listener ports.
Is a Tor proxy already running on port 9050?
The behaviour of the Use Proxy toggle is not making much sense barring some underlying problem in the UI framework.
I'm going to need to try recreate this problem - can you provide details of your Debian system so I can try to set it up in a VM?
I've installed Debian 11.4.0 (amd64) on a VM and then installed tor (0.4.7.8) and Sparrow (1.6.5). I was able to connect to a .onion server using the external proxy configured at 127.0.0.1:9050 without issues.
Tried to reproduce the toggle issue with Use Proxy as well on both GNOME and Xfce - in both cases switching the toggle immediately changed the value in ./sparrow/config.
If you can provide any more details here that might help to recreate this I'd appreciate it.
I am having the same issue....Sparrow was connecting to my node via private electrum .onion address. I used this guide: https://raspibolt.org/guide/bitcoin/desktop-wallet.html It was working, but now it wont connect:
without "Use Proxy":**
Could not connect:
SOCKS server general failure. Check if the proxy server is running.
Could it just be TOR that is having temp problems? Why does it say "exited" instead of "running"?
admin@raspibolt:~ $ systemctl status tor
- tor.service - Anonymizing overlay network for TCP (multi-instance-master) Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor preset: enabled) Active: active (exited) since Mon 2022-08-01 05:42:12 BST; 1h 47min ago Process: 529 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 529 (code=exited, status=0/SUCCESS) CPU: 6ms
Warning: some journal files were not opened due to insufficient permissions.
@uskrusader It looks like your external Tor proxy simply shut down for some reason.
This issue tracks a reported configuration problem with the Use Proxy toggle, and so is unrelated.
"active (exited)" means that whoever made the systemd service file didn't use the features of systemd that allow it to track the service properly, but it is probably up. My system tor also says the same thing though it is up and working fine.
Sorry to have taken so long to get back to you, but when I went to go reproduce this (the button not instantly setting ~/.sparrow/config useProxy to true) on other systems, I could not. The system I was originally testing on is actually Parrot (A debian-based distro that has some off-the-beaten-path security properties) so I figured I'd go duplicate it on basic debian, and could not. So although maybe there's a bug somehow somewhere about it not setting use proxy, I cannot duplicate that anywhere reasonable. However, even though useProxy gets set instantly, I still have issues connecting to the local tor socks proxy on multiple systems.
Here is on Linux Mint (21 xfce (based on Ubuntu), tor is up and running and working, useProxy successfully enabled, and I am using the electrum client itself, connected to the same electrs onion on the same Mint install, simultaneously, so tor and my server are working):
Could not connect:
SOCKS server general failure. Check if the proxy server is running.
LOG:
2022-08-01 11:54:42,657 ERROR [JavaFX Application Thread] c.s.s.p.ServerPreferencesController [null:-1] Connection error
com.sparrowwallet.sparrow.net.ProxyServerException: java.net.SocketException: SOCKS server general failure
at [email protected]/com.sparrowwallet.sparrow.net.TcpTransport.connect(Unknown Source)
at [email protected]/com.sparrowwallet.sparrow.net.ElectrumServer.connect(Unknown Source)
at [email protected]/com.sparrowwallet.sparrow.net.ElectrumServer$ConnectionService$1.call(Unknown Source)
at [email protected]/com.sparrowwallet.sparrow.net.ElectrumServer$ConnectionService$1.call(Unknown Source)
at javafx.graphics@18/javafx.concurrent.Task$TaskCallable.call(Unknown Source)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at javafx.graphics@18/javafx.concurrent.Service.lambda$executeTask$6(Unknown Source)
at java.base/java.security.AccessController.doPrivileged(Unknown Source)
at javafx.graphics@18/javafx.concurrent.Service.lambda$executeTask$7(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.net.SocketException: SOCKS server general failure
at java.base/java.net.SocksSocketImpl.connect(Unknown Source)
at java.base/java.net.Socket.connect(Unknown Source)
at java.base/java.net.Socket.connect(Unknown Source)
at [email protected]/com.sparrowwallet.sparrow.net.ProxySocketFactory.createSocket(Unknown Source)
at [email protected]/com.sparrowwallet.sparrow.net.ProxySocketFactory.createSocket(Unknown Source)
at [email protected]/com.sparrowwallet.sparrow.net.TcpTransport.createSocket(Unknown Source)
... 12 common frames omitted
So I uncheck "Use Proxy" in the hopes sparrow will use the built-in tor. It tries...
Connecting to tcp://electrumserverreallylonghostname.onion:50001...
Starting Tor
Aug 01 12:51:05.678 [notice] Tor 0.4.3.6 (git-30711296fd5b7f51) running on Linux with Libevent 2.1.11-stable, OpenSSL 1.1.1g, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Aug 01 12:51:05.678 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Aug 01 12:51:05.678 [notice] Read configuration file "/tmp/tor4267375093160349034/torrc".
Aug 01 12:51:05.681 [notice] Opening Control listener on 127.0.0.1:0
Aug 01 12:51:05.681 [notice] Control listener listening on port 45775.
Aug 01 12:51:05.681 [notice] Opened Control listener on 127.0.0.1:45775
Aug 01 12:51:05.681 [notice] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
But ends with:
Could not connect:
SOCKS server general failure. Check if the proxy server is running.
Thanks for the additional testing.
The issue is quite clear now - the Java SOCKS client java.net.SocksSocketImpl successfully starts the negotiation with the Tor proxy server, but during this initialisation process the server replies with a general failure message. Why it does so is unclear, but there are some potential reasons.
I've used Wireshark to examine the packets in the SOCKS protocol negotiation with both Sparrow and Electrum. This process is described quite well here: https://samsclass.info/122/proj/how-socks5-works.html. Of course on my side both are working successfully, but I thought it would be useful to see how they differ.
The only difference during the connection phase is that the Electrum (Python) client indicates it can only handle "No Auth" (0x00) authentication, while the Sparrow (Java) client indicates it can handle both "No Auth" 00 and "Username/password" 02. The response from the proxy is therefore different - to Python it responds with "No Auth" 00 and to Java it responds with "Username/password" 02 (I assume because switching credentials is a way of switching Tor circuits). Python proceeds to connection, while Java, in the absence of any supplied credentials, sends the username of the current system user and an empty password, which the proxy authenticates successfully with a response of 01 00. Note that this must be true even in your case, otherwise a Java exception would be raised at this point.
Both clients then write identical byte streams (on my side at least) with 05 01 00 03 3e 73 72 .... 2e 6f 6e 69 6f 6e c3 51 which contains a header indicating the domain name, followed by the electrumserverreallylonghostname.onion address followed by the port. The proxy responds to this with bytes starting with 05 00 indicating the negotiation was successful. In your case, the proxy is responding with 05 01, which is classified a "general SOCKS server failure" according to RFC 1928.
My suspicion is that either the authentication is causing the failure to happen in some mysterious way (seems unlikely given that the proxy has already successfully authenticated the client before it returns an error), or that there is something odd about the domain name that is being passed to the proxy (which seems more likely since it is the last piece of information supplied by the client before the error is returned).
This suspicion is borne out by testing. When I try to use the non-functional Tor v3 address for blockstream.info (explorerzydxu5ecjrkwceayqybizmjjznk5izmitf2modhcusuqlid.onion) my Tor proxy also responds with general SOCKS server failure 05 01, and logs [warn] Invalid hostname [scrubbed]; rejecting in the Tor log. Is there anything written to this log when you try connecting?
My tor configuration is default (no Socks5ProxyUsername or Socks5ProxyPassword are set), and my server address is a standard Tor v3 hidden service.
Here is my Tor log when connecting to the blockstream address above with Tor's config set to Log debug:
Aug 02 10:19:32.000 [debug] connection_handle_listener_read: Connection accepted on socket 9 (child of fd 4).
Aug 02 10:19:32.000 [info] connection_handle_listener_read: New SOCKS connection opened from 127.0.0.1.
Aug 02 10:19:32.000 [debug] connection_add_impl: new conn type Socks, socket 9, address 127.0.0.1, n_conns 5.
Aug 02 10:19:32.000 [debug] conn_read_callback: socket 9 wants to read.
Aug 02 10:19:32.000 [debug] read_to_chunk: Read 4 bytes. 4 on inbuf.
Aug 02 10:19:32.000 [debug] connection_ap_handshake_process_socks: entered.
Aug 02 10:19:32.000 [debug] process_socks5_methods_request: socks5: accepted method 2 (username/password)
Aug 02 10:19:32.000 [debug] connection_ap_handshake_process_socks: socks handshake not all here yet.
Aug 02 10:19:32.000 [debug] connection_ap_handshake_process_socks: entered.
Aug 02 10:19:32.000 [debug] connection_ap_handshake_process_socks: socks handshake not all here yet.
Aug 02 10:19:32.000 [debug] conn_write_callback: socket 9 wants to write.
Aug 02 10:19:32.000 [debug] conn_read_callback: socket 9 wants to read.
Aug 02 10:19:32.000 [debug] read_to_chunk: Read 14 bytes. 14 on inbuf.
Aug 02 10:19:32.000 [debug] connection_ap_handshake_process_socks: entered.
Aug 02 10:19:32.000 [debug] connection_ap_handshake_process_socks: socks handshake not all here yet.
Aug 02 10:19:32.000 [debug] connection_ap_handshake_process_socks: entered.
Aug 02 10:19:32.000 [debug] connection_ap_handshake_process_socks: socks handshake not all here yet.
Aug 02 10:19:32.000 [debug] conn_write_callback: socket 9 wants to write.
Aug 02 10:19:32.000 [debug] conn_read_callback: socket 9 wants to read.
Aug 02 10:19:32.000 [debug] read_to_chunk: Read 68 bytes. 68 on inbuf.
Aug 02 10:19:32.000 [debug] connection_ap_handshake_process_socks: entered.
Aug 02 10:19:32.000 [debug] connection_ap_handshake_rewrite: Client asked for [scrubbed]:143
Aug 02 10:19:32.000 [warn] Invalid hostname [scrubbed]; rejecting
I've attached my pcap in the hopes that you can make more sense of it than I can.
Best I can tell: Tor sends 0502 Sparrow sends back 05020002 (I think?) sparrow then tries to proxy a connection to the onion(?) Shortly thereafter tor sends a FIN+ACK packet which then terminates the tcp session between Sparrow and Tor's socks proxy .
Thanks, that's very helpful. It's now clear why your Tor proxy is disconnecting from Sparrow: Your electrumserverreallylonghostname.onion is resolving to a local IP on your machine. Exactly why is does so is unclear to me, but I assume there is a good reason - perhaps Docker?
Here is what happens:
- The Java proxy client in Sparrow authenticates successfully with the proxy.
- The proxy client takes the provided Electrum server address it is being asked to connect to via the proxy and sees it is resolvable.
- The proxy client writes the resolved IPv4 address and the port to the proxy server, in this case
10.99.28.191:50001. You can see this in your network capture at the end of frame 14:05 01 00 01 0a 63 1c bf c3 51. - The Tor proxy server notes this is a local IP address, and because it cannot handle it, closes the connection.
To me, it appears that electrumserverreallylonghostname.onion should not be resolvable (but is). Can you shed more light on your local setup?
Well, I have absolutely no explanation for that. I am on a 10. private network but nowhere is 10.99.* anything used. And I'm not sure where this IP could have come from, no DNS server I can query at the moment will give me any answer for an A record for my electrumserverreallylonghostname.onion. Besides that, I was under the impression Tor's socks (4a/5) proxy does the resolution itself (by forwarding that job to an exit node who sends the answer back to the originating tor client in the case of exit node -> clearnet, and by some other method for hidden services - Obviously .onions need to resolve to something inside tor, or ip can't work, but afaik these are mapped internally to the 127.0.0.0/8 space.). I wasn't even aware socks exposed the answer to the client, really. If sparrow is asking for the IP from DNS before it talks to the socks proxy, that's a privacy leak and probably needs to be changed.
As far as my local setup, it is the defaults of Linux Mint:
/etc/resolv.conf is a link to /run/resolvconf/resolv.conf which contains:
nameserver 127.0.0.53
systemd-resolved is listening on 127.0.0.53:53
My DHCP hands out a DNS server of 1.1.1.1 but when I do a dig google.com I see systemd-resolved's nameserver is the one giving the answers:
;; SERVER: 127.0.0.53#53(127.0.0.53)
What it is doing on the backend is kind of mysterious. The only uncommented line in /etc/systemd/resolved.conf is:
[Resolve]
I was under the impression Tor's socks (4a/5) proxy does the resolution itself
True, these versions of the protocol can do DNS resolution, although the user might be using a Socks4 proxy which cannot.
If sparrow is asking for the IP from DNS before it talks to the socks proxy, that's a privacy leak and probably needs to be changed.
Agreed, it's not ideal. I'd made a change in ca782dfc which checks if the host is a .onion address, and if so avoids the automatic DNS resolution attempt that occurs when creating the socket address. This should solve this issue, although why it is occurring in the first place is still a mystery. Internally Java uses the system getaddrinfo call which is standard. I setup my system to use 1.1.1.1 but could not reproduce this.
Would it be possible to run from source (instructions in README) to see if this fixes the problem?
After following the instructions here: https://github.com/sparrowwallet/sparrow/blob/master/docs/reproducible.md
Mixed with the ones here so I don't pull down the 1.6.6 tag, but master, and with this small detail changed to pull down the latest because the version recommended was not available:
user@host:~/Dev/Packages/sparrow$ sudo apt install -y temurin-17-jdk=18.0.1+10
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Version '18.0.1+10' for 'temurin-17-jdk' was not found
user@host:~/Dev/Packages/sparrow$ sudo apt install -y temurin-18-jdk=18.0.2+9
Reading package lists... Done
Building dependency tree
Reading state information... Done
temurin-18-jdk is already the newest version (18.0.2+9).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Things look good until I get to:
$ ./gradlew jpackage --info
Initialized native services in: /home/user/.gradle/native
Initialized jansi services in: /home/user/.gradle/native
The client will now receive all logging from the daemon (pid: 131427). The daemon log file: /home/user/.gradle/daemon/7.5/daemon-131427.out.log
Starting 11th build in daemon [uptime: 1 hrs 47 mins 17.776 secs, performance: 99%, non-heap usage: 18% of 256 MiB]
Using 8 worker leases.
Not watching /home/user/Dev/Packages/sparrow since the file system is not supported
Not watching /home/user/Dev/Packages/sparrow/buildSrc since the file system is not supported
Watching the file system is configured to be enabled if available
File system watching is active
Starting Build
Settings evaluated using settings file '/home/user/Dev/Packages/sparrow/settings.gradle'.
Projects loaded. Root project using build file '/home/user/Dev/Packages/sparrow/build.gradle'.
Included projects: [root project 'sparrow', project ':drongo']
> Configure project :buildSrc
Evaluating project ':buildSrc' using build file '/home/user/Dev/Packages/sparrow/buildSrc/build.gradle'.
Task name matched 'build'
Selected primary task 'build' from project :
Resolve mutations for :buildSrc:compileJava (Thread[Execution worker,5,main]) started.
Resolve mutations for :buildSrc:compileJava (Thread[Execution worker,5,main]) completed. Took 0.001 secs.
:buildSrc:compileJava (Thread[included builds,5,main]) started.
> Task :buildSrc:compileJava FAILED
Caching disabled for task ':buildSrc:compileJava' because:
Build cache is disabled
Task ':buildSrc:compileJava' is not up-to-date because:
Task has failed previously.
The input changes require a full rebuild for incremental task ':buildSrc:compileJava'.
Full recompilation is required because no incremental change information is available. This is usually caused by clean builds or changing compiler arguments.
Compiling with toolchain '/usr/local'.
Compiling with JDK Java compiler API.
:buildSrc:compileJava (Thread[included builds,5,main]) completed. Took 0.021 secs.
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':buildSrc:compileJava'.
> Java compiler is not available. Please check that /usr/local contains a valid JDK installation.
* Try:
> Run with --stacktrace option to get the stack trace.
> Run with --debug option to get more log output.
> Run with --scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 606ms
1 actionable task: 1 executed
Some of the file system contents retained in the virtual file system are on file systems that Gradle doesn't support watching. The relevant state was discarded to ensure changes to these locations are properly detected. You can override this by explicitly enabling file system watching.
It keeps looking for java & all its associated binaries in /usr/local/ yet I've repeatedly informed it of where java lives, as instructed in reproducible.md:
$ sudo update-alternatives --config java
[sudo] password for user:
There are 2 choices for the alternative java (providing /usr/bin/java).
Selection Path Priority Status
------------------------------------------------------------
0 /usr/lib/jvm/temurin-18-jdk-amd64/bin/java 1811 auto mode
1 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111 manual mode
* 2 /usr/lib/jvm/temurin-18-jdk-amd64/bin/java 1811 manual mode
Press <enter> to keep the current choice[*], or type selection number: 0
To no avail. Any ideas?
I'm not sure - my approach is to use SDKman to manage the JDKs, which is detailed a little further down in the doc. It seems to avoid these kinds of issues.
Happy to create a binary for you tomorrow though.
Excellent, that worked, thanks!
So this is odd. When I specify the proxy as 127.0.0.1:9050 it does not work:
Could not connect:
Retries exhausted
2022-08-16 13:49:43,775 ERROR [JavaFX Application Thread] c.s.s.p.ServerPreferencesController [ServerPreferencesController.java:579] Connection error
com.sparrowwallet.sparrow.net.ElectrumServerRpcException: Error getting server version
at [email protected]/com.sparrowwallet.sparrow.net.SimpleElectrumServerRpc.getServerVersion(SimpleElectrumServerRpc.java:47)
at [email protected]/com.sparrowwallet.sparrow.net.ElectrumServer.getServerVersion(ElectrumServer.java:145)
at [email protected]/com.sparrowwallet.sparrow.net.ElectrumServer$ConnectionService$1.call(ElectrumServer.java:1138)
at [email protected]/com.sparrowwallet.sparrow.net.ElectrumServer$ConnectionService$1.call(ElectrumServer.java:1080)
at javafx.graphics@18/javafx.concurrent.Task$TaskCallable.call(Task.java:1426)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at javafx.graphics@18/javafx.concurrent.Service.lambda$executeTask$6(Service.java:727)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at javafx.graphics@18/javafx.concurrent.Service.lambda$executeTask$7(Service.java:726)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: com.sparrowwallet.sparrow.net.ServerException: Retries exhausted
at [email protected]/com.sparrowwallet.sparrow.net.RetryLogic.getResult(RetryLogic.java:38)
at [email protected]/com.sparrowwallet.sparrow.net.SimpleElectrumServerRpc.getServerVersion(SimpleElectrumServerRpc.java:44)
... 11 common frames omitted
Caused by: java.lang.IllegalStateException: I/O error during a request processing
at [email protected]/com.github.arteam.simplejsonrpc.client.builder.RequestBuilder.executeRequest(RequestBuilder.java:364)
at [email protected]/com.github.arteam.simplejsonrpc.client.builder.RequestBuilder.executeAndConvert(RequestBuilder.java:316)
at [email protected]/com.github.arteam.simplejsonrpc.client.builder.RequestBuilder.execute(RequestBuilder.java:295)
at [email protected]/com.sparrowwallet.sparrow.net.SimpleElectrumServerRpc.lambda$getServerVersion$1(SimpleElectrumServerRpc.java:45)
at [email protected]/com.sparrowwallet.sparrow.net.RetryLogic.getResult(RetryLogic.java:34)
... 12 common frames omitted
Caused by: java.io.IOException: No response from server
at [email protected]/com.sparrowwallet.sparrow.net.TcpTransport.readResponse(TcpTransport.java:109)
at [email protected]/com.sparrowwallet.sparrow.net.TcpTransport.pass(TcpTransport.java:88)
at [email protected]/com.github.arteam.simplejsonrpc.client.builder.RequestBuilder.executeRequest(RequestBuilder.java:362)
... 16 common frames omitted
Very odly, when I specify localhost:9050 it does work:
Connected to electrs/0.9.7 on protocol version 1.4
Batched RPC enabled.
Server Banner: Welcome to electrs 0.9.7 (Electrum Rust Server)!
Very odd indeed.
To try understand this, I've created a very simple Java application which will indicate what Java is doing when it attempts to resolve:
import java.net.*;
public class Resolver {
public static void main(String[] args) {
String host = "127.0.0.1";
if(args.length > 0) {
host = args[0];
}
InetSocketAddress socketAddress = new InetSocketAddress(host, 50001);
if(socketAddress.isUnresolved()) {
System.out.println("Could not resolve " + host);
} else {
System.out.println(host + " resolved to " + socketAddress.getAddress());
}
}
}
You can compile this yourself with javac Resolver.java, or use the attached .class file, compiled with Java 18. The InetSocketAddress constructor is the same one used within Sparrow when creating the proxy address. The host you are trying to resolve can be passed in as the first parameter. Here are my results:
❯ java Resolver localhost
localhost resolved to localhost/127.0.0.1
❯ java Resolver 127.0.0.1
127.0.0.1 resolved to /127.0.0.1
❯ java Resolver paynym7bwekdtb2hzgkpl6y2waqcrs2dii7lwincvxme7mdpcpxzfsad.onion
Could not resolve paynym7bwekdtb2hzgkpl6y2waqcrs2dii7lwincvxme7mdpcpxzfsad.onion
That actually works as expected (with a twist):
$ java Resolver localhost
localhost resolved to localhost/127.0.0.1
$ java Resolver 127.0.0.1
127.0.0.1 resolved to /127.0.0.1
$ java Resolver electrumserverreallylonghostname.onion
electrumserverreallylonghostname.onion resolved to electrumserverreallylonghostname.onion/xx.xx.xxx.xxx
Turns out the network I am on at work specifies a search domain blah.tld, AND our nameserver does wildcard resolution for *.blah.tld, so when I would ask the DNS server what the A record for electrumserverreallylonghostname.onion was, it would return an A record that actually resolved to an ip for electrumserverreallylonghostname.onion.blah.tld.
This must have just been a conveniently timed tor-being-shitty thing yesterday (I noticed hidden services being rather intermittently available - it's been getting ddos'd for months now and afaict was extra shitty over the last week, though today something seems to have abated, and not just where I am). Anyway, today when I tried with the same yesterday's-master Sparrow, 127.0.0.1:9050, it worked fine. So maybe that was a red herring. I actually now have your master and 1.6.5 lined up right next to each other and master can connect and 1.6.5 cannot, so I think this is fixed for me. Thank you!
Great to hear! Following this down the rabbit hole has improved Sparrow, so I'm grateful for your patience as we figured this out. Closing this off.