Using tcpdump input

[Steve McInerney]

Andrew,

Out of curiousity: have you thought of sending this problem to "The 
Silicon Kid" in the Canberra Times? He should be able to help! ;-)


More seriously:
What about setting tcpdump to only capture the headers, rather than the 
full packet (default setting)? Possibly look at reducing/removing the 
disk IO bottleneck, and send the resulting file to a RAM disk???

FWIW I've had great success with tcptrace (http://www.tcptrace.org) when 
it comes to analyzing individual tcp flows and such. Particulary useful 
when you throw the resulting data to xplot and can see where packets are 
going and when - and the retries etc graphically! The Time Sequence 
graph should really help at showing dropped packets.


Perhaps, rather than a random file, use a structured file such that you 
could (more or less) re-build the file from tcpdump captured output, and 
thus verify if packets are being dropped?


my 2c for the day.


- Steve

Andrew Pollock wrote:
> 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 
> 
>