sloss, dloss, and loss in rc42

Can someone describe how the sloss, dloss, and loss counts will be 
affected by an argus probe that drops packets while monitoring?  In other 
words, if argus files do not contain all packets in a flow, will the 
missing packets be counted as "retransmitted or dropped"?  Or are those 
counts based solely on packets seen in a flow?  It's not clear what 
"dropped" means from the man page.  Thanks.

-Mike

Re: sloss, dloss, and loss in rc42

Hey Michael,
So there are basically two methods for realizing loss, 1) missing packets and 2) retransmitted packets. 
For protocols that have overt sequence numbers, tcp, esp and rtp, missing sequence numbers are counted as
loss (with allowance for packets out of order).  For tcp, multiple occurence of the same sequence number
indicates retransmissions, which is a direct indicator of loss and are also reported.  

Regardless where the loss occures, the probe will report missing packets as loss, so if the libpcap library
is dropping packets, or if all the packets are not captured, it could come up in the flow loss reporting. 
Hard to avoid that.

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: Michael Hornung <hornung <at> cac.washington.edu>
Date: Mon, 2 Apr 2007 10:11:37 
To:argus-info <at> lists.andrew.cmu.edu
Subject: [ARGUS] sloss, dloss, and loss in rc42

Can someone describe how the sloss, dloss, and loss counts will be 
affected by an argus probe that drops packets while monitoring?  In other 
words, if argus files do not contain all packets in a flow, will the 

Re: sloss, dloss, and loss in rc42

Thanks for the clear info, Carter.

-Mike

On Tue, 3 Apr 2007 at 02:47, carter <at> qosient.com wrote:

|Hey Michael,
|So there are basically two methods for realizing loss, 1) missing packets and 2) retransmitted packets. 
For protocols that have overt sequence numbers, tcp, esp and rtp, missing sequence numbers are counted as
loss (with allowance for packets out of order).  For tcp, multiple occurence of the same sequence number
indicates retransmissions, which is a direct indicator of loss and are also reported.  
|
|Regardless where the loss occures, the probe will report missing packets as loss, so if the libpcap
library is dropping packets, or if all the packets are not captured, it could come up in the flow loss
reporting.  Hard to avoid that.
|
|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: Michael Hornung <hornung <at> cac.washington.edu>
|Date: Mon, 2 Apr 2007 10:11:37 

libpcap ring buffer patches and SMP boxes

Hi All,

I'm currently trying to compile the version of libpcap from
http://public.lanl.gov/cpw/ on a FC6 dual core box.   I'm getting
conflicting definitions for some of the low level stuff in the
include/asm directory.

I note that other linux distros have an /asm dir in /usr/include -- what
I did on FC6 was to edit the make file to add a
-I/usr/src/kernel/..../include/asm

Has anyone hit this one before??

I know Peter uses the kernel patches from ntop but I don't have access
to a tame kernel monkey :)

Russell

Re: libpcap ring buffer patches and SMP boxes

On Wed, Apr 04, 2007 at 03:47:25PM +1200, Russell Fulton wrote:
> Hi All,
> 
> I'm currently trying to compile the version of libpcap from
> http://public.lanl.gov/cpw/ on a FC6 dual core box.   I'm getting
> conflicting definitions for some of the low level stuff in the
> include/asm directory.
> 
> I note that other linux distros have an /asm dir in /usr/include -- what
> I did on FC6 was to edit the make file to add a
> -I/usr/src/kernel/..../include/asm
> 
> Has anyone hit this one before??
> 
> I know Peter uses the kernel patches from ntop but I don't have access
> to a tame kernel monkey :)
> 
> Russell

	I think our current kernel is up for ftp from ftp.sfu.ca in 
/pub/unix/argus (and if not I can put it up)  but it is a SUSE kernel perhaps 
for PowerPC and it also contains the web100 changes for ndt so it may not 
work on RedHat (it seems SUSE does something odd at boot time and needs 
changes from a stock kernel which is the most likely cause of problems I 
expect). 
	It should be interesting to see how the Lanl kernel performs (I'd
expect very well ). 

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

Re: libpcap ring buffer patches and SMP boxes

Hi Russell,

Not quite what you are looking for but perhaps it will help?

http://wiki.ntop.org/mediawiki/index.php/Installing_on_Fedora_Core_5_%28FC5%29
http://wiki.ntop.org/mediawiki/index.php/Installing_on_Fedora_Core_4_%28FC4%29

The FC4 entry looks a bit more detailed.

HTH,
Harry

> Hi All,
>
> I'm currently trying to compile the version of libpcap from
> http://public.lanl.gov/cpw/ on a FC6 dual core box.   I'm getting
> conflicting definitions for some of the low level stuff in the
> include/asm directory.
>
> I note that other linux distros have an /asm dir in /usr/include -- what
> I did on FC6 was to edit the make file to add a
> -I/usr/src/kernel/..../include/asm
>
> Has anyone hit this one before??
>
> I know Peter uses the kernel patches from ntop but I don't have access
> to a tame kernel monkey :)
>
> Russell
>

racluster rc.42 problems

I have argus 2.0.6-fixes.1 + ... running on OpenBSD 4.0-stable and have a 
collector running on OpenSuSE running 3.0.0 rc 42 compiled with gcc 4.1.0. 
Configure was run as ./configure --prefix=/usr/local .  I'm under the impression 
that collecting with 3.0.0 from a 2.0.6 argus should work fine.  Carter, please 
correct me if I am wrong.

Collection has been stable and working fine.  I do post collection processing of 
the data to give me TopN type stats, along the lines of what Carter posted 
recently with racluster | rasort | ra.  I have run into some racluster issues.

First - a seg fault.  The command that sees the segfault is   racluster -M rmon 
-m saddr -r ... -w ...  .  Attached is sample data (segfault.dat) that causes 
the fault.  Seg fault was at common/argus_client.c:9535, but the fix looks to be 
common/argus_client.c:9505

switch (type = f1->hdr.argus_dsrvl8.qual & 0x07)

Changing to

switch ((type = f1->hdr.argus_dsrvl8.qual) & 0x07)

appears to fix the bug.  The output seems right, but I haven't dug into it in 
detail to ensure that there aren't minor discrepancies.

Second - things seem to go wrong after getting rtcp data.  Attached is sample 
data (rtcp-argus.dat) that causes this problem.

Apologies for the line wraps.

ra -r rtcp-data.argus

Application flooding with zero bytes packets...

Re: Application flooding with zero bytes packets...

On Thu, Apr 05, 2007 at 05:25:53PM +0000, real.melancon <at> videotron.ca wrote:
> Hello List,This question is not related to Argus specifically. But we have an application flooding a
server with zero-bytes packets over a specific TCP port. How would I identify it with Argus ?Thanks.Real.
> 
> ____________________________
> R?al Melan?on

	I assume you mean 0 payload bytes in the frame (because a 0 byte 
frame wouldn't route ) and that you don't know the source IP or port number
which is presumably what you want to find. In that case you probably want to 
compare the output of "ra -r file" and "ra -r file -A". The 
first will give you the size of the entire packet and the second will give you
only the application data layer (which should be 0 in this case). The machine
/ port you want will be the one with a large value in the first instance
(lots of packets but no data). Note this will also catch tcp ack packets 
but I'd expect them to be distributed across port numbers and the traffic 
of interest should be at the top of the list (lots of packets to one 
specific IP port). This trick also works well for assessing packet loss. 
In the no loss case the first value should be about %10 higher than the 
second, in a high loss situation there will be many more packets / data
in the first case than goodput in the second. 

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

Re: racluster rc.42 problems

I'm going to be out until Monday, but I'll try take a look before then. 

Thanks!!!!
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: Michael Sanderson <sanders <at> cs.ubc.ca>
Date: Thu, 05 Apr 2007 00:18:22 
To:argus-info <at> lists.andrew.cmu.edu
Subject: [ARGUS] racluster rc.42 problems

I have argus 2.0.6-fixes.1 + ... running on OpenBSD 4.0-stable and have a 
collector running on OpenSuSE running 3.0.0 rc 42 compiled with gcc 4.1.0. 
Configure was run as ./configure --prefix=/usr/local .  I'm under the impression 
that collecting with 3.0.0 from a 2.0.6 argus should work fine.  Carter, please 
correct me if I am wrong.

Collection has been stable and working fine.  I do post collection processing of 
the data to give me TopN type stats, along the lines of what Carter posted 
recently with racluster | rasort | ra.  I have run into some racluster issues.

First - a seg fault.  The command that sees the segfault is   racluster -M rmon 
-m saddr -r ... -w ...  .  Attached is sample data (segfault.dat) that causes 
the fault.  Seg fault was at common/argus_client.c:9535, but the fix looks to be 
common/argus_client.c:9505

switch (type = f1->hdr.argus_dsrvl8.qual & 0x07)

Changing to

switch ((type = f1->hdr.argus_dsrvl8.qual) & 0x07)

appears to fix the bug.  The output seems right, but I haven't dug into it in 
detail to ensure that there aren't minor discrepancies.

Second - things seem to go wrong after getting rtcp data.  Attached is sample 
data (rtcp-argus.dat) that causes this problem.

Apologies for the line wraps.

ra -r rtcp-data.argus
         StartTime    Flgs   Proto      SrcAddr        Sport   Dir      DstAddr 
       Dport  TotPkts   TotBytes State
07/04/02 23:55:06             tcp      154.20.43.121.cloant    -> 
142.103.6.67.imaps        10       1081   CON
07/04/02 23:55:42    s        tcp       142.103.6.47.60730     -> 
61.137.93.90.smtp          3        222   REQ
07/04/02 23:55:50            rtcp       62.236.60.53.6881      -> 
198.162.54.169.34307         1        105   INT


racluster -M rmon -m saddr -r rtcp-data.argus -w - | ra -r -
         StartTime    Flgs   Proto      SrcAddr        Sport   Dir      DstAddr 
       Dport  TotPkts   TotBytes State
07/04/02 23:55:42              ip       61.137.93.90          <- 
0.0.0.0               3        222   RSP
07/04/02 23:55:50              ip       62.236.60.53           -> 
0.0.0.0               1        105   INT


We should see data for the IP addresses above 62.236.60.53 here, but it isn't 
there.  If I recall correctly, on large input files, I see small, truncated 
output files from racluster as soon as I hit a record for rtcp.

racluster -M rmon -m saddr -r rtcp-data.argus -w - - not rtcp | ra -r -
         StartTime    Flgs   Proto      SrcAddr        Sport   Dir      DstAddr 
       Dport  TotPkts   TotBytes State
07/04/02 23:55:42              ip       61.137.93.90          <- 
0.0.0.0               3        222   RSP
07/04/02 23:55:42              ip       142.103.6.47           -> 
0.0.0.0               3        222   INT
07/04/02 23:55:06              ip       142.103.6.67          <-> 
0.0.0.0              10       1081   CON
07/04/02 23:55:06              ip      154.20.43.121          <-> 
0.0.0.0              10       1081   CON

Ignoring rtcp records gives me complete output for non-rtcp records.

I am currently working around this issue by using the 'not rtcp' filter on my 
racluster command lines.  I haven't looked for a fix for this one.

-- 
Michael Sanderson                   sanders <at> cs.ubc.ca
Computing Facilities Manager (Acting)   604 822 6194
UBC Computer Science		http://www.cs.ubc.ca/~sanders/