Hey Guys,
   Sorry I've been delayed in responding.  Out on business
and some DSL problems %(  OK, didn't I send a patch for
this one?  I should have if I didn't.  This will fix this
one, and it is in "F" which should have come out this past
weekend but I'll try to have tomorrow.

Carter

cvs diff ArgusModeler.c
Index: ArgusModeler.c
===================================================================
RCS file: /usr/local/cvsroot/argus/server/ArgusModeler.c,v
retrieving revision 1.96
diff -r1.96 ArgusModeler.c
450c450
<    if ((ArgusThisNetworkFlowType & 0xFFFF) == ETHERTYPE_IP) {
---
>    if (ArgusThisIpHdr && ((ArgusThisNetworkFlowType & 0xFFFF) == ETHERTYPE_IP)) {

--

-----Original Message-----
From: owner-argus <at> lists.andrew.cmu.edu
[mailto:owner-argus <at> lists.andrew.cmu.edu]On Behalf Of Russell Fulton
Sent: Monday, December 04, 2000 8:39 PM
To: argus <at> lists.andrew.cmu.edu
Subject: E Server crash

#0  0x804af59 in ArgusUpdateFlow (flowstr=0x8279d00, state=1 '\001') at
./ArgusModeler.c:451
451           if (((ArgusThisIpHdr->ip_off & 0x1fff) == 0) &&
(ArgusThisIpHdr->ip_off & IP_MF)) {
(gdb) l
446       
447        flowstr->state.lasttime = ArgusGlobalTime;
448        flowstr->qhdr.lasttime  = ArgusGlobalTime;
449
450        if ((ArgusThisNetworkFlowType & 0xFFFF) == ETHERTYPE_IP) {
451           if (((ArgusThisIpHdr->ip_off & 0x1fff) == 0) &&
(ArgusThisIpHdr->ip_off & IP_MF)) {
452              struct ArgusFlowStruct *frag = NULL;
453
454              ArgusThisLength = ArgusCurrLength;
455
(gdb) p ArgusThisIpHdr
$1 = (struct ip *) 0x0

Argus has been running several days.

Hey Russell,
  Yes I have fixed this in the mythical "F" release,
which I hope to have out tomorrow.  Sorry for the delay!!!!

What is the "_" notation at the of your records?
Am I doing that or are you ;o)

Carter

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

carter <at> qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426

-----Original Message-----
From: owner-argus <at> lists.andrew.cmu.edu
[mailto:owner-argus <at> lists.andrew.cmu.edu]On Behalf Of Russell Fulton
Sent: Monday, December 04, 2000 7:47 PM
To: argus <at> lists.andrew.cmu.edu
Subject: Still problems with ra -A (and tcp smurf logs)

I am still getting the occasional screwy count with -A.  In this case
everything was fine except for the 255.255.255.255 records.

bash-2.04$ bin/ra -Zb -ncr data/2000.12.04/argus-2000.12.04.21.00.gz - host 216.93.65.65 | grep 255.255
04 Dec 00 20:55:49.851285   tcp 255.255.255.255.80     o>      216.93.65.65.38971 192      0         12288        0           RA_

04 Dec 00 20:55:48.705615   tcp 255.255.255.255.80     o>      216.93.65.65.46588 246      0         15744        0           RA_

04 Dec 00 20:55:47.292610   tcp 255.255.255.255.80     o>      216.93.65.65.46587 764      0         48896        0           RA_

04 Dec 00 20:55:48.511802   tcp 255.255.255.255.80     o>      216.93.65.65.38970 768      0         49152        0           RA_

bash-2.04$ bin/ra -AZb -ncr data/2000.12.04/argus-2000.12.04.21.00.gz - host 216.93.65.65 | grep 255.255
04 Dec 00 20:55:49.851285   tcp 255.255.255.255.80     o>      216.93.65.65.38971 192      0         0            -162525840  RA_

04 Dec 00 20:55:48.705615   tcp 255.255.255.255.80     o>      216.93.65.65.46588 246      0         0            -324525512  RA_

04 Dec 00 20:55:47.292610   tcp 255.255.255.255.80     o>      216.93.65.65.46587 764      0         0            -1983371664 RA_

04 Dec 00 20:55:48.511802   tcp 255.255.255.255.80     o>      216.93.65.65.38970 768      0         0            1492133488  RA_

In case any of you are wondering what provoked this weird traffic, it
resulted from a tcp scan (ACK to port 80) directed against
130.216.*.255.  Some sort of tcp smurf?

Here is a sample of the triggering traffic:

04 Dec 00 20:56:01.574232   tcp    216.93.65.65.38971  o>   130.216.202.255.80    1        0         64           0           A_

04 Dec 00 20:56:01.577682   tcp    216.93.65.65.38971  o>   130.216.203.255.80    1        0         64           0           A_

04 Dec 00 20:56:01.578219   tcp    216.93.65.65.38971  o>   130.216.204.255.80    1        0         64           0           A_

04 Dec 00 20:56:01.579589   tcp    216.93.65.65.38971  o>   130.216.205.255.80    1        0         64           0           A_

04 Dec 00 20:56:01.581133   tcp    216.93.65.65.38971  o>   130.216.206.255.80    1        0         64           0           A_

04 Dec 00 20:56:01.583455   tcp    216.93.65.65.38971  o>   130.216.235.255.80    1        0         64           0           A_

I'm picking that 216.93.65.65 is the victim not the perpetrator.
Looks like its time to block *.255 for tcp (I thought we alread did but obviously not :( ) as well as udp and icmp.

Anyone know why responding packets have source of all 1s?
A few machines did respond with their own source addresses.

Cheers, Russell.

Gentle people,
   The long anticipated "F" release is now on the server.
This fixes a major dumping bug, as well as non-dumping
negative TCP application byte reporting.  This also
fixes a zombie issue when reading *.gz files, and a
number of interesting but very esoteric formatting
problems with reading ramon() output with ra().

ftp://qosient.com/dev/argus/argus-2.0/argus-2.0.0F.tar.gz

Please use this release in all testing.
Thanks!!!!!!!!

Carter

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

carter <at> qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426

Gentle people,
   I of course will be working on "G" tomorrow (Wed) but
I will be traveling on Thursday-Sunday, and at the IETF
next Monday-Friday, so I may not be able to get another
update out until I get to San Diego (Monday).

   In "G" I hope to get in:
      Netflow reading bug.
      Mods for NetBSD port.
      SASL based Cryptographic protection.
      A strange Linux/Sparc incompatibility.
      ramon sorting problem.
     
   I will be trying to wrap the whole thing up
soon, so if there is an outstanding issue that I've
left out, please send me some mail.

   Still going for a this month release, so if there
are any contributions that anyone wants to make to
the examples or contrib directory, now is the time!!!!!

Carter
     

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

carter <at> qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426

I pulled the data file from black-bird. The name of the file reflects the date (11/23 was it?)

 

Why does the linux version not care that the size of the record is 0?

 

Walter

-----Original Message-----
From: Mark Poepping [mailto:poepping <at> CMU.EDU]
Sent: Wednesday, December 06, 2000 9:14 AM
To: carter <at> qosient.com; 'Walter Wong'
Subject: RE: byte order?

 

I'd expect 'E', since that's what's running on black-bird, but I'm not sure

where Walter got the data.  I'll do 'F' later today.

mark.

 

-----Original Message-----
From: Carter Bullard [mailto:carter <at> qosient.com]
Sent: Wednesday, December 06, 2000 9:10 AM
To: 'Walter Wong'; 'Mark Poepping'
Subject: RE: byte order?

Hey Guys,

   An update on our problem.  The Argus Start Record that we're working with

thinks that the size of the argus records in this stream are zero (0) bytes

long.  So we bail on the first read.  This I can fix, BUT, the better solution

is to find out how this value got to be zero (0).  So, what version generated

this output file?  Was it "A" by any chance?

 

Carter

 

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

carter <at> qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426

-----Original Message-----
From: Walter Wong [mailto:wcw+ <at> cmu.edu]
Sent: Tuesday, December 05, 2000 8:30 PM
To: Mark Poepping
Cc: Carter Bullard
Subject: RE: byte order?

Good point...

 

machine is sol2.nas.cmu.edu. You should be able to ssh in.

 

file is in /mnt/dat.

 

Files should be the same -- one is just gzip'd and one is not.

 

'E' is compiled and in /mnt/argus/bin.

 

Walter

-----Original Message-----
From: Mark Poepping [mailto:poepping <at> CMU.EDU]
Sent: Tuesday, December 05, 2000 2:48 PM
To: Walter Wong
Cc: carter <at> qosient.com
Subject: RE: byte order?

 

I sponsor an account for carter, so yes, he does have access

to a sparc and linux.

mark.

 

-----Original Message-----
From: Walter Wong [mailto:wcw+ <at> cmu.edu]
Sent: Tuesday, December 05, 2000 10:16 AM
To: carter <at> qosient.com
Cc: 'Mark G Poepping'
Subject: RE: byte order?

oh man. You don't have a magic fix? Now I have to do some real work.

 

Do you have access to both a sparc and a linux box? If not, let me know and I'll try it the other way (generate a dump on a sparc and see if fails on the linux box).... and if you are making me do more work, I guess I could also step through the code and find out exactly where ArgusReadStreamSocket is bugging out.

 

If you do have access to a sparc, I'll try to pare down the file and send it to you. In its current form, the file is only a couple orders of magnitude too big to email.

 

On a side note, if you do a 'ra -r *.gz -', a pclose (or wait3) doesn't happen so the gzips stick around as zombies until the process exits.

 

Walter