Jump to content

TCPDUMP troubleshooting OSI layers


Recommended Posts

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.

Layer 1[/b] 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

Layer 5(Session), Layer 6(presentation) and Layer 7(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.

Here are some tcpdump notes.

Basic tcpdump flags

[table][tr][td]-i [/td]

[td]Specify which intterface to capture, defaults to lowest numbered interface[/td][/tr]


[td]Quick output. Print less protocol information so output lines are shorter, easier to read.[/td][/tr]


[td]Show binary and hex data[/td][/tr]


[td]Do not perform DNS lookup, just show the IP[/td][/tr]


[td]Show additional information, -vv shows more, -vvv shows even more[/td][/tr]

[tr][td]-s [/td]

[td]Size of the Packet, (-s 1514)[/td][/tr]


[td]Print absolute, rather than relative TCP sequence numbers[/td][/tr]

[tr][td]src (net)[/td]

[td]The source IP of the filter (src src net can be used to specify a network, in CIDR: (dst net[/td][/tr]

[tr][td]dst (net)[/td]

[td]The destination IP of the filter (dst dst net can be used to specify a network, in CIDR: (dst net[/td][/tr]

[tr][td](src|dst) port[/td]

[td]which port specifically, can be named ports, or specific port. (dst port 80)[/td][/tr]

[tr][td]-w [/td]

[td]The name of the file to write out your packet capture to (-w filename.cap)[/td][/tr]


[td]combine filters (and src net[/td][/tr]


[td]negate filters (and not dst port 22)[/td][/tr][/table]

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.

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

Show traffic to and from

tcpdump src

Show all traffic from

tcpdump dst

Show all traffic to

tcpdump net

Look at traffic to and from

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 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 and dst net not dst port 22

Like previous tcpdump filter, but also limiting between 2 networks, and ignoring port 22

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:

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.

tcpdump Statistics

Often, on a network a few hosts will be infected, but it’s hard to tell which ones those hosts are. Here is a quick method to help you determine who is spewing the most traffic:

First, get a packet capture of the data that is of interest to you, you can get basic packets, or all of it if you want to review it later. In my example I want to review it later, so I’m capturing the entire packet, with a bit of detail:

#  tcpdump -i any -nn -X -vv -s 1514 -c 1000 -w packetcap.cap 

Next run it through awk to display some statistical information:

# tcpdump -nr packetcap.cap | awk '{print }' | grep -oE '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | sort | uniq -c | sort -n

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...