fragments in 2.0.5?

Carter Bullard carter at qosient.com
Fri Apr 19 16:52:10 EDT 2002


Hey Peter,
    Hmmmm, we still track frags the same way, but the fragment
specific data was moved into its own DSR.  I stop generating
the fragment specific data in 2.0 as there was a lot of
issues with the weird formats and the delimiter field specifiers
and the like.

   It does look like the numbers are a bit screwy.  as the
frag id looks like its being printed as dst packet counts,
and the dst byte count is definitely not good.
Can you share the file that has the lone frags so I can
debug this?  The status field should have an 'f' in it, but
you aren't printing out the status indicator field.

Hope all things have been well!

Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com

> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu 
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of 
> Peter Van Epp
> Sent: Friday, April 19, 2002 3:41 PM
> To: argus
> Subject: fragments in 2.0.5? 
> 
> 
> 	Does 2.0.5 still report fragments? I'm in the process 
> of actually 
> thinking about moving to 2.0.5 from 1.8.1 and while 
> converting scripts needed to identify a frag output for 
> parsing. While I can find lots in 1.8.1, when fed to 2.0.5 it 
> doesn't think they are frags:
> 
> 	This is the 1.8.1 ra reporting isolated fragments:
> 
> test6# ./ra -r /data/frag -c -n
> Fri 04/19 11:00:03      man         0.0.0.0                   
> 0.0.0.0       0      0       0         0        INT
> Fri 04/19 10:52:08 frag  ip     160.79.2.67        ->    
> 142.58.1.152 16    pk  1  ex    0  ob 1532  max 1480 TIM
> Fri 04/19 10:50:53      tcp     160.79.2.67.1755  <->    
> 142.58.1.152.3537  4      2       96        96       EST
> Fri 04/19 10:54:05 frag  ip     160.79.2.67        ->    
> 142.58.1.152 3706  pk  1  ex    0  ob 1532  max 1480 TIM
> Fri 04/19 10:52:56      tcp     160.79.2.67.1755  <->    
> 142.58.1.152.3537  4      2       96        96       EST
> Fri 04/19 10:56:13 frag  ip     160.79.2.67        ->    
> 142.58.1.152 19640 pk  1  ex    0  ob 1532  max 1480 TIM
> Fri 04/19 10:54:59      tcp     160.79.2.67.1755  <->    
> 142.58.1.152.3537  4      2       96        96       EST
> Fri 04/19 10:57:02      tcp     160.79.2.67.1755  <o>    
> 142.58.1.152.3537  4      2       96        96       TIM
> Fri 04/19 10:50:37  F   udp     160.79.2.67.2888  <->    
> 142.58.1.152.3539  2430   2427    3722760   126204   TIM
> 
> 
> 	This is the same file (caught with tcpdump) on the 2.0.5 ra:
> 
> test6# /usr/local/bin/ra -r /data/frag -c -n 
> 19 Apr 02 11:00:03    man version=1.8     probeid=0           
>                                                           STA
> 19 Apr 02 10:52:08     ip     160.79.2.67       <->      
> 142.58.1.152       1        16        0            0           TIM
> 19 Apr 02 10:50:53    tcp    142.58.1.152.3537   ?>       
> 160.79.2.67.1755  4        2         96           96          EST
> 19 Apr 02 10:54:05     ip     160.79.2.67       <->      
> 142.58.1.152       1        3706      0            96994812    TIM
> 19 Apr 02 10:52:56    tcp    142.58.1.152.3537   ?>       
> 160.79.2.67.1755  4        2         96           96          EST
> 19 Apr 02 10:56:13     ip     160.79.2.67       <->      
> 142.58.1.152       1        19640     0            96994812    TIM
> 19 Apr 02 10:54:59    tcp    142.58.1.152.3537   ?>       
> 160.79.2.67.1755  4        2         96           96          EST
> 19 Apr 02 10:57:02    tcp    142.58.1.152.3537  <?>       
> 160.79.2.67.1755  4        2         96           96          TIM
> 19 Apr 02 10:50:37    udp    142.58.1.152.3539  <->       
> 160.79.2.67.2888  2430     2427      3722760      126204      TIM
> 
> 
> 	No frags indicated. Is the frag output depreciated 
> (i.e. I no longer need to look for it in 2.0.x output)? It 
> looks like the frag got reported as a standard packet only 16 
> bytes long.
> 
> Peter Van Epp / Operations and Technical Support 
> Simon Fraser University, Burnaby, B.C. Canada
> 
> 



More information about the argus mailing list