websocat icon indicating copy to clipboard operation
websocat copied to clipboard

TCP socket listen does not work on Windows

Open ivarref opened this issue 1 year ago • 2 comments

Hi

And thanks for a great project!

I've noticed that running websocat.x86_64-pc-windows-gnu.exe -vvv -t -E tcp-l:127.0.0.1:8090 - does not work as expected on windows.

Console output:

H:\>websocat.x86_64-pc-windows-gnu.exe -vvv -t -E tcp-l:127.0.0.1:8090 -
[DEBUG websocat] Done third phase of interpreting options.
[DEBUG websocat] Done fourth phase of interpreting options.
[DEBUG websocat] Preparation done. Now actually starting.
[DEBUG websocat::sessionserve] Serving TcpListen(127.0.0.1:8090) to BroadcastReuser(ThreadedStdio) with Options { websocket_text_mode: true, websocket_protocol: None, websocket_reply_protocol: None, udp_oneshot_mode: false, udp_broadcast: false, udp_multicast_loop: false, udp_ttl: None, udp_join_multicast_addr: [], udp_join_multicast_iface_v4: [], udp_join_multicast_iface_v6: [], udp_reuseaddr: false, unidirectional: false, unidirectional_reverse: false, max_messages: None, max_messages_rev: None, exit_on_eof: true, oneshot: false, unlink_unix_socket: false, unix_socket_accept_from_fd: false, exec_args: [], ws_c_uri: "ws://0.0.0.0/", linemode_strip_newlines: false, linemode_strict: false, origin: None, custom_headers: [], custom_reply_headers: [], websocket_version: None, websocket_dont_close: false, websocket_ignore_zeromsg: false, one_message: false, no_auto_linemode: false, buffer_size: 65536, broadcast_queue_len: 16, read_debt_handling: Warn, linemode_zero_terminated: false, restrict_uri: None, serve_static_files: [], exec_set_env: false, no_exit_on_zeromsg: false, reuser_send_zero_msg_on_disconnect: false, process_zero_sighup: false, process_exit_sighup: false, process_exit_on_disconnect: false, socks_destination: None, auto_socks5: None, socks5_bind_script: None, tls_domain: None, tls_insecure: false, headers_to_env: [], max_parallel_conns: None, ws_ping_interval: None, ws_ping_timeout: None, request_uri: None, request_method: None, request_headers: [], autoreconnect_delay_millis: 20, ws_text_prefix: None, ws_binary_prefix: None, ws_binary_base64: false, ws_text_base64: false, close_status_code: None, close_reason: None, asyncstdio: false, foreachmsg_wait_reads: false, announce_listens: false, timestamp_monotonic: false, print_ping_rtts: false, byte_to_exit_on: 28, max_ws_message_length: 209715200, max_ws_frame_length: 104857600, preamble: [], preamble_reverse: [], compress_deflate: false, compress_zlib: false, compress_gzip: false, uncompress_deflate: false, uncompress_zlib: false, uncompress_gzip: false, jsonrpc_omit_jsonrpc: false, inhibit_pongs: None, max_sent_pings: None }
[DEBUG websocat::net_peer] Listening TCP socket

Some diagnostics showing that websocat is not listening:

H:\>netstat -n -p TCP -a | findstr 127.0.0.1
  TCP    127.0.0.1:9001         0.0.0.0:0              LISTENING
  TCP    127.0.0.1:9002         0.0.0.0:0              LISTENING
  TCP    127.0.0.1:21207        0.0.0.0:0              LISTENING
  TCP    127.0.0.1:24612        0.0.0.0:0              LISTENING
  TCP    127.0.0.1:24749        0.0.0.0:0              LISTENING

H:\>telnet 127.0.0.1 8090
(this fails with a Norwegian error message...)

I'm using

H:\>websocat.x86_64-pc-windows-gnu.exe --version
websocat 1.12.0

Any idea about how to solve this issue?

Thanks and kind regards.

ivarref avatar Nov 01 '23 19:11 ivarref

Update: I have the exact same issue with a java TCP server. It seems this is some kind of firewall issue of sorts. Apparently Windows is strict on loopback access (!). I'm not an admin on the windows host.

More info: https://learn.microsoft.com/en-us/windows/uwp/communication/interprocess-communication#loopback https://stackoverflow.com/questions/34428173/unable-to-access-tcp-server-inside-a-windows-universal-application

ivarref avatar Nov 02 '23 09:11 ivarref

Typically when you start a listening program on Windows, interactive pop up shows up where you can configure the firewall for that application.

Localhost connections just work though even without a firewall exception, as far as I remember.

vi avatar Nov 02 '23 14:11 vi