a curiousity ...

[carter at qosient.com]

Hey Peter,
I'll take a look at the window stats.  As always, having an argus record that demonstrates the problem, makes it soooo much easier!!!

The management start time is the start time of the probe, which seems correct in your example.  This allows "dur" to provide probe up time.  I think that has been the behavior from the beginning of time.  Is this incorrect?

Carter


Carter Bullard
QoSient LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax  

-----Original Message-----
From: Peter Van Epp <vanepp at sfu.ca>
Date: Tue, 15 Aug 2006 16:33:48 
To:argus-info at lists.andrew.cmu.edu
Subject: [ARGUS] a curiousity ...

	I was (am) poking at the direction and status codes on 2.0.6 to 3.0
conversion because it is about the only non working part left. As part of that
I hit an oddness that I'm unsure of:

swin 0 65535
dwin 65535 0

line: 1 fields in error: swin,dwin,
1155330533.832071,1155330534.228521,1,0.396450,0.396450,64.152.73.70,142.58.121.65,tcp,80,2601,0,0,188,126,54,62,0,0,1,0,1089.67,1251.10,2.52,0.00,0.0000,0.0000,3848370891,d,0:90:69:c0:e0:1f,0:e0:63:13:7e:0,?>,,,RA_S,,,0,65535,1,,,,,0x999f
1155330533.832071,1155330534.228521,1,0.396450,0.396450,64.152.73.70,142.58.121.65,tcp,80,2601,0,,188,,54,62,0,0,1,0,1089.671,1251.104,2.522,0.000,0,0,229.97.122.203,  d      ,0:90:69:c0:e0:1f,0:e0:63:13:7e:0,?>,,,RA_S,,,65535,0,1,,,,,0x999f,

	On a none ragatored 2.0.6 file the source and dest windows are 
reversed. Running it through ragator seems to correct that which seems like 
it should be wrong. 
	This chunk of argus_client.c appears to be the culprit:


                           if ((!retn->canon.metric.src.pkts && tcp->src.flags)
||
                               (!retn->canon.metric.dst.pkts && tcp->dst.flags))
 {
                              struct ArgusTCPObjectMetrics  tmp = tcp->src;
                              tcp->src = tcp->dst;
                              tcp->dst = tmp;
                           }
                           if (!retn->canon.metric.src.pkts && retn->canon.metri
c.dst.pkts)
                              if (!(tcp->status & (ARGUS_SAW_SYN | ARGUS_SAW_SYN
_SENT))) {
                                 parser->ArgusReverse = 1;


	and I'm not at all sure this is in fact correct (and shouldn't be 
replaced with the parser->ArgusReverse = 1; just under it). The code would
appear to only invert the tcp dsr leaving all the other record fields 
unreversed which feels (but may not actually be :-)) wrong, as some of the 
other counts in other parts of the record will be still in the original 
order which should (but other than this particular case, doesn't seem to be)
causeing problems. 
	As I'm here there also looks to be a problem with the time stamp
on rc.25 man records:

/var/log/argus> ra -r bb_argus -n
    15:59:56.730998  v S        tcp      142.58.101.67.58302    <?>      142.58.135.55.80          272      678        19040      1019544   CON
    15:59:56.759793  v          tcp      142.58.131.72.1369     <?>     142.58.101.108.3389          3        3          174          267   CON
    15:59:56.807810  v        ipnip     142.58.203.225          <->       142.58.29.59              10       10         4990         1120   CON
...

/var/log/argus> ra -r bb_argus -n -- man
    13:46:27.113327             man               3521      0                    23679      1  2482031    39455        23679   2423511476   CON
    13:46:27.113327             man               2913      0                    20261      1  2159590    39343        20261   2450793408   CON
    13:46:27.113327             man               3338      0                    20963      1  1889735    36631        20963   2476506440   CON
    13:46:27.113327             man               3314      0             

	Without having looked I'd guess its using the start time for all man
records which it shouldn't be. 

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