A limitation of tcpdump is that you can't tell in from out

January 18, 2016

Suppose that you are running tcpdump on a network that's experiencing problems, on a machine which you know is supposed to be sending out broadcast ARP requests. When you do something that provokes an ARP request, you see two or three ARP broadcast packets from the machine in close succession (but not back to back; timestamps say there's a little bit of time between each). That sounds okay, doesn't it? Or at least it's not too crazy. There's a plausible case for rapid repeated ARPs in cases where the first request didn't get an immediate reply, and probably Unixes behave differently here so experience on say Linux doesn't necessarily tell you what to normally expect on OpenBSD or Illumos.

Except that there's a problem here. As far as I know, there is no way to tell from tcpdump output whether you're seeing these packets because the system is transmitting them or because it's receiving them. Of course normally you shouldn't (re-)receive packets that your system initially transmitted, but, well, network loops can happen.

Some versions of tcpdump have a switch to control whether it listens to input packets, output packets, or both. On OpenBSD this is -D, on different versions of Linux it is either -P (Ubuntu, CentOS) or -Q (Fedora); FreeBSD doesn't seem to have an option for this. Of course to use this option (if it's available) you have to remember that some sort of echo-back situation might be happening, but at least you can check for it.

This is definitely something that I'm going to have to try to remember for future network troubleshooting. Sadly it's not as simple as always using 'in' initially, because often you want to see both what the machine is sending and what it's getting back; you just would like to be able to tell them apart immediately.

(I believe that this is a limitation of the underlying kernel interfaces that tcpdump uses, in that most or all implementations simply don't tag packets with whether they're 'out' or 'in' packets.)

(This is just one of a number of ways that I've found to be misled by not looking sufficiently closely at what tcpdump seems to be telling me. Eg tcpdump -p versus not, various firewall and IPSec settings causing received packets to be dropped or even IPSec re-materializing packets, and not looking at MAC addresses (also).)

Written on 18 January 2016.
« My theory on how network loop caused the problem we observed
Today I learned that a syslog server can be very silent on the network »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jan 18 00:46:47 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.