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