a curiousity ...

Peter Van Epp vanepp at sfu.ca
Tue Aug 15 19:33:48 EDT 2006


	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



More information about the argus mailing list