Interesting things to look for in the current 3.0 code ...

Carter Bullard carter at qosient.com
Thu Aug 16 14:23:37 EDT 2007


Hey Peter,
So I've uploaded new server and clients-rc.48.
    ftp://qosient.com/dev/argus-3.0/argus-3.0.0.tar.gz
    ftp://qosient.com/dev/argus-3.0/argus-clients-3.0.0.rc.48.tar.gz

many changes for memory issues, and fixes for threads.  if you have
any problems, give the un-threaded versions a run (remove ./.threads
and ./configure) and see if that changes anything, and definitely
send any issues to the mailing list!!!!!
I think it has a chance to fix your timestamp problem, but that may just
be wishful thinking.

Hope all is most excellent, and that this fixes something ;o)

Carter



On Aug 16, 2007, at 11:56 AM, Peter Van Epp wrote:

> 	I'm seeing several problems in the current 3.0 code and Carter and I
> are trying to figure out if it is unique to me or if there are  
> really still
> bugs there :-).
> 	First I'm seeing continued growth in memory use in the argus sensor
> (in my case on a 64 bit IBM power PC). I just restarted it (after  
> rebooting
> the machine) so its currently ok, but it has been growing to 4 gigs  
> which
> is a problem. I don't think it used to do this, but when I moved  
> back to
> an argus from July 16 it still eats memory. That may point at a  
> problem
> on my machine (which is why it is desirable to get reports from  
> other folks!).
>
> hcids:/scratch # ps auxwwwww | grep argus
> root      6554  2.6  5.8 236692 231784 ?       SLs  08:31   0:12  
> argus -dJR -P 560 -i eth0 -i eth1 -U 512 -m -F /scratch/argus.conf
>
> 	My production 2.0.6 box on the same regen tap seeing the same data
> is using 256K (and has been up since Jun sometime) so I don't think  
> it is
> traffic pattern. You may wish to delete the .threads file in  
> clients since
> we aren't sure there aren't thread problems too (it is currently  
> off by
> default in the argus).
> 	Then I see timestamp oddnesses in the data:
>
> 07-08-16 08:40:05  e d        tcp      91.186.32.244.63229     - 
> >      142.58.101.50.25            4        5          311           
> 492   CON
> 07-08-16 08:34:15  e          tcp      218.61.29.109.7000      - 
> >        142.58.7.96.25437         1        0            
> 60            0   ACC
> 07-08-16 08:40:06  e          tcp       85.141.86.97.2185      - 
> >      142.58.101.28.25            2        1           
> 122           62   CON
> 07-08-16 08:40:00  e          tcp     142.58.129.162.4040      - 
> >       69.63.176.11.80            4        3         1026           
> 470   CON
> 07-08-16 08:40:06  e          udp    208.201.249.252.53       <- 
> >       142.58.103.1.41451         3        3          413           
> 302   CON
> 07-08-16 08:34:35  e          tcp     222.77.182.228.1387      - 
> >      206.12.16.133.3128          5        4          623           
> 513   RST
> 07-08-16 08:40:06  e          tcp         67.44.2.38.14894     - 
> >      142.58.211.84.443           6        4          701          
> 1645   CON
>
> 	Note the two flows at 08:34:15 and 08:34:35 intermixed with current
> data. This one just started and isn't too bad yet, but by the time  
> the log
> file cycles and it has been up for an hour or two I see data from  
> the last
> hour intermixed with current data. Carter hasn't been able to  
> reproduce this
> so we don't know if it is something to do with my machine or a bug  
> in argus
> somewhere. If you are running the current 3.0 versions, please have  
> a look at
> your data and see if you are seeing unexpected time stamps.
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>



More information about the argus mailing list