Using tcpdump input

[Andrew Pollock]

On Wed, Mar 26, 2003 at 07:55:56PM -0500, Carter Bullard wrote:
> Hey Andrew,
>    Great!  It seems that everyone has to do this at some
> point.  If you have any problems, or interesting results,
> don't hesitate to send mail.

Interesting results time.

We setup three boxes and a Cisco switch like so:

+-------+       +-------+        +-----+
|lettuce|-------|Switch |--------|onion|
+-------+       +-------+        +-----+
                    |
                    |
                +-------+
                |rhubarb|
                +-------+

Lettuce and Onion were used to transfer files backwards and forwards,
the switch had a span port setup with Rhubarb running Argus and tcpdump.

We used SSH, rsync and netcat to transfer a file of random contents being exactly
1GB in size (1024^3 bytes).

We ran Argus and tcpdump simultaneously and tcpdump by itself, with tcpdump invoked with a
snaplen of 0 to catch the entire packet.

I would have thought that with a snaplen of zero, the resulting tcpdump would be greater 
than the size of the file being transferred, given IP overhead and whatnot, yet the tcpdump
was consistently less than 1GB (exact size varied depending on transport method used), which suggests
dropped packets. Tcpdump claims there were no dropped packets, yet the number packets seen was approximately
50% of what an racount of the Argus logfile said it saw.

So if tcpdump is indeed dropping packets, this strikes me as strange that Argus isn't as well, given they are
both using libpcap.

The interesting thing with the Argus results is that they came out somewhat higher than I would have expected,
the 1GB file transferred using netcat, which I figured would have been about as raw TCP in terms of transport as it comes,
had Argus reporting about a 20% more than the 1GB going over the wire, which seems quite a lot of overhead to me.

We're yet to see what the interface counter on the switch saw.

Andrew