Attach to stdin/stdout on each end rather than a network interface.

[guest]

Similar to ozymanDNS or dnscat (both of which are slow, buggy and unmaintained), each endpoint would attach to standard input and output which opens up countless new possibilities for using iodine, just a few of these are:

• Using pppd over the dns tunnel, for stronger authentication than simply a password.
• Forwarding single ports (via socat)
• SSH proxy command
• etc

• Jack Coulter <jscinoz@…>

[guest]

This would be a VERY nice feature indeed. It would combine the advantages of ozymandns

• no client side setup,
• no client side root access needed

with the advantages of iodine

• performance,
• multi-user,
• etc.

Maybe it would even be possible to run the iodine server in a dual-use mode where a subdomain could be dedicated to clients in stdin/stdout mode while the rest still works in TUN/TAP mode.

• Henrik <henrik-iodine@…>

[yarrick]

Yes, i have been thinking about that as well. The initial version will probably be a single-user server for stdin/stdout tunneling only but it could be improved to do tcp tunneling (for ssh) on a special subdomain and things like that.

stdout is now unused in the server and client after change [849].

[yarrick]

The hard part about this ticket is that iodine then has to handle retransmits. Right now it only provides best-effort delivery of IP frames.

[guest]

Currently iodined can not be used on OpenVZ-based virtual servers as OpenVZ does not allow tun/tap access by default.

Enabling stdin/stdout binding should fix it as one can use ssh/socks tunneling instead.