strange argus records

[Carter Bullard]

Hey Alexander,
   Hmmmmm, you may have tickled a bug in the 1.7e TCP
source packet count logic.  I use to see this with argus-1.5
where occasionally we would get a report of a TCP connection with
an ungodly number of packets from the source.  In fact, 
the 1.5 ra(), actually had some logic to check for ungodly
numbers.  I thought we had fixed that in 1.[67], but you
know how bugs can be.

   To answer your question about certain kinds of input causing
problems.  I'm sure that the answer is yes, but I think we've
got all the ones we know about in the 1.8 code.

   You can suppress the 'unas' mapping with the -nn option (2 -n's)
which will show you the actual protocol number that was in the
packet stream.  This might help to rule out data corruption, which
has a probability, but I feel like that number is really low.

   We are reporting that the flow had IP Timestamp Options set, which
seems interesting in its own right.     Do you have any other crazy
looking records that may be clustered around this one in the file?
Especially with the T indicator set?

Carter


-----Original Message-----
From: Alexander Bochmann [mailto:bochmann at mupfel.infra.de]
Sent: Friday, April 16, 1999 4:47 AM
To: argus at lists.andrew.cmu.edu
Subject: Re: strange argus records


...on Fri, Apr 16, 1999 at 09:03:16AM +1200, Russell Fulton wrote:

 > On Thu, 15 Apr 1999 15:50:40 +0200 Alexander Bochmann 
 > <bochmann at mupfel.infra.de> wrote:
 > > Mon 10/14 18:21:19T    unas     30.99.31.97       <-> xxxxxx.xxxxx.de       150339664 38      37        409      CON
 > > Is there something broken? (This is argus-1.7.beta.1e on a Linux box.)
 > This looks like another symptom of the incomplete read problem which 
 > linux system seem to be more prone to.  Carter has patches for it which 

It's mildly strange, because at least the (obviously spoofed) IP 
address 30.99.31.97 also shows up in a cisco accounting logfile 
(would have to look up the traffic, though, but if I remember correctly 
it was only a handfull of bytes at east in the one record I saw)... 
The (x-ed out) receipient address is also ok.

 > The other possibility is that the ra input file was corrupt.  (unas is 
 > short for unassigned -- I think i.e. the field was garbage like the 
 > rest of the record). 

I assume that at least part of the record is actually correct - is there 
any kind of traffic that can break argus' recording and/or reporting?

Alex.