Page MenuHomePhabricator

replace rinetd with socat
Closed, ResolvedPublic

Description

There is now a real reason to transition away from rinetd. I don't think upstream still cares about rinetd. Never got a reply to the following inquiry.

(Socat would be useful for better I2PBOX support. - https://www.whonix.org/pipermail/whonix-devel/2016-January/000501.html)


socat TCP-LISTEN:9050,fork TCP:10.137.2.1:9050

https://github.com/Whonix/anon-ws-disable-stacked-tor/blob/master/etc/rinetd.conf.anondist


Migrated from:
https://github.com/Whonix/Whonix/issues/341

Details

Impact
Normal

Event Timeline

Patrick raised the priority of this task from to Normal.
Patrick updated the task description. (Show Details)
Patrick set Impact to Normal.
Patrick added subscribers: Patrick, HulaHoop, marmarek, nrgaway.

What about iptables redirect? Isn't that enough, or some problems with it?

iptables cannot redirect local port traffic to remote ports, otherwise
these tools would not be needed.

As no crypto is used in Whonix (and generally nothing more than simple
TCP connection), I think it doesn't matter.

https://forums.whonix.org/t/retroshare-tickets/2364/2?u=patrick makes me wonder, if this whole thing should be configurable using a .d configuration folder.

https://github.com/Whonix/anon-ws-disable-stacked-tor/blob/master/usr/lib/anon-ws-disable-stacked-tor/socat-unix-sockets could be simplified. To allow arbitrary local workstation ports being redirected to the gateway, maybe the config file should just be a long list of socat commands that get executed one after another?

https://forums.whonix.org/t/retroshare-tickets/2364/2?u=patrick makes me wonder, if this whole thing should be configurable using a .d configuration folder.

Agreed.

https://github.com/Whonix/anon-ws-disable-stacked-tor/blob/master/usr/lib/anon-ws-disable-stacked-tor/socat-unix-sockets could be simplified. To allow arbitrary local workstation ports being redirected to the gateway, maybe the config file should just be a long list of socat commands that get executed one after another?

Yes would be more convenient and extendable.

HulaHoop claimed this task.

I kept this as review, since this all has to be tested again when a new build has been created.

(superseded by systemd socket activation)