wstunnel stdio does not exit / stuck in a loop

[streaps]

I have a problem to get wstunnel -L stdio work with some software. It looks like wstunnel doesn't exit and tries to connect again and again. Simple example

$ echo "Hello Server" | wstunnel -L stdio:localhost:1234 wss://example.com
Hello Client!
CLOSE tunnel :: 127.0.0.1:0 <==WSS==> example.com:443 <==STDIO==> localhost:1234
CLOSE tunnel :: 127.0.0.1:0 <==WSS==> example.com:443 <==STDIO==> localhost:1234
CLOSE tunnel :: 127.0.0.1:0 <==WSS==> example.com:443 <==STDIO==> localhost:1234
[...]

This does work though:

$ echo "Hello Server" | ncat --proxy 127.0.0.1:1080 --proxy-type socks5 localhost 1234
Hello Client!
$

(port 1080 is wstunnel)

There are also no issues with ssh and ProxyCommand wstunnel -L stdio:...

[erebe]

Hello,

Thanks for reporting !
Have to check if it is a feature or a bug, basically if the tunnel get disconnect we keep retrying to establish a new one.
I am not sure if this behavior is desirable when there is a connection issue (as it will automatically reconnect you)
In your case it is clearly a pain, as you can't exist the program without killing wstunnel

🤔

[struanb]

Any update on this issue? When using wstunnel with ssh, we want wstunnel to exit if the server closes the connection, but currently we get the infinite loop of error messages described above.

Is what we need a command-line option that tells wstunnel to exit immediately in the case its initial connection, once made, is clsed?

[erebe]

Will try to get a look at it this week, and coming back to you

[erebe]

Hey,
I gave it a shot, would you mind trying this release and let know if it matches your expectations
https://github.com/erebe/wstunnel/suites/16183624020/artifacts/924199162 (linux)
https://github.com/erebe/wstunnel/suites/16183624020/artifacts/924199164 (mac)
https://github.com/erebe/wstunnel/suites/16183624020/artifacts/924199165 (windows)

[struanb]

Thanks for doing this. I've tested the mac version, in conjunction with ssh. It works well.

Here are before and after logs from an ssh connection made via wstunnel, when the remote wstunnel dies.

Before:

CLOSE tunnel :: 127.0.0.1:0 <==WSS==> myserver:443 <==STDIO==> 127.0.0.1:22
[hangs]
ERROR :: Cannot establish websocket connection with the server
                               ERROR :: Cannot establish websocket connection with the server
                                                                                             ERROR :: Cannot establish websocket connection with the server
                                                                                                                                                           ERROR :: Cannot establish websocket connection with the server
                                                         ERROR :: Cannot establish websocket connection with the server
                                                                                                                       ERROR :: Cannot establish websocket connection with the server
                     ERROR :: Cannot establish websocket connection with the server
                                                                                   ERROR :: Cannot establish websocket connection with the server
                                                                                                                                                 ERROR :: Cannot establish websocket connection with the server
[loops indefinitely]

After:

CLOSE tunnel :: 127.0.0.1:0 <==WSS==> myserver:443 <==STDIO==> 127.0.0.1:22
                                                                                                                                 CLOSE stdio server
                                                                                                                                                   Bad packet length 3702688319.
ssh_dispatch_run_fatal: Connection to UNKNOWN port 65535: Connection corrupted

Will the new version need a command line option that enables the new behaviour, or do you feel the new behaviour is better in all cases?

[erebe]

I think I will not add a flag, and make this behavior the default.
If stdin close, there is not much we can do to resume the connection. The only way is to spawn a new process to get a fresh stdin.
if it is the remote connection that close, well, it is super hard to resume it because there is no way anymore to know what data has been sent or if some has been lost in the middle, so the only way is to restart a new connection, and sadly with stdin there is no feedback loop possible to notify the program to tell it re-open a new cnx.

So I will make it the default and see if some users complains

[struanb]

Makes complete sense.

[erebe]

Available in https://github.com/erebe/wstunnel/releases/tag/v6.0