Unofficial Tor Community

236 readers

1 users here now

Link to tor project (they made the icon I grabbed, and tor itself of course): https://www.torproject.org/

This is a community to discuss the tor project and your experience with tor, tor browser, etc.

Rules are generally: be nice, don't be bigoted, etc.

Only seems fair that an infosec instance should have a community about one of the most well known anonymity tools :)

founded 2 years ago

MODERATORS

sapient_cogbag

Irssi over Tor glitchy and fragile. Am I doing it wrong? (lemmy.sdf.org)

submitted 2 days ago by evenwicht@lemmy.sdf.org to c/tor

1 comments fedilink hide all child comments

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?

you are viewing a single comment's thread
view the rest of the comments

[–] okwhateverdude@lemmy.world 2 points 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 [^5]), 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 [^6][^7]. When Tor rotates circuits, socat dies, the loop restarts it, and irssi reconnects automatically (irssi has built-in reconnection logic [^4][^8]).

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 [^3][^6]. 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 [^2][^3]. The forever option only helps with the initial connection attempt, not reconnection after success [^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]: sockets - Socat not closing tcp connection - Super User (23%) [^3]: Ubuntu Manpage: socat - Multipurpose relay (SOcket CAT) (11%) [^4]: reconnect - Irssi dev help page (10%) [^5]: Tor traffic seems to be exiting from different Tor exit nodes (8%) [^6]: How to keep socat alive using keepalive option - Super User (6%) [^7]: SOCAT as a Polymorphic Networking Tool - Cybrary (6%) [^8]: reconnect - Irssi 1.2 help page (5%)