verbatim from


tcpdump Tutorial and Primer

Image from

[ Check out my latest post on the HP Security Blog: “Thoughts on the Heartbleed Bug” ]

tcpdump is the premier network analysis tool for information security professionals. Having a solid grasp of this über-powerful application is mandatory for anyone desiring a thorough understanding of TCP/IP. Many prefer to use higher level analysis tools such as Ethereal Wireshark, but I believe this to usually be a mistake.

In a discipline so dependent on a true understanding of concepts vs.rote learning, it’s important to stay fluent in the underlying mechanics of the TCP/IP suite. A thorough grasp of these protocols allows one to troubleshoot at a level far beyond the average analyst, but mastery of the protocols is only possible through continued exposure to them.

When using a tool that displays network traffic a more natural (raw) way the burden of analysis is placed directly on the human rather than the application. This approach cultivates continued and elevated understanding of the TCP/IP suite, and for this reason Istrongly advocate using tcpdump instead of other tools whenever possible.

15:31:34.079416 IP (tos 0x0, ttl  64, id 20244, offset 0, flags [DF], 
proto: TCP (6), length: 60) source.35970 > dest.80: S, cksum 0x0ac1 
(correct), 2647022145:2647022145(0) win 5840 0x0000:  4500 003c 4f14 4000 
4006 7417 0afb 0257  E..  0x0010:  4815 222a 8c82 0050 9dc6 5a41 0000 
0000  H."*...P..ZA....  0x0020:  a002 16d0 0ac1 0000 0204 05b4 
0402 080a  ................  0x0030:  14b4 1555 0000 0000 0103 0302


Below are a few options (with examples) that will help you greatly when working with the tool. They’re easy to forget and/or confuse with other types of filters, i.e. ethereal, so hopefully this page can serve as a reference for you, as it does me.

First off, I like to add a few options to the tcpdump command itself, depending on what I’m looking at. The first of these is -n, which requests that names are not resolved, resulting in the IPs themselves always being displayed. The second is -X, which displays both hex and ascii content within the packet. The final one is -S, which changes the display of sequence numbers to absolute rather than relative. The idea there is that you can’t see weirdness in the sequence numbers if they’re being hidden from you. Remember, the advantage of using tcpdump vs. another tool is getting manual interaction with the packets.

It’s also important to note that tcpdump only takes the first 68 96 bytes of data from a packet by default. If you would like to look at more, add the -s number option to the mix, where number is the number of bytes you want to capture. I recommend using 0 (zero) for a snaplength, which gets everything. Here’s a short list of the options I use most:

  • -i any : Listen on all interfaces just to see if you’re seeing any traffic.
  • -n : Don’t resolve hostnames.
  • -nn : Don’t resolve hostnames or port names.
  • -X : Show the packet’s contents in both hex and ASCII.
  • -XX : Same as -X, but also shows the ethernet header.
  • -v, -vv, -vvv : Increase the amount of packet information you get back.
  • -c : Only get x number of packets and then stop.
  • -s : Define the snaplength (size) of the capture in bytes. Use-s0 to get everything, unless you are intentionally capturing less.
  • -S : Print absolute sequence numbers.
  • -e : Get the ethernet header as well.
  • -q : Show less protocol information.
  • -E : Decrypt IPSEC traffic by providing an encryption key.

[ The default snaplength as of tcpdump 4.0 has changed from 68 bytes to 96 bytes. While this will give you more of a packet to see, it still won’t get everything. Use -s 1514 to get full coverage ]

Basic Usage

So, based on the kind of traffic I’m looking for, I use a different combination of options to tcpdump, as can be seen below:

  1. Basic communication // see the basics without many options

    tcpdump -nS

  2. Basic communication (very verbose) // see a good amount of traffic, with verbosity and no name help

    tcpdump -nnvvS

  3. A deeper look at the traffic // adds -X for payload but doesn’t grab any more of the packet

    tcpdump -nnvvXS

  4. Heavy packet viewing // the final “s” increases the snaplength, grabbing the whole packet

    tcpdump -nnvvXSs 1514

Here’s a capture of exactly two (-c2ICMP packets (a ping andpong) using some of the options described above. Notice how much we see about each packet.

hermes root # tcpdump -nnvXSs 0 -c2 icmp
tcpdump: listening on eth0, link-type EN10MB (Ethernet), 23:11:10.370321 IP 
(tos 0x20, ttl  48, id 34859, offset 0, flags [none], length: 84) > icmp 64: echo request seq 0

        0x0000:  4520 0054 882b 0000 3001 7cf5 45fe d52b  E..T.+..0.|.E..+
        0x0010:  4815 222a 0800 3530 272a 0000 25ff d744  H."*..50'*..%..D
        0x0020:  ae5e 0500 0809 0a0b 0c0d 0e0f 1011 1213  .^..............
        0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
        0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
        0x0050:  3435 3637                                4567
23:11:10.370344 IP (tos 0x20, ttl  64, id 35612, offset 0, flags [none], 
length: 84) > icmp 64: echo reply seq 0
        0x0000:  4520 0054 8b1c 0000 4001 6a04 4815 222a  E..T....@.j.H."*
        0x0010:  45fe d52b 0000 3d30 272a 0000 25ff d744  E..+..=0'*..%..D
        0x0020:  ae5e 0500 0809 0a0b 0c0d 0e0f 1011 1213  .^..............
        0x0030:  1415 1617 1819 1a1b 1c1d 1e1f 2021 2223  .............!"#
        0x0040:  2425 2627 2829 2a2b 2c2d 2e2f 3031 3233  $%&'()*+,-./0123
        0x0050:  3435 3637                                4567
2 packets captured
2 packets received by filter
0 packets dropped by kernel
hermes root # 

Common Syntax

Expressions allow you to trim out various types of traffic and find exactly what you’re looking for. Mastering the expressions and learning to combine them creatively is what makes one truly powerful with tcpdump. There are three main types of expression:typedir, and proto.

Type options are hostnet, and port. Direction is indicated by dir, and there you can have srcdstsrc or dst, and src and dst. Here are a few that you should definitely be comfortable with:

    • host // look for traffic based on IP address (also works with hostname if you’re not using -n)

      tcpdump host


    • srcdst // find traffic from only a source or destination (eliminates one side of a host conversation)

      tcpdump src
      tcpdump dst


    • net // capture an entire network using CIDR notation

      tcpdump net


    • proto // works for tcp, udp, and icmp. Note that you don’t have to typeproto

      tcpdump icmp


    • port // see only traffic to or from a certain port

      tcpdump port 3389


    • src, dst port // filter based on the source or destination port

      tcpdump src port 1025
      tcpdump dst port 389


  • src/dst, port, protocol // combine all three

    tcpdump src port 1025 and tcp
    tcpdump udp and src port 53

You also have the option to filter by a range of ports instead of declaring them individually, and to only see packets that are above or below a certain size.

    • Port Ranges // see traffic to any port in a range
      tcpdump portrange 21-23


    • Packet Size Filter // only see packets below or above a certain size (in bytes)
      tcpdump less 32
      tcpdump greater 128

[ You can use the symbols for less thangreater than, and less than or equal / greater than or equal signs as well. ]

// filtering for size using symbols

    tcpdump > 32

      tcpdump <= 128

      Writing to a File

      tcpdump allows you to send what you’re capturing to a file for later use using the -w option, and then to read it back using the -roption. This is an excellent way to capture raw traffic and then run it through various tools later.

      The traffic captured in this way is stored in tcpdump format, which is pretty much universal in the network analysis space. This means it can be read in by all sorts of tools, including WiresharkSnort, etc.

      Capture all Port 80 Traffic to a File

      tcpdump -s 1514 port 80 -w capture_file

      Then, at some point in the future, you can then read the traffic back in like so:

      Read Captured Traffic back into tcpdump

      tcpdump -r capture_file

      Getting Creative

      Expressions are nice, but the real magic of tcpdump comes from the ability to combine them in creative ways in order to isolate exactly what you’re looking for. There are three ways to do combinations, and if you’ve studied computers at all they’ll be pretty familar to you:

      1. AND
        and or &&
      2. OR
        or or ||
      3. EXCEPT
        not or !

      More Examples

      # TCP traffic from destined for port 3389

      tcpdump -nnvvS and src and dst port 3389

      # Traffic originating from the 192.168 network headed for the 10 or 172.16 networks

      tcpdump -nvX src net and dst net or172.16.0.0/16

      # Non-ICMP traffic destined for from the 172.16 network

      tcpdump -nvvXSs 1514 dst and src net and not icmp

      # Traffic originating from Mars or Pluto that isn’t to the SSH port

      tcpdump -vv src mars and not dst port 22

      As you can see, you can build queries to find just about anything you need. The key is to first figure out precisely what you’re looking for and then to build the syntax to isolate that specific type of traffic.


      Also keep in mind that when you’re building complex queries you might have to group your options using single quotes. Single quotes are used in order to tell tcpdump to ignore certain special characters — in this case the “( )” brackets. This same technique can be used to group using other expressions such as hostportnet, etc. Take a look at the command below:

      # Traffic that’s from AND destined for ports 3389 or 22(incorrect)

      tcpdump src and (dst port 3389 or 22)

      If you tried to run this otherwise very useful command, you’d get an error because of the parenthesis. You can either fix this by escaping the parenthesis (putting a before each one), or by putting the entire command within single quotes:

      # Traffic that’s from AND destined for ports 3389 or 22(correct)

      tcpdump ‘src and (dst port 3389 or 22)’


      You can also filter based on specific portions of a packet, as well as combine multiple conditions into groups. The former is useful when looking for only SYNs or RSTs, for example, and the latter for even more advanced traffic isolation.

      [ Hint: An anagram for the TCP flags: Unskilled Attackers Pester RealSecurity Folk ]

      Show me all URGENT (URG) packets…

      # tcpdump ‘tcp[13] & 32!=0

      Show me all ACKNOWLEDGE (ACK) packets…

      # tcpdump ‘tcp[13] & 16!=0

      Show me all PUSH (PSH) packets…

      # tcpdump ‘tcp[13] & 8!=0

      Show me all RESET (RST) packets…

      # tcpdump ‘tcp[13] & 4!=0

      Show me all SYNCHRONIZE (SYN) packets…

      # tcpdump ‘tcp[13] & 2!=0

      Show me all FINISH (FIN) packets…

      # tcpdump ‘tcp[13] & 1!=0

      Show me all SYNCHRONIZE/ACKNOWLEDGE(SYNACK) packets…

      # tcpdump ‘tcp[13]=18

      [ Note: Only the PSH, RST, SYN, and FIN flags are displayed in tcpdump‘s flag field output. URGs and ACKs are displayed, but they are shown elsewhere in the output rather than in the flags field ]

      Keep in mind the reasons these filters work. The filters above find these various packets because tcp[13] looks at offset 13 in the TCP header, the number represents the location within the byte, and the !=0 means that the flag in question is set to 1, i.e. it’s on.

      As with most powerful tools, however, there are multiple ways to do things. The example below shows another way to capture packets with specific TCP flags set.

      Capture TCP Flags Using the tcpflags Option…

      # tcpdump ‘tcp[tcpflags] & & tcp-syn != 0

      Specialized Traffic

      Finally, there are a few quick recipes you’ll want to remember for catching specific and specialized traffic, such as IPv6 and malformed/likely-malicious packets.

      IPv6 traffic

      # tcpdump ip6

      Packets with both the RST and SYN flags set (why?)

      # tcpdump ‘tcp[13] = 6’

      Traffic with the ‘Evil Bit’ Set

      # tcpdump ‘ip[6] & 128 != 0


      Well, this primer should get you going strong, but the man pageshould always be handy for the most advanced and one-off usage scenarios. I truly hope this has been useful to you, and feel free tocontact me if you have any questions. ::



      verbatim from

      tcpdump command is also called as packet analyzer.

      tcpdump command will work on most flavors of unix operating system. tcpdump allows us to save the packets that are captured, so that we can use it for future analysis. The saved file can be viewed by the same tcpdump command. We can also use open source software like wireshark to read the tcpdump pcap files.

      In this tcpdump tutorial, let us discuss some practical examples on how to use the tcpdump command.

      1. Capture packets from a particular ethernet interface using tcpdump -i

      When you execute tcpdump command without any option, it will capture all the packets flowing through all the interfaces. -i option with tcpdump command, allows you to filter on a particular ethernet interface.

      $ tcpdump -i eth1
      14:59:26.608728 IP > . ack 540 win 16554
      14:59:26.610602 IP >  4278 1/0/0 (73)
      14:59:26.611262 IP >  26364+ PTR? (45)

      In this example, tcpdump captured all the packets flows in the interface eth1 and displays in the standard output.

      NoteEditcap utility is used to select or remove specific packets from dump file and translate them into a given format.

      2. Capture only N number of packets using tcpdump -c

      When you execute tcpdump command it gives packets until you cancel the tcpdump command. Using -c option you can specify the number of packets to capture.

      $ tcpdump -c 2 -i eth0
      listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
      14:38:38.184913 IP > P 1457255642:1457255758(116) ack 1561463966 win 63652
      14:38:38.690919 IP > P 116:232(116) ack 1 win 63652
      2 packets captured
      13 packets received by filter
      0 packets dropped by kernel

      The above tcpdump command captured only 2 packets from interface eth0.

      Note: Mergecap and TShark: Mergecap is a packet dump combining tool, which will combine multiple dumps into a single dump file. Tshark is a powerful tool to capture network packets, which can be used to analyze the network traffic. It comes with wireshark network analyzer distribution.

      3. Display Captured Packets in ASCII using tcpdump -A

      The following tcpdump syntax prints the packet in ASCII.

      $ tcpdump -A -i eth0
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
      listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
      14:34:50.913995 IP > P 1457239478:1457239594(116) ack 1561461262 win 63652
      14:34:51.423640 IP > P 116:232(116) ack 1 win 63652

      Note: Ifconfig command is used to configure network interfaces

      4. Display Captured Packets in HEX and ASCII using tcpdump -XX

      Some users might want to analyse the packets in hex values. tcpdump provides a way to print packets in both ASCII and HEX format.

      $tcpdump -XX -i eth0
      18:52:54.859697 IP > . ack 232 win 16511
              0x0000:  0050 569c 35a3 0019 bb1c 0c00 0800 4500  .PV.5.........E.
              0x0010:  0028 042a 4000 7906 c89c 10b5 aaf6 0f9a  .(.*@.y.........
              0x0020:  69c4 f999 0016 57db 6e08 c712 ea2e 5010  i.....W.n.....P.
              0x0030:  407f c976 0000 0000 0000 0000            @..v........
      18:52:54.877713 IP > igmp query v3 [max resp time 1s]
              0x0000:  0050 569c 35a3 0000 0000 0000 0800 4600  .PV.5.........F.
              0x0010:  0024 0000 0000 0102 3ad3 0a00 0000 e000  .$......:.......
              0x0020:  0001 9404 0000 1101 ebfe 0000 0000 0300  ................
              0x0030:  0000 0000 0000 0000 0000 0000            ............

      5. Capture the packets and write into a file using tcpdump -w

      tcpdump allows you to save the packets to a file, and later you can use the packet file for further analysis.

      $ tcpdump -w 08232010.pcap -i eth0
      tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
      32 packets captured
      32 packets received by filter
      0 packets dropped by kernel

      -w option writes the packets into a given file. The file extension should be .pcap, which can be read by any network protocol

      6. Reading the packets from a saved file using tcpdump -r

      You can read the captured pcap file and view the packets for analysis, as shown below.

      $tcpdump -tttt -r data.pcap
      2010-08-22 21:35:26.571793 00:50:56:9c:69:38 (oui Unknown) > Broadcast, ethertype Unknown (0xcafe), length 74:
              0x0000:  0200 000a ffff 0000 ffff 0c00 3c00 0000  ............<...
              0x0010:  0000 0000 0100 0080 3e9e 2900 0000 0000  ........>.).....
              0x0020:  0000 0000 ffff ffff ad00 996b 0600 0050  ...........k...P
              0x0030:  569c 6938 0000 0000 8e07 0000            V.i8........
      2010-08-22 21:35:26.571797 IP > P 800464396:800464448(52) ack 203316566 win 71
      2010-08-22 21:35:26.571800 IP > P 52:168(116) ack 1 win 71
      2010-08-22 21:35:26.584865 IP > NBT UDP PACKET(137): QUERY; REQUEST; BROADC

      7. Capture packets with IP address using tcpdump -n

      In all the above examples, it prints packets with the DNS address, but not the ip address. The following example captures the packets and it will display the IP address of the machines involved.

      $ tcpdump -n -i eth0
      15:01:35.170763 IP > P 105:157(52) ack 18060 win 16549
      15:01:35.170776 IP > P 23988:24136(148) ack 157 win 113
      15:01:35.170894 IP > P 24136:24380(244) ack 157 win 113

      8. Capture packets with proper readable timestamp using tcpdump -tttt

      $ tcpdump -n -tttt -i eth0
      2010-08-22 15:10:39.162830 IP > . ack 49800 win 16390
      2010-08-22 15:10:39.162833 IP > . ack 50288 win 16660
      2010-08-22 15:10:39.162867 IP > . ack 50584 win 16586

      9. Read packets longer than N bytes

      You can receive only the packets greater than n number of bytes using a filter ‘greater’ through tcpdump command

      $ tcpdump -w g_1024.pcap greater 1024

      10. Receive only the packets of a specific protocol type

      You can receive the packets based on the protocol type. You can specify one of these protocols — fddi, tr, wlan, ip, ip6, arp, rarp, decnet, tcp and udp. The following example captures only arp packets flowing through the eth0 interface.

      $ tcpdump -i eth0 arp
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
      listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
      19:41:52.809642 arp who-has tell
      19:41:52.863689 arp who-has tell
      19:41:53.024769 arp who-has tell

      11. Read packets lesser than N bytes

      You can receive only the packets lesser than n number of bytes using a filter ‘less’ through tcpdump command

      $ tcpdump -w l_1024.pcap  less 1024

      12. Receive packets flows on a particular port using tcpdump port

      If you want to know all the packets received by a particular port on a machine, you can use tcpdump command as shown below.

      $ tcpdump -i eth0 port 22
      19:44:44.934459 IP > P 18932:19096(164) ack 105 win 71
      19:44:44.934533 IP > P 19096:19260(164) ack 105 win 71
      19:44:44.934612 IP > P 19260:19424(164) ack 105 win 71

      13. Capture packets for particular destination IP and Port

      The packets will have source and destination IP and port numbers. Using tcpdump we can apply filters on source or destination IP and port number. The following command captures packets flows in eth0, with a particular destination ip and port number 22.

      $ tcpdump -w xpackets.pcap -i eth0 dst and port 22

      14. Capture TCP communication packets between two hosts

      If two different process from two different machines are communicating through tcp protocol, we can capture those packets using tcpdump as shown below.

      $tcpdump -w comm.pcap -i eth0 dst and port 22

      You can open the file comm.pcap using any network protocol analyzer tool to debug any potential issues.

      15. tcpdump Filter Packets – Capture all the packets other than arp and rarp

      In tcpdump command, you can give “and”, “or” and “not” condition to filter the packets accordingly.

      $ tcpdump -i eth0 not arp and not rarp
      20:33:15.479278 IP >  26929 1/0/0 (73)
      20:33:15.479890 IP >  56556+ PTR? (45)
      20:33:15.480197 IP > P 540:1504(964) ack 1 win 96
      20:33:15.487118 IP > . ack 540 win 16486
      20:33:15.668599 IP > igmp query v3 [max resp time 1s]

      Crashplan backup server on the pi

      Complete credit to


      These are my personal notes on getting Crashplan up and running on a Raspberry Pi running Wheezy 2015-05-05. Some words may be copied straight out from the above two threads so full credit to them – THIS IS NOT MY WORK!

      REPEAT : This is NOT MY work, only my process for personal notes!

      Step 1 : Installing Raspian Wheezy

      First download the image file from:


      Then, if running from Windows download the disk imaging tool:


      Image the disk using the tool!


      Connect up the Pi and boot up for the raspi-config splash screen.


      Step 2 : Configuring the Pi

      I’m a newbie still but this is how I decided to configure the pi:

      1. Expand file system
      2. Overclock : Medium
      3. Enable SSH
      4. Exit raspi-config
      5. Add Public keys for ssh access to ~/.ssh/authorized_keys , more info
      6. Create iptables rules to provide some limits,  this is achieved by
        iptables-restore < yourIptableFileHere

        a yourIptableFileHere example:

        # Generated by iptables-save v1.4.21 on Sat May 23 13:51:53 2015
        # Loopback accept
        -A INPUT -s -i lo -j ACCEPT
        -A INPUT -d -j REJECT --reject-with icmp-port-unreachable
        # Accept established
        -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
        # ACCEPT SSH
        -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
        # Accept incoming for Crashplan 4242
        -A INPUT -p tcp --dport 4242 -j ACCEPT
        -A INPUT -p udp --dport 4282 -j ACCEPT
        # accept local network
        -A INPUT -s x.x.x.x/24 -j ACCEPT
        -A INPUT -s x.x.x.x/24 -p icmp -j ACCEPT
        # Log all other attempts limit to 5 mins
        -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
        # limit ssh attempts in particular
        -A INPUT -p tcp --syn --dport 3333 -m connlimit --connlimit-above 3 -j REJECT
        # also http
        -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 20 -j REJECT --reject-with tcp-reset
        # Drop everything else
        -A INPUT -j DROP
        -A FORWARD -j DROP
        # Allow outbound
        -A OUTPUT -j ACCEPT
      7. Install iptables-persistent when you’re happy with the ruleset
      8. [Optional] Change your SSH port to match ruleset

      Step 3 : Preparing the storage

      The Crashplan application can be quite intense on the disk and the pi’s default swap file on the SD card is not going to cut it.

      First thing I did was move the swap file to a 2GB USB drive attached to the Pi.

      1. Get the device location of the USB drive:
        sudo dmesg

        My drive had an entry for “VERBATIM STORE N GO”, further down I saw it listed as



      2. Format the drive as ext4 :
        sudo mkfs.ext4 /dev/sda1 -L usbswap


      3. Create the directory to mount the drive :
        sudo mkdir /media/usbswap
      4. Mount the directory:
        sudo mount -t ext4 /dev/sda1 /media/usbswap

        then check for errors :

        ls -l /media/usbswap


      1. I have this working on a Raspberry Pi Model B. Started with the NOOBS 8G SD Card. I used information from above, the Oracle Java 1.7 post, and several other pages to build a Pi with 1TB WD Passport attached. My MacBook Air has been backing up to it for over an hour so far with no issues. Many thanks to Jon Rogers, Bion, Brad Peterson, and others for contributions toward getting this done.
      I am posting my documentation which sections just duplicate some of the above post and comments. There are some differences and I also document setting up the USB drive, etc. all in one place in case it helps someone. Rather than use a variable like path/to/swapfile, I use the real names in case someone will benefit from an actual example. Make sure you adjust accordingly.
      CrashPlan (headless) on Raspberry Pi
      Using the NOOBS v1.2.1 SD on a B Model with 512Mb
      Using a WD MyPassport 1TB NTFS USB Drive formerly on a Windows 7 box
      Install Raspbian (default selection in NOOBS)
      The unit will boot into raspi-config, choose option 8, advanced options
      Choose option A5, Update this tool to the latest version
      Set Keyboard, Locale, and Timezone if not UK:
      Choose option 4, Internationalization Options
      Choose I1, Change Locale, and follow the prompts (e.g. en_US.UTF-8 UTF-8)
      Choose I2, Change Timezone, and follow the prompts
      Choose I3, Change Keyboard, and follow the prompts
      Optional, set host name (good if you have multiple units):
      Return to option 8, advanced options
      Select A2, Hostname
      Optional, overclock the unit:
      Select option 7, Overclock
      Select Modest for a 14% boost in MHz with no overvolt to start or no overclock. Get it working first so you know if the overclock is the culprit if you have problems.
      Select Finish when done with configuration options and allow a reboot.
      Install GIT (in case the newest version is not installed – mine was up to date):
      sudo apt-get install git-core
      Install Update Tool (in case the newest version is not installed – mine was up to date):
      sudo apt-get install rpi-update
      Upgrade Firmware (this can take some time):
      sudo rpi-update
      Check Firmware (mine was June 17 2013 20:49:11):
      sudo vcgencmd version
      sudo reboot
      Recheck Firmware (mine was Jan 10 2014 16:58:06):
      sudo vcgencmd version
      If you haven’t already, mount your USB drive.
      Find your drive’s location:
      sudo dmesg
      I found the entries associated with the drive as it came up “Direct-Access WD My Passport…”
      Following this down, I can see it is sda: sda1
      If necessary, format the drive, ext4 is recommended:
      sudo mkfs.ext4 /dev/sda1 -L cpusb01
      To mount the USB drive, create a directory in mnt:
      sudo mkdir /media/usbhd
      Mount the directory:
      sudo mount -t ext4 /dev/sda1 /media/usbhd
      If no errors, you should be able to do a directory listing on the mounted volume:
      ls -l /media/usbhd
      Note: to unmount the drive (before unplugging) issue the following command:
      sudo umount /media/usbhd
      Since I plan to leave this drive attached as a primary backup volume, I want to automount it on reboot. Because I may add more USB drives in the future, the safest way to mount the drives is using its Unique Identifier (UUID).
      To find the UUID, enter this command:
      ls -laF /dev/disk/by-uuid
      This gave me the following (this drive only):
      F474B7AA74B76DCC -> ../../sda1
      I then modify /etc/fstab to mount this drive automatically:
      sudo vi /etc/fstab
      I append this line:
      UUID=F474B7AA74B76DCC /media/usbhd ntfs nofail,user,auto,rw 0 0
      After saving and quitting (:wq), I test it manually by first unmounting:
      sudo umount /media/usbhd
      And then mounting with:
      sudo mount -a
      This mounts the drive using the entry in /etc/fstab.
      Test to be sure:
      ls -l /media/usbhd
      Thanks to Brad Peterson (above): Raspbian by default will have 100MB swap on the SD card. This is not a good idea. It is small and it will kill the SD card. Since we have an external USB drive attached as backup media, we will use this for swap instead.
      Initial setup (the first command may take a while with no feedback, be patient):
      sudo dd if=/dev/zero of=/media/usbhd/swapfile bs=1M count=1024
      sudo mkswap /media/usbhd/swapfile
      sudo chown root:root /media/usbhd/swapfile
      sudo chmod 0600 /media/usbhd/swapfile
      Add the additional swap space just created (takes a while as well):
      sudo swapon /media/usbhd/swapfile
      Verify the additional swap space:
      free -h
      This should now report 1.1G
      Now we make it mount at boot time.
      sudo vi /etc/fstab
      Insert the following after the USB mount:
      /media/usbhd/swapfile swap swap defaults 0 0
      Reboot and see if it is still 1.1G
      sudo reboot
      free -h
      Now to stop Raspbian from creating the 100M swap on the SD card:
      sudo apt-get purge dphys-swapfile
      Reboot again and validate only 1G of swap:
      sudo reboot
      free -h
      Now on to installing Java. We are going to try Oracle Java since it offers significant performance advantages over OpenJDK on ARM platforms. Courtesy of eben at
      sudo apt-get update && sudo apt-get install oracle-java7-jdk
      Download CrashPlan for Linux and extract it:
      tar -xvf CrashPlan_3.5.3_Linux.tgz
      Install CrashPlan (important: install as root and from the CrashPlan-install directory – I got several errors trying to run it using Crashplan-install/
      su (if you haven’t set the root password, usesudo psswd)
      cd CrashPlan-install
      ** Make sure you change the default backup directory to /media/usbhd/crashplan/
      Start the CrashPlan Engine:
      sudo /usr/local/crashplan/bin/CrashPlanEngine start
      Validate it is running:
      /usr/local/crashplan/bin/CrashPlanEngine status
      It will crash because included by CrashPlan is compiled for 32-bit Intel which will not run on an ARM processor. Here is the fix:
      Download the patched libjtux and md5 library, courtesy of Jon Rogers.
      Extract as necessary and copy the .so files to /usr/local/crashplan/ replacing the files that are there.
      sudo apt-get install libjna-java
      Now, per Bion’s post, edit /usr/local/crashplan/bin/CrashPlanEngine and find the line that begins with FULL_CP= (its around the start case) add this to the beginning of the string:
      Start the CrashPlan Engine again:
      sudo /usr/local/crashplan/bin/CrashPlanEngine start
      Validate it is running:
      /usr/local/crashplan/bin/CrashPlanEngine status
      Next we move on to running a remote client. I am not going to detail this since CrashPlan has it detailed on one page here:

      2. Greg Aldrich says:
      01/11/2014 AT 12:28 PM
      I have multiple edits for this commentary.
      For the formatting of the USB drive, I had an old volume name in there as I ran through this process twice. Where I wrote:
      sudo mkfs.ext4 /dev/sda1 -L cpusb01
      The cpusb01 should be usbhd to be consistent with the rest of the document or this will look like it’s working but will fail once you start backing up (because your swap and backup location will be on the SD card).
      That line should read:
      sudo mkfs.ext4 /dev/sda1 -L usbhd
      I tested this all again and it worked. I am getting over 80 Mbps right now and I do plan to go back and experiment with overclocking.
      One other thing I found which may be helpful was in:
      You will find the following line:
      I edited mine to:
      If it is a fresh install, that is it. If you already have a cache built up, you will want to move that before you restart the service.
      The same goes for the log files. You will find “/usr/local/crashplan/log/xxxx.log” entries in as well.
      Finally, the headless client link was missing a quotation mark. The last sentence should have read:
      Next we move on to running a remote client. I am not going to detail this since CrashPlan has it detailed on one page here.



      OPTION 2:

      Copied from for posterity! 🙂

      Update 2016/05/17

      If you tried recently to install CrashPlan and it failed, or wouldn’t stay running for very long, it looks like the most recent installer has fixed whatever was broken. The current download from Code42’s site should be version 4.7 or newer, and readers are reporting that all is well again.

      If, like me, a previous auto-update broke your existing installation, then I suggest uninstalling CrashPlan like this (From memory, forgive me if I get something wrong)

      cd /mnt/data/public/downloads/crashplan-install
      sudo ./uninstall -i /usr/local/crashplan

      Then download and install the latest version from Code42. You’ll need to repeat all of the steps in this article, but as long as you point the backups to the same directory you were using before, CrashPlan should pick them up and continue using them, so you don’t have to start completely over. You will need to reinstall and re-patch the UI, and then sign in to your account again, just like the first time around.

      Updated 2015/02/07:

      Recently, Code42 (CrashPlan’s developer) updated their installation files, and the instructions in this article stopped working. Thanks to the work of several readers (see the comments), I’ve been able to revisit this article and update the instructions so that they work once again.

      See the end of this article for additional troubleshooting information if you find that your installation mysteriously stops working one day.


      One of the main jobs of a proper “home server” is to back up the other computers on the network. You could accomplish this through the file shares I covered earlier in the series, but I’d like to try something a little more ambitious.

      There’s a great product out there called “CrashPlan” ( The company has subscription offerings that will store your backups in their “cloud”, similar to other products like Carbonite (, but if you can supply your own storage, CrashPlan is free.

      The free version of CrashPlan can back up to a local drive on the same computer, or to another computer that is also running CrashPlan. Your Raspberry Pi Home Server can be that “other computer”, and handle the backups for all of the computers in your house.

      Note: It is possible to get CrashPlan to backup to a share on your local network, too, but it involves jumping through some symbolically-linked hoops, and won’t be covered here.


      I didn’t figure all this stuff out on my own, not by a long shot. I am standing on the shoulders of other geeks here. In 2012, Jon Rogers wrote a blog post about getting CrashPlan running on the Raspberry Pi. That article is largely the basis for this one.

      In February of 2013, Bion Ren posted an updated version of Jon’s instructions, replacing OpenJDK with Oracle’s Java 8 preview. He also called attention to a post by Torbjörn that solves a major configuration issue, and a comment by Brad Peterson that addresses a rather serious stability issue with regards to swap file use.

      I am posting this because I wanted to gather together a complete, updated set of end-to-end instructions for adding CrashPlan to the Raspberry Pi Home Server I’ve been describing in this series. As I have pointed out before, I am by no means a Linux expert. I could not have done this without the work of those that went before me.

      Before you start

      CrashPlan was not written with tiny computers like the Raspberry Pi in mind. It expects to be running on a computer with more resources in general, and more memory in particular. When it doesn’t have enough memory, it will start paging to the swap file. Whether or not this will wear out your SD card is a rather contentious subject, and I’m not going to pretend that I know the answer to that one. One thing is for sure, though, SD card-based swap files are slow.

      As a result, I cannot recommend running CrashPlan on a Raspberry Pi unless you have moved your swap file (and I recommend your root filesystem as well) onto a proper hard drive as covered in my “Adding a hard drive” post. If you skipped that article, this isn’t going to work for you. The SD card just doesn’t have enough space to hold backups. In order to serve as a useful CrashPlan backup destination, you’re going to have to have a big hard drive anyway, so you may as well take full advantage of it.

      In addition, CrashPlan does some pretty heavy lifting in the background, compressing and pruning backups, and doing general housekeeping. This can use a lot of CPU, and make the rest of your server’s functions slow to respond. As I’m writing this, my own CrashPlan instance is using up about 60% of my CPU time compressing backups from my primary computer. CrashPlan is usually pretty good at getting out of the way when other programs need to think, at least on the desktop.



      CrashPlan runs on Java, which means it can run on anything with a Java runtime. Current Raspbian images (2015-01-31 at the time of this update) already include the Java Runtime, version 8. You can check this by typing the following at the command line:

      java –version

      If it says “1.8.0” or above, you’re all set to go. If not, you may need to install the Java Runtime Engine (JRE) yourself. Unfortunately, I can’t find a simple JRE installer for the raspberry pi at this time, so you’ll just have to install the whole Java Development Kit (JDK). Only do this if you don’t already have JRE8, as checked in the last step.

      sudo apt-get install oracle-java8-jdk

      There is an additional piece you’ll need in order for CrashPlan to work. According to a user called Torbjörn on the CrashPlan forums, you’ll also need the Java Native Access (JNA) library. Install them both at once like this:

      sudo apt-get install libjna-java

      When the Java installation completes, you are ready to install CrashPlan itself.

      Get the CrashPlan installer

      Since there are new versions being released all the time, I can’t give you a simple url to “wget”. Go to, from a browser on the Pi itself, and the download should start automatically. I used the new “Web” browser that’s part of the Raspbian image, so the file ended up in /home/pi/Downloads. Depending on your browser, your downloads may go somewhere else. If you can’t figure out where they are going, just download the package from your primary computer, and copy it over on a flash drive.

      When the download is complete, find the .tgz file and extract it. Since I was already in the desktop environment to run the browser, I took advantage of the modern amenities, right-clicked the file and picked “Extract here” from the context menu. Sometimes it’s nice to live in the future, if only for a moment.

      If you want to do it from the command line, go to the folder where your .tgz file is:

      cd /mnt/data/Downloads

      …and type the following:

      tar zxvf FILENAME.tgz

      Install CrashPlan

      Navigate to the folder where you just extracted the installer (Note: your folder may be different):

      cd ~/Downloads/CrashPlan-install

      Execute the installer from the command line.

      sudo ./

      The install script will prompt you for anything it needs, including accepting a really long EULA that you probably won’t really read (q exits the reader). You can accept most of the defaults and let the installer create any missing folders, but one directory you should probably change is the backup location.

      Unless you are backing up something very very small, like another Raspberry Pi, the root partition is not going to be big enough to hold the files. Change the backup location to somewhere on the data partition. I set mine to “/mnt/data/CrashPlan”, and let the installer create the folder. You’ll get a summary and a confirmation prompt like this:


      Double check all of your values, and then let the installer go. It’s a surprisingly fast installation. If there were no problems, you should see a confirmation like this:


      At this point, you have CrashPlan installed, but it’s not very happy. Although the installer says the engine is installed and running, it’s actually not. You can check on the status of the CrashPlan service like this:

      service crashplan status

      The answer will probably say “CrashPlan Engine is stopped.”, and even if you try to start is manually, checking its status will still say “stopped”.

      The trouble is that the installer downloaded it’s own private copy of the Java Runtime Engine, version 7 (JRE7). Normally, this would just be an irritating waste of storage space, having multiple copies of the JRE around, but the one CrashPlan installed isn’t even the right architecture. The CrashPlan installer has installed a JRE that assumes it’s on a desktop processor, specifically something i586-ish (Pentium, Core, etc.)

      Don’t worry about it if you don’t know what that means. All it means to us is that we’re going to have to trick CrashPlan into running on the JRE that’s already on the Pi, instead of the one it installed itself. Thanks to Rainer Boehme and Matt for showing me this in the comments.

      The first order of business is to blow away the useless x86 version of JRE7.

      sudo rm -r /usr/local/crashplan/jre

      Next, we’ll create a “symbolic link”, which is a kind of shortcut on your hard drive. Symbolic links make things in one place appear to be somewhere else, or even in multiple places. You can use them to keep one physical copy of a file, but have it appear in many different places. Here, we’re going to use one to make the raspberry pi-friendly JRE8 appear where CrashPlan put its raspberry-unfriendly JRE7.

      sudo ln -s /usr/lib/jvm/jdk-8-oracle-arm32-vfp-hflt /usr/local/crashplan/jre

      Patch CrashPlan to work on the Pi

      CrashPlan is now installed, but it’s not very happy. If you were to look in the/usr/local/crashplan/log/engine_error.log file right now, you’d see a complaint about the /usr/local/crashplan/ file being the wrong version. Luckily for us, Jon Rogers already fixed that problem.

      Return to the terminal, and go to the /usr/local/crashplan folder where you will find the file in question.

      Remove the bad file, and replace it with the one that Jon Rogers patched.

      cd /usr/local/crashplan
      sudo rm
      sudo wget

      There’s also something wrong with the libmd5.s0 file, so replace that one the same way.

      sudo rm
      sudo wget -O ./


      These two files should allow the CrashPlan engine to start up.

      Next, edit the CrashPlanEngine file.

      sudo nano /usr/local/crashplan/bin/CrashPlanEngine

      Find (ctrl-w) the line that starts with “FULL_CP=”, and add “/usr/share/java/jna.jar:” (don’t forget the colon) to the beginning of the string value.


      Exit nano, saving the file (ctrl-x,y,enter)

      Start CrashPlan

      To check whether everything is working, try launching CrashPlan manually.

      sudo service crashplan start
      sudo service crashplan status

      If everything went well, you should get a message indicating that the CrashPlan service is running.


      Configure CrashPlan to auto-start

      Having a backup system like CrashPlan won’t do you much good if it doesn’t start back up again after your power goes out. Type the following command to automatically configure CrashPlan to auto-start after a reboot.

      sudo update-rc.d crashplan defaults

      To make sure that it worked, reboot the Raspberry Pi, log back in, and check the status of the service. It should be running.

      sudo reboot
      sudo service crashplan status


      Patch the CrashPlan UI

      At this point, you have a working CrashPlan server, but no way to communicate with it. You need to get a GUI talking to the CrashPlan engine so that you can configure backups, change preferences, and generally fiddle with the knobs.

      LiquidState has a very detailed walkthrough of configuring CrashPlan to answer to a UI running on a different computer. If that’s how you want to do things, then go ahead, but it’s not that much harder to get the UI running on the Pi’s own X desktop.

      If you were to try the CrashPlan icon that the installer has placed on your X desktop right now, it wouldn’t work because the version of the Standard Widget Toolkit (SWT) library that CrashPlan installed won’t work on the Raspberry Pi. You can double-click that icon all day and it will never get you anywhere until we fix this problem.

      Install a compatible version of the SWT library like this:

      sudo apt-get install libswt-gtk-3-java libswt-cairo-gtk-3-jni

      Next, replace the SWT library that CrashPlan installed with the compatible one.

      sudo cp /usr/lib/java/swt-gtk-3.8.2.jar /usr/local/crashplan/lib/swt.jar

      Note: The version of this file is subject to change, so if the command complains, use tab-completion to help find the correct filename. Type up to “/usr/lib/java/swt” and then hit the Tab key to fill in the rest. This file has changed more than once since this article was first published.

      You can now run the CrashPlan UI directly from the shortcut the installer put on your X desktop. The first run can be pretty slow, so give it some time.

      You’ll either need to connect to an existing CrashPlan account, or create a new one. It’s been so long since I signed up, that I honestly couldn’t walk you through the steps anymore, but all you’re going to need is what’s included in the free version.

      Back up your stuff

      Now that you have a CrashPlan server, it’s time to start backing things up. Install the CrashPlan software on the computer you want to back up, and open the UI. Sign in using the same account information you used above.

      From here on, it’s just business as usual. Choose what you want to back up, and select “another computer” for the destination. If you signed in with the same account on the client and server, they should see each other in the list, and you can pick the Raspberry Pi as your backup location.

      If your computers have trouble seeing each other, I’d suggest looking in the supportsection of the CrashPlan site. CrashPlan does a pretty good job of opening its own firewall holes via UPnP, but perhaps your router doesn’t support that, or maybe you’ve turned it off on purpose. Such networking issues are beyond the scope of this article. Your mileage may vary. Google is your friend.

      Warning: The first time you back up another computer it will take a very long time, and it’s going to peg the Raspberry Pi’s CPU, just like when MiniDLNA was indexing your media. Don’t worry, you’re not going to hurt the Pi. Mine was at 100% CPU usage for more than a day, and the CPU temperature never rose above 64°C. As long as the temperature stays below 80°C, you have nothing to worry about. Subsequent backups will also run up the CPU, but not for nearly as long.

      The CrashPi: Secure, off-site backups

      Now we come to the real payoff, and the part that’s going to keep your stuff safe in the event of a fire or flood. When you use CrashPlan to back up to another computer, that other computer does not have to be on the same local network as the computer it’s backing up. It can be anywhere on the internet. It could be on the other side of town, or in a different state.

      A Raspberry Pi is cheap enough that you could just Velcro one to the side of a big USB drive and leave the whole thing at a buddy’s house. If your buddy does the same, and parks a CrashPi (as I am now calling it) at your house, then you’ll both be protected in the event of a disaster… unless, of course, you live in the same apartment building. You should choose a location for your off-site backups that is far enough away that both sites are unlikely to fall victim to the same disaster.

      To build a CrashPi, all you need to do is build another Raspberry Pi Home Server, leaving out all the parts that CrashPlan doesn’t need, which is actually most of them. Follow this subset of the Raspberry Pi Home Server blog series, and you’ll have made a CrashPi.

      1. Installing the OS:
        Start with a small, cheap SD card. You only need 4GB.
      2. Configuring the OS:
        If you want SSH access to maintain the CrashPi remotely, your buddy will have to punch a hole in the firewall, or put the CrashPi in his/her DMZ.
      3. Web Administration: (Optional)
        This will let you check in on your CrashPi to perform maintenance, install updates, etc.
        Your buddy will have to punch a hole in the firewall, or put the CrashPi in his/her DMZ.
      4. This post:

      You may have noticed something CrashPlan calls a “backup code”. This is a unique code that identifies a specific CrashPlan installation. You can give this code to a friend to let them back things up to your server, even though you have different accounts. For instance, when the kids head off to college, you might want to let them use your Raspberry Pi Home Server as a backup destination. All they’ll need is that particular computer’s “backup code”, which you can get from “Friends” tab in the CrashPlan UI.

      What’s next?

      As far as core home server functionality goes, the Raspberry Pi is already doing a lot. It’s sharing files and media on the local network, downloading things for you, and backing up your computers, even over the internet when you’re away from home.

      What more could you possibly want?

      How about Virtual Private Networking (VPN) access to your home network when you’re away? Sound good? In the next post, we’ll set up OpenVPN so that you can have all the safety and security of your home network, even from the sketchiest of airport coffee shop networks.


      I have a sneaking suspicion that this article is going to see more updates than most, so I’m starting a section here at the bottom to catch any updates.

      CrashPlan UI has stopped working!

      If you have already installed CrashPlan in the past, and find that the UI doesn’t work anymore after performing an apt-get update/upgrade, you’ll need to repeat the final step of the article once again to put things back to normal. Simply run the following commands to replace the SWT library that CrashPlan installs with one that is compatible with the Pi, and you should be up and running again.

      sudo cp /usr/lib/java/swt-gtk-3.8.0.jar /usr/local/crashplan/lib/swt.jar

      You may need to do this each time you do an apt-get update/upgrade, unfortunately. I haven’t quite figured out what causes the problem just yet, but since CrashPlan wasn’t installed through apt-get, that shouldn’t be it. Just remember this in case your UI stops working one day.