good news / bad news :-)

[Peter Van Epp]

	The good news is that memory on the latest 2.0.0k has climbed to about
8 megs and stablized probably indicating the memory leak has been found (or
at least slowed substantially, it hasn't been running long enough yet to tell).
	The bad news is two fold: the counts look wrong and a small file gets
lost when run live. Below are the results from running a single web transaction
through tcpreplay (which also caught an error in my perl script that processes
sniffer output). 

start both argus_bpf (2.0.0k from an hour or so ago, /usr/local/bin erased and
replaces with 2.0.0k/bin/*) and tcpdump which deletes the argus.1.log and 
tcpdump.1.log files before launching:

# ./start
[1] 14078
[2] 14079
tcpdump: listening on xl0
demoa# ls -l
total 8805
-rw-r--r--  1 root    unsupped      128 Oct  1 15:00 argus.1.log
-rw-r--r--  1 root    unsupped        0 Oct  1 15:00 tcpdump.1.log

Hit the other machine and fire up tpcreplay with the 9 packet long tcpdump
file (I'll forward Carter a copy of it) and wait for it to finish (I used a 
rate of 1 meg per second) then killed the two processes:

demoa# kill -HUP 14078 14079

9 packets received by filter
0 packets dropped by kernel
demoa# ls -l
-rw-r--r--  1 root    unsupped      256 Oct  1 15:01 argus.1.log
-rw-r--r--  1 root    unsupped     2468 Oct  1 15:01 tcpdump.1.log

Use ra to read the argus log, don't get anything at all:

demoa# ra -r argus.1.log -c -n
01 Oct 00 15:01:32.053752   man  pkts      0  bytes            0  drops     0
  flows    0         closed       0           STP

Use argus_bpf, the tcpdump file and ra and get data (but unfortunatly not 
right data ...):

demoa# argus_bpf -r tcpdump.1.log -w - |ra -c -n
01 Oct 00 15:00:55.714191   tcp  130.71.240.184.2197   ->      142.58.12.12.80
  5        4         440          1554        RST
01 Oct 00 15:00:55.714511   man  pkts      9  bytes         2300  drops     0
  flows    1         closed       1           STP

Now feed the tcpdump file to 1.8.1 (patched) argus_bpf and ra and get right
data (according to the sniffer anyway):

1.8argus_bpf -r tcpdump.1.log -w - | 1.8ra -c -n

9 packets recv'd by filter
0 packets dropped by kernel
Sun 10/01 15:38:13      man         0.0.0.0                   0.0.0.0       0
   0       0         0        INT
Sun 10/01 15:00:55  M   tcp  130.71.240.184.2197   |>    142.58.12.12.80    5
   4       314       1456     RST
Sun 10/01 15:38:13      man  pkts        9  drops     0   flows active      0
closed      1                 CLO

	Here is what the sniffer (or more correctly what the perl script that
post processed the sniffer summary data) thought:

this is src/dst ip/port  src dst packets src/dst total bytes src/dst data bytes

130.71.240.184.2197 142.58.12.12.80 5 4 608 1690 314 1456

	The src/dst data bytes agree with 1.8.1, but don't with 2.0.0k (in 
either case). As well the 2.0.0k version saw 2 more (2300 against 2298 for
the sniffer) total bytes for the flow as well from the final tcpdump man line.
	Hmmm, 1.8.1 seems to have the same bug when not coming from tcpdump
but rather tcpreplay over the wire: 

demoa# 1.8argus_bpf -ixl0 -w - |1.8ra -c -n
^C
9 packets recv'd by filter
0 packets dropped by kernel

demoa# rm t
demoa# 1.8argus_bpf -ixl0 -w t
^C
9 packets recv'd by filter
0 packets dropped by kernel
demoa# 1.8ra -r t -c -n
Sun 10/01 16:04:22      man     1.168.192.0             255.255.255.0       0
   0       0         0        INT
Sun 10/01 16:04:31      man  pkts        9  drops     0   flows active      0
closed      0                 CLO
demoa#

Peter Van Epp / Operations and Technical Support 
Simon Fraser University, Burnaby, B.C. Canada