LAN file transfer with netcat

Need to quickly transfer a file from one computer to another? They don't have AirDrop and you can't find a memory stick? No worries; netcat comes to the rescue. This tip works on Linux as well as OSX.

I'm going to suppose you're on the same LAN, and you want to transfer a file called photos.zip. First, open up a terminal on the receiving computer and type ifconfig|grep "inet " to find out its IP address:

$ ifconfig|grep "inet "
         inet 127.0.0.1 netmask 0xff000000
         inet 192.168.1.243 netmask 0xffffff00 broadcast 192.168.1.255
$ █

The IP address is 192.168.1.243. (We don't want 127.0.0.1, because that's a loopback address that only works locally.)

Then make netcat listen to a port by typing nc -l 12345 > photos.zip. On the sending side, type nc 192.168.1.243 12345 < photos.zip (or whatever the IP address and file name are). And magic happens!

19 comments:

  1. Ha, almost forgot this little trick, quite useful.

    Note that `ifconfig` is deprecated (if not missing already) on most linux distros nowadays. You can use `ip addr` instead.

    ReplyDelete
    Replies
    1. And I'm willing to bet you're still much more likely to find ifconfig compiled into busybox in embedded environments.

      Delete
  2. A less geeky, yet far more convenient way would be: "python -m SimpleHTTPServer" (python2) or "python -m http.server" (python3). It spawns a proper HTTP server (including directory listing) sharing the current folder.

    ReplyDelete
    Replies
    1. Or, in Perl with Plack installed:

      plackup -MPlack::App::File -e'Plack::App::File->to_app'

      Delete
  3. If, on the sending end, you don't have netcat, but do have bash, you can do `cat file.tar > /dev/tcp/192.168.1.243/12345` which redirects to a tcp socket using a crazy bash-only extension

    ReplyDelete
  4. You can use $ pv file.tar | nc 192.168.1.243 12345 to see how much magic is going on.

    ReplyDelete
  5. Okay, I have to ask:
    What's wrong with scp ?

    ReplyDelete
    Replies
    1. Once you have it all set up, nothing!

      Delete
    2. Woops, I just realised what it's actually doing.

      Easier to set-up than scp, indeed :)

      Delete
    3. No encryption overheaduseful when moving things between devices with weak CPUs.

      Delete
  6. that's what it's meant for, print wirelessy:

    nc -l 9001 >/dev/lp0

    ReplyDelete
  7. I found this to be very useful when I wanted to rescue data from a disk with no free space.

    Receiver: nc -l 7000 | tee >(sha512sum >> hash) | tar xpfz -

    Sender: tar cfp - / | gzip | tee >(sha512sum >> hash) | nc 192.168.2.7 7000

    Archiving, compression, and hashing all in one pipe.

    ReplyDelete
  8. And actually back in the days you could transfer a whole operating system (running) to another system (running livecd) byte by byte. Ofcourse this took some time and in the end it required some fsck on the first boot but it worked! :-)

    ReplyDelete
  9. Hello,

    Not only it works, but it is also very fast.

    In 2012 I needed to transfer a 40GB virtual machine from a windows host to a linux laptop. I started using the provided network infrastructure and protocols but it was estimated to takes hours (don't remember the exact duration, perhaps 3-4 hours).

    I made a bootable USB key, booted the host on that, plugged a cable between the two hosts (they were gigabyte Ethernet capable) and made the transfer using nc on both sides. The whole transfer took 10-12 minutes.

    The downside of nc is that you can't interrupt and resume but in such a situation it really doesn't matter.

    Thanks to author and commenters on this blog post, I now know several handy tricks.

    ReplyDelete
  10. If you have Nmap on Windows, it include "ncat", which is essentially the same as netcat on linux. It transfers files a lot slower though (20kb/s) compared to netcat's 200kb/s+ (both on a local network).

    ReplyDelete
  11. The best file transfer speed I could squeeze out of my local network was using uftp (http://uftp-multicast.sourceforge.net/). It was about 10 times faster than rsync over ssh. Didn't use the multicast feature, though.

    ReplyDelete

Please browse through the FAQ first, it might be that your question is already answered.

Spammers have even found comments sections, so this comments section is pre-moderated; it will take some time for the comment to show up.