another ra oddity...

Tue Oct 5 20:51:23 EDT 1999

Hey Russell,
   This is unavoidable.  What is happening is the flow idle timer
is reached and argus() times out the flow sometime after your #2
report.  Then when the flow kicks back in the, first packet seen
is going in the opposite direction.  But since we didn't see a SYN
or a SYN_ACK, we don't know who the source is.  In this case
we use the first packet encountered to define the scr and
dst for the flow.

   Not much you can do here.  raconnections() will match them up
correctly when it merges them together.

Carter

Carter Bullard
Principal Consultant/Engineer
Nortel Networks
320 Park Avenue  16th Floor
New York, New York 10022
Email  cbullard at nortelnetworks.com
Phone +1 212 317 4230
Fax   +1 212 317 4324
Pager +1 800 217-7496 

> -----Original Message-----
> From: Russell Fulton [mailto:r.fulton at auckland.ac.nz]
> Sent: Tuesday, October 05, 1999 8:27 PM
> To: Bullard, Carter [NYPAR:DS46-I:EXCH]
> Subject: another ra oddity...
> 
> 
> Hi Carter,
> 	  Here is another oddity reported by ra.  Here the ports get
> swapped in the middle of a session!  Again I don't know what triggers
> this behaviour but I noticed it in several sessions yesterday.
> 
> 
> Tue 10/05 11:52:04 *    tcp  130.216.64.177.3692  <->   
> 134.169.9.220.23    55     62      104       4951     sSE
> Tue 10/05 11:54:15 s    tcp  130.216.64.177.3692  <->   
> 134.169.9.220.23    10     8       5         1562     sSE
> Tue 10/05 11:57:35 *    tcp   134.169.9.220.23    <->  
> 130.216.64.177.3692  24     25      3779      9        E
> Tue 10/05 11:59:35 d    tcp   134.169.9.220.23     ->  
> 130.216.64.177.3692  4      5       6         6        EFC
> 
> I did check and the release ra (unmodified by me) reports the 
> same pattern.
> 
> Server and ra both from the 1st freeze release.
> 
> here is a uuencoded argus file with the offending records in it:
> 
> begin 600 tmp/out.uue
> M at 0```#?H!6\``O3*-_DC80`-$V!!<F=U<R!697)S:6]N(#$N.`H````!V((`
> M____+`$```$!````````"0`D%S?Y+Y0`!$^;+W\`10`!L%0`8#Y9)5@```Q&
> M7-&"V$"QAJD)W`YL`!<````W````/@```&@``!-7"0!@%S?Y,!<`#HP!+W\`
> M,@`*.4\`8#Y9)5@```Q&7-&"V$"QAJD)W`YL`!<````*````"`````4```8:
> M"0`T%#?Y,-\`!Z+O?R\`=P`-.TL`8#Y9)5@```Q&7-&"V$"QAJD)W`YL`!<`
> /```8````&0``#L,````)
> `
> end
> 
> I noticed these because I dump all connections *to* various 
> web servers
> that did not have dst port == 80 and it turned up the last 
> two records.
> (130.216/16 is our net)
> 
> Here is the full report for that job:
> 
> Tue 10/05 11:22:49      tcp  207.46.186.203.80     ?>  
> 130.216.64.177.3542  1      0       0         0        F
> Tue 10/05 11:14:34      tcp  209.185.241.67.80    <|   
> 130.216.64.177.3523  10     9       6840      0        ER
> Tue 10/05 11:57:35 *    tcp   134.169.9.220.23    <->  
> 130.216.64.177.3692  24     25      3779      9        E
> Tue 10/05 11:59:35 d    tcp   134.169.9.220.23     ->  
> 130.216.64.177.3692  4      5       6         6        EFC
> Tue 10/05 12:37:44      tcp 209.185.243.117.443   <|   
> 130.216.64.177.3705  9      9       207       0        ER
> Tue 10/05 12:45:53      tcp 209.185.243.117.443   <|   
> 130.216.64.177.3705  3      1       46        0        ER
> Tue 10/05 12:58:22      tcp  209.185.131.98.80    <|   
> 130.216.16.102.18169 10     10      7600      0        ER
> Tue 10/05 12:56:10      tcp 209.185.131.212.80    <|   
> 130.216.16.102.18151 12     11      8360      0        ER
> Tue 10/05 12:57:24      tcp 209.185.130.157.80    <|   
> 130.216.16.102.18160 12     11      9120      0        ER
> Tue 10/05 13:07:20      tcp  209.185.131.98.80    <|   
> 130.216.16.102.18169 2      1       760       0        ER
> Tue 10/05 13:02:23      tcp 209.185.130.162.80    <|   
> 130.216.16.102.18200 13     12      9120      0        ER
> Tue 10/05 15:30:44      tcp  209.185.243.78.443   <|   
> 130.216.64.177.4350  1      1       0         0        ER
> Tue 10/05 17:49:44      tcp  209.185.243.51.443   <|   
> 130.216.64.177.4962  1      1       0         0        ER
> Tue 10/05 18:29:58      tcp  209.249.226.43.80    <|   
> 130.216.16.102.23221 4      3       4380      0        ER
> 
> here is a full trace for another one:
> 
> Tue 10/05 12:37:35      tcp  130.216.64.177.3705  <|    
> 209.185.243.7.443   11     10      1546      1926     sSEFR
> Tue 10/05 12:37:44      tcp 209.185.243.117.443   <|   
> 130.216.64.177.3705  9      9       207       0        ER
> Tue 10/05 12:45:53      tcp 209.185.243.117.443   <|   
> 130.216.64.177.3705  3      1       46        0        ER
> 
> This one is understandable since the first record is recorded as
> ending with a RST which would cause argus to 'close' the session.
> Later traffic then appears and so argus does not know the 'direction'.
> 
> It is another question as to just why argus thought there was a reset,
> of if there was why the session swapped another 10 packets 
> afterwards???
> 
> I *think* (i.e. I'm not dead sure ;-) that I have seen this sort of
> thing only since I put up the 1.8 1st freeze server.
> 
> 
> Cheers, Russell.
> 
> 