Introducing nc – the network “cat”

No, not lolcat, netcat. Ever wanted to

  • see how exactly a web server responds to a HTTP request,
  • intercept and study the network traffic of a client-server program, or
  • transfer files over a network?

Well, you’ll love netcat. You give it a hostname and a port, and it connects stdin and stdout to the socket connection. You are left talking with the server:

$ nc 80 talking with the server...

Some common uses

Testing a web server:

echo -en 'GET / HTTP/1.0\r\n\r\n' | nc 80 -q 5

(The “-q 5” makes nc wait 5s for the server’s reply)

Copying a bunch of files from one machine to another: listen on port 1234 of the receiver, and connect from the sender.

recvr$ nc -l 1234 | tar xzv
sendr$ tar cz file1 file2 | nc recvr 1234

(If you use the old “netcat” program you need the -p switch in the first command to listen on a port.)

Intercepting the traffic between a client and a server gets a bit more involved. You might think that you could do something like this to spy a the Windows remote desktop connection to “remotehost”:

nc -l 3389 | tee | nc remotehost 3389 #broken

It won’t work because the pipes only work in one direction. Data from the client is passed to “remotehost,” but the data from the remote side is printed to the terminal. To solve this problem we’ll have to use named pipes:

mkfifo pin
mkfifo pout
nc -l 3389 <pin | tee >pout
nc remotehost 3389 <pout | tee rdesktop.out >pin

Now the data read from the client is saved to, and the data written to the client is saved to rdesktop.out.