It looks like the most common method to use irssi over tor is to use a transparent proxy to tamper with network libraries, like torsocks or using proxychains4. Those approaches are useless when you also use Irssi with #Bitlbee, because bitlbee runs a local agent obviously becomes unreachable with torsocks in the loop.

So I must use a more complex approach:

$ socat -T9999999 -s TCP4-LISTEN:13999,ignoreeof SOCKS4A:127.0.0.1:libera75jm6of4wxpxt4aynol3xjmbtxgfyjpu34ss4d7r7q2v5zrpyd.onion:6697,socksport=9050,ignoreeof &
$ socat_pid_libera=$!
$ irssi
$ kill ${socat_pid_libera}

Then irssi is configured to point the libera network to 127.0.0.1:13999.

That’s the idea. There is a separate socat process for every IRC host I might reach, which is about a dozen in my case. Apart from ugly tediousness, it works for like 30 min on avg then dies. I believe that’s the nature of Tor. Circuits die and get replaced, and when that happens socat is left with a dead connection for some reason.

Is there a remedy? I there a way to make socat resilient to tor volatility?

  • okwhateverdude@lemmy.worldEnglish
    2·
    2 days ago

    TL;DR: you need to make socat resilient. Try adding the fork option.

    AI SLOP answer that is grounded in online search:

    The behavior you’re experiencing is by design: socat’s forever option only applies to initial connection attempts, not reconnection after a successful connection drops [1]. Once the Tor circuit rotates (which happens every ~10 minutes by default [2]), the underlying TCP connection dies and socat exits because its relay job is complete.

    Here are remedies to make your setup resilient:

    1. Wrap socat in a restart loop (Recommended)

    The most reliable solution is a shell wrapper that respawns socat immediately when it exits. This creates a fresh connection through a new Tor circuit:

    while true; do
    socat -T9999999 -s TCP4-LISTEN:13999,ignoreeof,reuseaddr SOCKS4A:127.0.0.1:libera75jm6of4wxpxt4aynol3xjmbtxgfyjpu34ss4d7r7q2v5zrpyd.onion:6697,socksport=9050,ignoreeof
    sleep 1
done &

    The reuseaddr option ensures the listening socket can be rebound immediately [3][4]. When Tor rotates circuits, socat dies, the loop restarts it, and irssi reconnects automatically (irssi has built-in reconnection logic [5][6]).

    2. Use fork to handle multiple reconnections

    If you want socat to stay alive and handle multiple sequential connections from irssi (rather than one persistent connection), add the fork option:

    socat -T9999999 -s TCP4-LISTEN:13999,ignoreeof,reuseaddr,fork SOCKS4A:127.0.0.1:libera75jm6of4wxpxt4aynol3xjmbtxgfyjpu34ss4d7r7q2v5zrpyd.onion:6697,socksport=9050,ignoreeof

    This spawns child processes for each connection [7][3:1]. When a Tor circuit dies, that child exits, but the parent continues listening for irssi’s reconnection attempt. However, each new connection gets a fresh SOCKS negotiation, which may use different Tor circuits for each reconnect.

    3. Use a supervisor process

    For a dozen IRC hosts, manage socat instances with a process supervisor:

    # In a systemd user service or tmux/screen session
for host in host1 host2 ...; do
    while true; do
        socat -T9999999 -s TCP4-LISTEN:${port},ignoreeof,reuseaddr SOCKS4A:127.0.0.1:${onion}:6697,socksport=9050,ignoreeof
        sleep 2
    done &
done

    4. Extend Tor circuit lifetime (trade-off)

    You can reduce volatility by extending how long Tor keeps circuits open. In torrc:

    MaxCircuitDirtiness 3600  # Keep circuits for 1 hour instead of 10 minutes

    This reduces anonymity by making your traffic patterns more linkable over time, but decreases connection drops.

    Why the original approach fails

    Your current command lacks fork and uses a single process. When the SOCKS4A connection through Tor dies (circuit rotation), socat sees EOF on one address and exits—even with -s (sloppy) and ignoreeof, because a dead SOCKS connection is a fatal transport error, not just an EOF [8][7:1]. The forever option only helps with the initial connection attempt, not reconnection after success [1:1].

    The restart loop approach (option 1) is the standard solution for persistent SOCKS proxying with volatile circuits—simple, predictable, and works with irssi’s native reconnection handling.

    1. Reconnect socat connection after network failure - Stack Overflow (31%) ↩︎ ↩︎

    2. Tor traffic seems to be exiting from different Tor exit nodes (8%) ↩︎

    3. How to keep socat alive using keepalive option - Super User (6%) ↩︎ ↩︎

    4. SOCAT as a Polymorphic Networking Tool - Cybrary (6%) ↩︎

    5. reconnect - Irssi dev help page (10%) ↩︎

    6. reconnect - Irssi 1.2 help page (5%) ↩︎

    7. Ubuntu Manpage: socat - Multipurpose relay (SOcket CAT) (11%) ↩︎ ↩︎

    8. sockets - Socat not closing tcp connection - Super User (23%) ↩︎