Argus-2.0 byte count strategy

Sun Oct 1 22:35:28 EDT 2000

Hey Peter,
   So there is a signal issue and a byte count issue.
Regarding the SIG_HUP, Argus-2.0 should handle this well,
so we'll need to look into that.  It should flush all
records that it is tracking.  I suspect that if you compiled
in the debug support and ran it in debug mode -d2, you
would see some different behavior (maybe?).  Use -d4 to
see if its writing out the record to the other processes.

The byte counts are due to Argus-2.0 reporting bytes
differently from Argus-1.8.1.  We discussed this
briefly on the list, and now is probably a great time
to talk it through.  Argus-2.0 is not doing the right
thing, so lets decide what the right thing is.

We should be reporting total bytes above IP, as derived from
the packet headers.  In argus-1.8.1 we are subtracting
ether, IP header and transport header length from the
reported bytes, so Argus-1.8.1 you get user bytes.  So
Argus-2.0 is reporting something in between total bytes
and user bytes.  So that's expected.

We should support both in Argus-2.0.  Possibly a -A switch
for application bytes, and default reporting total
bytes?  Do we want any other strategies

I'll double check the man record byte reporting, 6 bytes
off is 6 tooooo many.

Other differences that you did not mention.
In Argus-2.0, notice that the tcp connection is saying
RST, but the arrow is different from 1.8.1.  You'll
get the older indication if you ran ra with the -R
(response) option.

Carter

-----Original Message-----
From: owner-argus at lists.andrew.cmu.edu
[mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Peter Van Epp
Sent: Sunday, October 01, 2000 7:09 PM
To: argus
Subject: good news / bad news :-)

	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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20001001/698c66e3/attachment.html>