Linux.com

Feature

CLI Magic: socat

By Julien Buty on March 26, 2007 (8:00:00 AM)

Share    Print    Comments   

Socat, netcat's "twin brother," is a utility that "establishes two bidirectional byte streams and transfers data between them." It handles sockets in various ways, allowing a wide range of actions, including file transfers, port forwarding, and serial line emulation.

The socat utility is available as a binary package for the main *nix operating systems. However, since the current version, 1.6, was just released earlier this month, you might have to wait a while to get the latest and greatest, or download the source from the project's home page and install it with the usual ./configure, make, and (as root) make install commands.

Beside socat itself, the package contains a set of files, scripts, and binaries that offer examples of what socat can do. Here's an introduction to some of its capabilities.

File transfers

Even though there are more efficient methods to transmit files over a network, socat can come in handy on a freshly installed server or to process simple backups.

To transmit a file, you must run socat on the host that is receiving the file to listen for an incoming data stream. On the receiving host, run socat TCP-LISTEN:4242 filename . The TCP-LISTEN argument tells socat to listen on the port provided, and works with both IPv4 and IPv6. You can replace the port number, 4242 in this example, with any port you would like, but keep in mind that you need to run socat as root to bind a port below 1024.

To send the file, run socat TCP:hostname:4242 filename . This sends the file named "filename" to the host "hostname" through the port 4242. The hostname can be an IPv4 or IPv6 address or a fully qualified domain name (FQDN).

You can couple socat with tar to make a quick and simple backup. On the receiving host, run the same command as above. On the local server run tar czf - /folder/to/backup | socat TCP:hostname:4242 -. The hyphen after the tar option tells tar to send its output to the standard output, which is then redirected thanks to the pipe to socat.

By default only fatal and error messages are displayed. You can increase socat's debug level with the -d option, up to four times. The first level adds warning messages, the second adds info messages, and the fourth prints debug messages, such as library calls and their results. All messages can be written to stderr, a file, or to syslog.

The -b<size> option sets the data transfer block size; data will be transmitted in blocks of size bytes. The -T option can be use to set a timeout (in seconds) for when socat enters a transfer loop but nothing happens. Many others option are available; read the socat man page for additional information, or the README file located in the /usr/share/doc/ directory.

Instead of using filename in the sending command, you can use a hyphen to redirect the output to the standard out, which lets you interact with the remote host as a Telnet client does, but without some Telnet annoyances. For instance, Telnet isn't fit for use in a script and does not offer a listening mode.

Here is a way to use socat to get the date from an NTP server:

$ socat TCP:time.nist.gov:13 -
54178 07-03-19 10:42:02 50 0 0 427.6 UTC(NIST) *

Here is a way to list the most recent kernels: socat TCP:kernel.org:79 -

Port forwarding

Another interesting capability of socat is port forwarding, which allows you to route traffic from a local port to another port on a remote host.

To install a simple port forwarder, run the command socat TCP-LISTEN:80,fork TCP:www.domain.org:80 . The TCP-LISTEN argument tells socat to listen on local port 80 until a connection come in. Socat accepts it and forks it, then opens a connection on the remote host (www.domain.org in this example) and starts a data transfer. The fork option allows more than a single connection by forking a new process after each accepted connection.

Socat can also forward UDP ports with the arguments UDP and UDP-LISTEN. The command becomes socat UDP-LISTEN:80,fork UDP:www.domain.org:80 .

You can build more complex port forwarders with socat, adding security (chroot, change process uid to the nobody user, etc.), command execution on the remote host (with output displayed on the client side), proxy authentication, and more.

Serial line emulation

The command socat READLINE,history=$HOME/.cmd_history /dev/ttyS0,raw,echo=0,crnl opens an interactive connection via the serial line (/dev/ttys0 in this example). The standard input is wrapped with the GNU readline command, which gives us the same editing power as a bash shell. The raw option tells socat to leave the standard in and standard out untouched. echo=0 disables local echo, while crnl convert newline characters for a correct display.

This feature can be used to maintain a dialog with serial devices with a command-line interface. Thus, if something goes wrong with one of your serial devices, socat lets you troubleshoot.

These demonstrations of socat's capabilities only scratch its surface. Socat is a powerful tool worth adding to your administrator's toolbox.

Julien Buty is a computer science student from the International Institute of Information Technology in Paris, France.

Share    Print    Comments   

Comments

on CLI Magic: socat

Note: Comments are owned by the poster. We are not responsible for their content.

But what is it REALLY for?

Posted by: Anonymous Coward on March 26, 2007 07:21 PM

The first application you mention, moving files around, is surely much more easily (and securely) accomplished with scp.


That makes me wonder about the others. Is there any use of socat where it is clearly and unambiguously better than all alternatives? If there is, you didn't say what it is.

#

Re:But what is it REALLY for?

Posted by: Anonymous Coward on March 27, 2007 03:22 PM
...until you want to transfer a large directory tree which includes symbolic links, and want to keep symbolic links on the target system. scp does not do this (or not that I have found) - it will copy the actual file instead of recreating the symlink.

#

Re:But what is it REALLY for?

Posted by: Anonymous Coward on March 27, 2007 03:39 PM
tar cjf - something | ssh login@remote 'cd somewhere && tar xjf -'

#

Re:But what is it REALLY for?

Posted by: Anonymous Coward on March 27, 2007 04:10 PM
scp replacement for archive (keeps symlinks etc):

rsync -a -e ssh othermachine:/path/ .

works a treat, eg for snapshot backup to DVD when the remote dir has recursive symlinks.

Hamish

#

Re:But what is it REALLY for?

Posted by: Administrator on March 26, 2007 07:34 PM
Don't search for a use case that matches your tool, at least if you're not a PR guy. It's just the opposite. You'll remember this tool if you someday hit a use case for it. Making up a use case looks always a bit constructed. I doubt there will be a task that it is absolutely better at than any other software. But then, you miss another point: By using an integrated solution for those socket-related tasks, you'll only have to learn one tool.

But since you mentioned scp: Why the heck would I bother to use scp (bad suggestion, sftp is so much more reliable) with all its authorization and encryption (OK, that can be disabled) overhead when piping tar output onto a socket is absolutely sufficient and the network is trusted (e.g. a virtual one on one physical machine)? I wouldn't even bother to include 1 MB of OpenSSL goodness to my embedded devices, BTW, so there might be circumstances when SSH isn't even an option.

Oh, and by the way: netcat doesn't have readline integration, AFAIK. Not that I ever missed it...

#

Re:But what is it REALLY for?

Posted by: Anonymous Coward on March 27, 2007 06:24 AM
one man's overhead is another man's 'security feature'

#

Re:But what is it REALLY for?

Posted by: Anonymous Coward on March 27, 2007 07:29 PM
one man's overhead is another man's 'security feature'

And viceversa.

#

Re:But what is it REALLY for?

Posted by: Anonymous Coward on March 27, 2007 06:05 PM
> Why the heck would I bother to use scp (bad suggestion, sftp
> is so much more reliable)


        With SSH-2, scp gets mapped on to sftp internally. There is no reliability difference.

#

Just the tool I was looking for

Posted by: Anonymous Coward on March 28, 2007 01:54 AM
I spent a few hours looking for a toll which would allow me to tie two tty devices together. The goal here is to have two devices connected to the serial ports talk transparently to each other.

I tried some interesting things with cat, tail, netcat, etc... But they all gave me different problems.

1. Text is echoed locally and set back from the serial device.
2. Text is only sent by the line, and not by character.

Here is the socat command I used:
socat<nobr> <wbr></nobr>/dev/ttyS44,raw,echo=0,crnl<nobr> <wbr></nobr>/dev/ttyS45,raw,echo=0,crnl

#

What about rsync

Posted by: Administrator on March 28, 2007 12:01 AM
Rsync seems to be another way to accomplish the same thing as socat, no? If you use rsync again it will only copy the pieces that changed. What a deal! Makes future updates very fast indeed.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya