tcpdump
Layers
A common step in troubleshooting is finding out what not to troubleshoot. With a packet capture you can confirm things such as routing, firewall rules, and remote services.
OSI Model from wikipediaOnce you can prove that a packet is coming back, then you can prove that all layers of the OSI model below are working. For example, if you get an ACK, then you know a few things:
Layer 1 hardware is probably on and functioning Layer 2 Addressing is likely working Layer 3 Routing would appear to be working Layer 4 Transport is likely working
Session, presentation and application might not be working at this point, but you’ve ruled out several things that don’t need to be tested. You can do detailed packet captures that look for additional information to verify if layers 5,6 and 7 are working, but this should save you some time to know that layers 1-4 are operational. It’s possible that intermittent errors, or bandwidth related errors could be hiding, and a packet capture can still help you find this type of error too. Every serious network and security professional should know how to use tcpdump.
Here are my tcpdump notes, perhaps you’ll find them handy too:
Basic tcpdump flags
| Flag | Explanation |
|---|---|
| -i | Specify which intterface to capture, defaults to lowest numbered interface |
| -q | Quick output. Print less protocol information so output lines are shorter, easier to read. |
| -X | Show binary and hex data |
| -n | Do not perform DNS lookup, just show the IP |
| -v | Show additional information, -vv shows more, -vvv shows even more |
| -s | Size of the Packet, (-s 1514) |
| -S | Print absolute, rather than relative TCP sequence numbers |
| src (net) | The source IP of the filter (src 1.1.1.1). src net can be used to specify a network, in CIDR: (dst net 1.1.1.0/24) |
| dst (net) | The destination IP of the filter (dst 1.1.1.1). dst net can be used to specify a network, in CIDR: (dst net 1.1.1.0/24) |
| (src | dst) port |
| -w | The name of the file to write out your packet capture to (-w filename.cap) |
| and | combine filters (and src net 1.1.1.0/24) |
| not | negate filters (and not dst port 22) |
tcpdump filter examples
Here is a list of several ways to build filters, and some of the more common ways that you might want to view data.
| Example | Description |
|---|---|
| tcpdump -nS | Very basic communication. |
| tcpdump -nnvvS | Basic, verbose communication. |
| tcpdump -nnvvXS | Get the packet payload, but that’s all |
| tcpdump -nnvvXSs 1514 | Full packet capture with all details |
| tcpdump host 1.2.3.4 | Show traffic to and from 1.2.3.4 |
| tcpdump src 1.2.3.4 | Show all traffic from 1.2.3.4 |
| tcpdump dst 4.3.2.1 | Show all traffic to 4.3.2.1 |
| tcpdump net 1.2.3.0/24 | Look at traffic to and from 1.2.3.0/24 |
| tcpdump port 3389 | Remote Desktop example |
| tcpdump udp and src port 53 | specify protocol combined with src port (DNS filter example) |
| tcpdump portrange 1000-2000 | Do you need an explanation? If so, perhaps another article is better for you. |
| tcpdump -i any -nnvvXSs 1514 -c 100 src 1.2.3.4 port 443 -w capturefile | Capturing full packet, fully verbose, limit to 100 of them, with IP and port filter, write to capturefile for later analysis. |
| tcpdump -nnvvXSs 1514 src net 192.168.0.0/16 and dst net 10.0.0.0/8 not dst port 22 | Like previous tcpdump filter, but also limiting between 2 networks, and ignoring port 22 |
| tcpdump -D | which interface? |
| tcpdump -nnei eth0 -c 5 | 5 packets |
| tcpdump -A -i eth0 | Ascii |
| tcpdump -XX -i eth0 | hex + ascii |
| tcpdump -w 0001.pcap -i eth0 | write |
| tcpdump -r 0001.pcap -i eth0 | replay |
| tcpdump -i eth0 port 22 | all ssh |
| tcpdump -i eth0 src 192.168.0.2 | just this source |
3 way Handshake Troubleshooting With tcpdump
We are able to confirm routing, firewall rules, and remote service response by looking at the type of packet that comes back:
| flag | description |
|---|---|
| tcpdump ‘tcp[13] & 2!=0’ | SYN messages tell us that at least our client is sending it’s initial outbound message. If that’s all we see, then nothing is coming back and routing could be bad, or the remote server could be down. |
| tcpdump ‘tcp[13] & 16!=0’ | ACK is the acknowledge message. We can see that the traffic is going all the way to and from the client/server and the server is responding. |
| tcpdump ‘tcp[13]=18’ | SYN ACK packets shows active communication between client and server. Routes, ACLs, and Firewall rules are good. |
| tcpdump ‘tcp[13] & 4!=0’ | RST packets. RST packets are sent back from the service, so at least you know the path is good and not blocked by an ACL or firewall. |
| tcpdump ‘tcp[13] & 1!=0’ | FIN packets. FIN packets are sent back from the service, so you also know path and firewall or ACL rules are not blocking. |