best way to collect traffic

Peter Van Epp vanepp at sfu.ca
Wed Apr 29 01:25:07 EDT 2009


On Fri, Apr 24, 2009 at 08:44:33AM +0300, Oguz Yarimtepe wrote:
> 
> I am generally using a dataset [1] for testing purposes. What i do is
> converting the tcpdump files to arg3 records and analyse the results. 
> 
> A few days ago i tried to check my own traffic so i run the tcpdump
> while surfing. After a while i break the process by ctrl+c and converted
> the dumo file arg3 and check the results. I saw some <?> values at the
> direction field. So i thought, collecting the traffing in this way is
> not a good idea or i broke the connection an packages so the flow data
> was missing. 
> 
> What is the good way to collect a traffic for analyzing via argus?
> 
> -- 
> Oguz Yarimtepe
> http://www.loopbacking.info
> 

	With care tcpdump is a fine way to collect traffic. Depending on what
kind of traffic you want to analyse you may want to increase the default 
capture length to tcpdump (-s0 which captures the entire traffic is nice but
may cause performance problems). When you have the capture running tcpdump -r
against the capture file and looking at the traffic is a good bet. As Carter
noted if the syn syn-ack handshake isn't in the tcpdump output argus won't see
it and won't report correctly. If your tcpdump capture machine is too busy,
your pcap buffer is too small (the default uused to be 8K on FreeBSD for 
instance but sysctl can boost it to 512K or so) or your capture machine is 
to slow and/or has too slow disks then you will lose packets (this happens
at reasonably low line rates, writing to disk used to drop packets on a 50 
meg per second link for instance). My former site's production argus sensor
captures using an argus instance with output being written to a socket (on a 
Linux box using Phil Wood's mmap ed libpcap for speed) which is captured by
ra on a second box and the argus data written to disk. As noted at a 30 to 
50 megabit per second line rate argus writing to local disk used to lose 
packets (of course both disks and machines weere slower then too). If you have
access to a wire speed sniffer and a tap, capture the same data that tcpdump
is seeing with the tap/sniffer combination and compare the output and see if 
the tcpdump is losing packets. 

Peter Van Epp 



More information about the argus mailing list