Packet Pushers

Where Too Much Technology Would Be Barely Enough

  • HOME
  • Podcasts
    • Heavy Networking
    • Priority Queue
    • Network Break
    • Briefings In Brief
    • Datanauts
    • Full Stack
    • IPv6 Buzz
    • Community
  • News
  • Hosts
  • Subscribe
  • Sponsor
  • Contact

IGNITION MEMBERSMEMBER LOGIN

You are here: Home / Blogs / Masterclass – Tcpdump – Basics

Masterclass – Tcpdump – Basics

Steven Iveson June 28, 2013

This tcpdump Masterclass article series aimes to provide in-depth technical information on the installation, usage and operation of the classic and supremely popular tcpdump network traffic analysis program including alternatives, running tcpdump as a process, building expressions, understanding output and more. I’ll cover the Basics here and move on to Parameters, then filter Expressions and finally Interpreting Output.

utilities-terminal

Precautions

tcpdump output can be considerable if the network traffic your expression defines is high bandwidth; particularly if you are capturing more than the default 68 Bytes of packet content.

Capturing packets, for example, related to a large file transfer or a web server being actively used by hundreds or thousands of clients will produce an overwhelming amount of output. If writing this output to stdout you will probably be unable to enter commands in your terminal, if writing to a file you may exhaust the host’s disk space. In either case tcpdump is also likely to consume a great deal of CPU and memory resources.

To avoid these issues;

  • Be very careful when specifying expressions and try to make them as specific as possible.
  • Don’t capture during times of heavy traffic/load.
  • If you wish to capture entire packet contents, do a test capture only capturing the default 68Bytes first and make a judgement on whether the system will cope with the full packet content capture.
  • Where writing to disk, carefully monitor the size of the file and make sure the host in question has the likely disk resources required available, or use the -c parameter to limit the number of packets captured.
  • Never use an expression that would capture traffic to or from your remote telnet/SSH/whatever terminal/shell. tcpdump output would generate traffic to your terminal, resulting in further output, resulting in more traffic to your terminal and so on in an infinite and potentially harmful feedback loop.

Development

Tcpdump and Libpcap (see next) are maintained and developed by http://www.tcpdump.org/ and have been since 1999. The original authors that created tcpdump in 1987 are: Van Jacobson, Craig Leres and Steven McCanne, all of the Lawrence Berkeley National Laboratory, University of California, Berkeley, CA.

Libpcap

The low-level packet capture and file writing/reading related code of tcpdump was extracted at some point and formed into a library to which tcpdump is linked. This library, libpcap now provides the underlying functionality of tcpdump and many other Linux and Windows packet capture tools including Wireshark, Snort, Nmap, iftop, ngrep and Bro amongst others.

Linux User Permissions

Root or root equivalent user account privileges are required to run tcpdump.

This can present potential security and stability risks; I’ve never had an issue myself but for information on how to run tcpdump as a non-root user, see this link: http://packetlife.net/blog/2010/mar/19/sniffing-wireshark-non-root-user/.

As noted in a comment (unfortunately anonymous) you can also (rather more simply) just prefix your tcpdump command and syntax with the nice command. This will assign a lower scheduling priority and should ensure system CPU resources cannot be exhausted by the command.

Linux Installation

tcpdump can be installed or upgraded as follows, depending on your platform;

  • Ubuntu/Debian: apt-get install tcpdump
  • RHEL/Fedora Core/CentOS: yum install tcpdump
  • FreeBSD: pkg_add -v -r tcpdump

Availability

tcpdump is only available for Unix/Linux and is the program used to perform packet capture and analysis on Arista, F5 BIG-IP and Vyatta network devices, amongst others.

Linux Alternatives

For capturing and decrypting/decoding SSL/TLS packets and data at the CLI, ssldump can be used: http://www.rtfm.com/ssldump/. Update: I’ve now written an article on using this tool, available here: Using ssldump to Decode/Decrypt SSL/TLS Packets.

The tshark and dumpcap CLI programs which are a part of Wireshark or of course, Wireshark itself.

The ngrep CLI program: http://ngrep.sourceforge.net/

Windows Equivalents

WinDump has equivalent functionality and runs in a Windows command prompt: http://www.mirrorservice.org/sites/ftp.wiretapped.net/pub/security/packet-capture/winpcap/windump/. WinDump requires WinPcap which can be obtained here: http://www.winpcap.org/install/default.htm. Command syntax is exactly the same as tcpdump, but some older version, most options and syntax detailed in this article will work.

The tshark and dumpcap command prompt programs which are a part of Wireshark or of course, Wireshark itself.

It seems you can now perform Native Packet Capture in Windows 8.x with the netsh command!

VMWare ESXi Equivalents

I recently just stumbled across this tool: tcpdump-uw to capture vmkernel and vm packets: http://rickardnobel.se/tcpdump-uw-for-troubleshoot-esxi-networking/.

Docker Containers

As a lightweight alternative to installation you could use one of the many container images out there. You’ll find my very own, tiny image here: https://hub.docker.com/r/itsthenetwork/alpine-tcpdump/.

Decoding SSL/TLS

tcpdump can capture but not decrypt or decode SSL/TLS packet data.

To do this, either;

  • Use a real-time tool such as ssldump (available at: http://www.rtfm.com/ssldump/). Update: I’ve now written an article on using this tool, available here: Using ssldump to Decode/Decrypt SSL/TLS Packets.
  • Write your capture to a file and use a tool such as Wireshark (available at: http://www.wireshark.org) to decode the packet data instead. I’ll do a Using Wireshark to Decrypt SSL/TLS Packet Data article for information on how to do this if anyone thinks it’ll be useful. Update: Find that article here.

In either case, you will need the SSL/TLS private key.

Usage Syntax

tcpdump [-i interface] [parameter(s)] [expression(s)]

Running tcpdump As A Process (Unattended Captures)

Update: Using the screen command would appear to be a better method than the one described below (and negates the need for writing to a file) although it’s unlikely to be part of any Linux base install unfortunately. See here for more information: http://www.rackaid.com/resources/linux-screen-tutorial-and-how-to/ (thanks to Gabriel and Nicola for there comments around this).

You can use the nohup command with the shell function & to run tcpdump as a background process that will continue running even if the terminal/shell it is launched from is closed. This is very useful for running unattended captures and in situations where, for instance, an SSH shell is terminated after a period of inactivity.

Use following command syntax;

nohup tcpdump [-i interface] [parameters] -w [dir/]filename [expression(s)] &

Note: Output must be written to a file using the -w option.

To stop the process, use the ps command to identify the relevant tcpdump process and then the kill command to terminate it.

Update: The jobs command seems to be a rather superior alternative to using ps as the output is considerably smaller. Better yet, you can use the fg command to return the tcpdump process to the foreground and then stop it simply using [CTRL]+C (thanks to Paul Cantle for these tips).

Standard Output & Writing To A File

You can display tcpdump output on standard output (STDOUT,) the default and capture that output to a file as well using the tee command, using the syntax below;

tcpdump [-i interface] [parameters] [expression(s)] | tee [dir/]filename

Notes;

  • The file will be saved as a text file, not in the format used when the -w parameter is used (libpcap.)
  • You will not be able to use Wireshark or similar tools to analyse the output captured in the file, as the format is not supported.
  • If you specify the name of an existing file it will be overwritten without warning unless you specify the tee command parameter -a.

Specifying An Interface

-i interface

You do not need to specify the interface if you wish to capture traffic on the lowest numbered, configured interface on the system (often eth0.) Loopback interfaces are ignored. Use -D to display a list of interfaces that tcpdump is capable of capturing on.

For Linux, use the ifconfig command to display information on interfaces available to the system, but note this command limits the display of interface names to 9 characters. Alternatively, use the ip link command which displays names up to 255 characters long.

On Linux systems with kernel 2.2 or later an interface argument of any or 0.0 is supported. This captures packets from all interfaces but not in promiscuous mode.

Using Tcpdump With SPAN Traffic

You might want to take a look at this around some of the drawbacks of SPAN in general: https://packetpushers.net/benefits-limitations-of-span-ports/.

Thanks to Ian for this. Note that a NIC that does TCP offload will reconstruct large fragments even for traffic that has been SPANed to it. So, disable offload features as necessary (ethtool -k under Linux) when using tcpdump and SPAN to see what is actually on the wire.

The icon Artwork used in this article is by the GNOME Project and licensed under the Creative Commons Attribution-Share Alike 3.0 United States License.

19 Comments

About Steven Iveson

The last of four children of the seventies, Steve was born in London and has never been too far from a shooting, bombing or riot. He's now grateful to live in a small town in East Yorkshire in the north east of England with his wife Sam and their four children.

He's worked in the IT industry for over 20 years in a variety of roles, predominantly in data centre environments. More recently he's widened his skill set to embrace DevOps, Linux, containers, automation, orchestration, cloud and more. He's been awarded F5 Networks DevCentral MVP status five times in 2014, 2016, 2017, 2018 and 2019. Details of his F5 related books can be found here. You can find him on Twitter: @sjiveson.

Comments

  1. thepacketologist says

    June 28, 2013 at 6:09 pm

    Thanks for this Steven. Just yesterday, I used tcpdump and traceroute -T -p 80 on a Ubuntu Live CD to get to the bottom of an issue at work. We were trying to rule out our network as being the cause of why certain clients couldn’t get to a remote server over http.

    I’m a beginner with Linux but more and more I’m convinced that it’s an invaluable resource to have. Things like traceroute with protocol/port options, tcpdump, mtr, grep, etc are all great to have in an engineer’s tool bag.

    Reply
    • euan_b says

      June 30, 2013 at 12:59 am

      I wouldn’t get to hung up on the OS – all those tools are cross-platform. Whilst it’s true that, out the box, Linux has these tools one may not always have the luxury of running it.

      Reply
      • thepacketologist says

        June 30, 2013 at 1:37 am

        Agreed. In my environment and previous environments, Microsoft was the only OS allowed. We just so happened to have a non-domain laptop that we were able to use Ubuntu Live CD on in this one particular case.

        Reply
      • What Lies Beneath says

        July 2, 2013 at 10:28 am

        Very true Euan; thanks for prompting me to look into the cross-platform aspects a bit further. I’ve added some detail on libpcap to the article.

        I’ve rarely found server administrators with the necessary privileges to run tools like this on Linux systems. I’m more focussed on network devices that either run Linux or have a Linux based management subsystem (such as F5 devices). Have this capability at the core of or gateway to a network is incredibly useful.

        Reply
    • What Lies Beneath says

      June 30, 2013 at 9:37 pm

      You’re welcome, thanks for your comments. mtr is new to me so I’ll be investigating that. Cheers

      Reply
  2. Alex__Clark says

    June 30, 2013 at 2:20 am

    Great post and very useful tool! I am very glad to see tcpdump added to some of the networking operating systems. Here are a couple tcpdump, (or similar tools) which have been added to switch/router OSes.

    Arista EOS has full blown TCPDump: https://eos.aristanetworks.com/2011/06/using-tcpdump-for-troubleshooting/

    JunOS: http://kb.juniper.net/InfoCenter/index?page=content&id=KB23313

    NX-OS has a similar tool called Ethananlyzer: http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps11541/white_paper_c11-673817_ps9670_Products_White_Paper.html

    Standard IOS doesn’t have any real equivalent. In theory you could try and munge the output of packet debugs, but that would kill the appliance.

    Reply
    • What Lies Beneath says

      June 30, 2013 at 9:35 pm

      Thanks Alex, indeed. Cheers

      Reply
  3. What Lies Beneath says

    June 30, 2013 at 9:32 pm

    Thanks Alex, that’s really useful. I’ve updated the article accordingly.

    Reply
  4. Anon says

    July 1, 2013 at 5:37 pm

    Or nice the process so it can only interrupt with a certain priority.

    Reply
    • What Lies Beneath says

      July 2, 2013 at 10:22 am

      Thanks Anon, I added your suggestion too.

      Reply
  5. Gabriel says

    July 1, 2013 at 9:30 pm

    – instead of nohup, one could start tcpdump in a screen/tmux session

    – if one wants to see the capture in real-time AND write to a file in .pcap format, -w and -r can be combined: start tcpdump in a console with -w file.pcap as parameter and then start another tcpdump instance in another console with -r file.pcap. It (kinda) works (I keep getting errors like “tcpdump: pcap_loop: truncated dump file; tried to read 16 header bytes, only got 12” before it stops).

    Reply
    • What Lies Beneath says

      July 3, 2013 at 4:08 pm

      Thanks Gabriel. I don’t think I’d take the risk of your second suggestion but could you expand on the first please? Clearly my Linux skills are wanting.

      Reply
      • Gabriel says

        July 3, 2013 at 9:05 pm

        I was thinking that, instead of sending the tcpdump process in the background, you could run it in a screen (or tmux) session. These allow you to multiplex virtual consoles and attach to / detach from them whenever.

        So, you could start a session, run tcpdump in a virtual console inside that session and detach from the session. Later, you could re-attach to the session (even after ssh-ing into the machine from a remote location) and stop the capture. I guess the main difference between this and nohup would be that you could see the statistics tcpdump presents at the end (received/captured/dropped pkts) or, if tcpdump stopped unexpectedly, you could see the error message.

        Reply
        • What Lies Beneath says

          July 3, 2013 at 9:36 pm

          Hey Gabriel; thanks again and forgive my continued ignorance but how would that be achieved; it sounds seriously useful. Cheers

          Reply
          • Nicola says

            July 3, 2013 at 9:57 pm

            When you have installed screen (apt-get install or whatever) just launch it in the console.
            Typing Ctrl+A and then D you can detach it.
            With the command “screen -ls” you get a list of sessions (PID is the identifer)
            With “screen -r PID” you can reattach to the session

            (something similar to RDP session in windows: you can disconnect and reattach without logging off)

          • What Lies Beneath says

            July 3, 2013 at 10:13 pm

            It’s one of those tools I’ve never heard of that I suspect I won’t be able to live without very soon. Many thanks Gabriel and Nicola both; I’ve updated the article quickly now and will look into this more. This is one of the many reasons I love blogging here; I learn something every time. Cheers

  6. Jamie says

    July 12, 2013 at 3:12 pm

    “I’ll do a Using Wireshark to Decrypt SSL/TLS Packet Data article for information on how to do this if anyone thinks it’ll be useful.”
    I would find this extremely useful. My primary use for TCPdump is to capture packets on a VCS Expressway (SIP registrar/proxy), and most of the endpoints are using TLS encrypted SIP. The ability to debug these call flows without having to change the remote endpoint to TCP would be most helpful.

    Reply
    • What Lies Beneath says

      July 13, 2013 at 9:34 am

      Hey Jamie. Sure thing, I’ll get something up early next week.
      Btw, anyone notice how the Disqus Twitter login now wants far more access than it used to?

      Reply
  7. What Lies Beneath says

    July 13, 2013 at 9:40 am

    Many thanks for persisting Gabriel and you’re welcome. I don’t think I’ve ever learnt so much from a blog post, albeit nothing network related! A friend also pointed out yesterday that the jobs command is probably better than using ps.

    Anyway, I’ll be taking a close look at both and my latest ‘almost ready’ book will be getting a few extra sections. If you could drop me your full name via Twitter or email I’ll give you a mention. Thanks again.

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

  • Email
  • Facebook
  • LinkedIn
  • RSS
  • Twitter
  • YouTube

RSS YouTube

  • What Does Digital Transformation Mean To Me February 12, 2019

RSS The Weekly Show

  • Heavy Networking 430: The Future Of Networking With Guido Appenzeller February 15, 2019

RSS Priority Queue

  • PQ 161: Inside Juniper’s Programmable Silicon (Sponsored) December 13, 2018

RSS Network Break

  • Network Break 222: SnapRoute Launches Network OS; Carbonite Buys Webroot February 18, 2019

RSS Briefings In Brief

  • Tech Bytes: Thousand Eyes Shares Lessons Learned From A CenturyLink Outage (Sponsored) February 18, 2019

RSS Datanauts

  • Datanauts 158: Creating, Operating, And Collaborating On Open Source February 13, 2019

RSS Full Stack Journey

  • Full Stack Journey 028: Turning The Mic On Scott Lowe December 18, 2018

RSS IPv6 Buzz

  • IPv6 Buzz 019: IPv6 And Broadband Internet Cable Providers February 7, 2019

RSS The Community Show

  • Day Two Cloud 002: How To Do Cloud Right February 6, 2019

Recent Comments

  • Martin on Fortinet Stitches New Firewalls Into Its Security Fabric
  • Ethan Banks on BiB 071: SnapRoute CN-NOS For Whitebox Focuses On Operators
  • Glenn Sullivan on BiB 071: SnapRoute CN-NOS For Whitebox Focuses On Operators
  • Ethan Banks on BiB 071: SnapRoute CN-NOS For Whitebox Focuses On Operators
  • Ethan Banks on BiB 071: SnapRoute CN-NOS For Whitebox Focuses On Operators
  • michael marrione on BiB 071: SnapRoute CN-NOS For Whitebox Focuses On Operators

PacketPushers Podcast

  • Heavy Networking
  • Network Break
  • Priority Queue
  • Briefings In Brief
  • Datanauts
  • Full Stack Journey
  • IPv6 Buzz
  • Community Podcast

PacketPushers Articles

  • All the News & Blogs
  • Only the Latest News
  • Only the Community Blogs
  • Virtual Toolbox

Search

Website Information

  • Frequently Asked Questions
  • Subscribe
  • Sponsorship
  • How To Pitch Us
  • Meet the Hosts
  • Terms & Conditions
  • Privacy Policy

Connect

  • Contact PacketPushers
  • Ask Me Anything
  • Subscribe to Podcasts
  • Sponsorship
  • Facebook
  • LinkedIn
  • RSS
  • Twitter
  • YouTube

© Copyright 2019 Packet Pushers Interactive, LLC · All Rights Reserved