argus-*-rc.30 on the server

Carter Bullard carter at qosient.com
Mon Oct 2 12:30:42 EDT 2006


Hey Peter,
Hmmmm, OK, so argus-3.0 is currently reporting the libpcap reported  
on-the-wire
bytes, and argus-2.x is reporting the corrected bytes, adjusted by  
calculating
the difference between the length reported in the ip header and the  
remainder
of the packet length after parsing the encapsulation header.

So which is right?  Its clear that libpcap reports larger packets  
than are
actually written by the sender.  If I pick out one of your tcp  
connections,
say the one with source port 40669, the last packet in your trace is an
IPv4 based TCP ACK packet over ethernet, yet libpcap sez that the on-
the-wire packet length is 60 bytes.  That packet should be 54 bytes, 14
ethernet hdr + 20 IP header + 20 TCP header.

I think this is a known problem with libpcap, so ...., I took out the
'correction' code in argus-3.0 thinking that we should not be sensitive
to packet contents for stating what the packet length is (since this can
be faked).   Although libpcap is incorrect, should we stay with it or  
should
we correct the length?

Opinions?

Carter


On Sep 27, 2006, at 2:22 PM, carter at qosient.com wrote:

> Hmmmm, byte count changes?  I'll look into it tonight!!!
> And thanks on the OpenBSD reminder!!
>
> 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: Peter Van Epp <vanepp at sfu.ca>
> Date: Tue, 26 Sep 2006 22:04:26
> To:argus-info at lists.andrew.cmu.edu
> Subject: Re: [ARGUS] argus-*-rc.30 on the server
>
> 	Two apparant problems (although one may be a 2.0.6 bug). The  
> correction
> to ether_hostton got missed (it breaks on OpenBSD but works with  
> this patch):
>
> *** common/argus_util.c.orig	Tue Sep 26 08:31:44 2006
> --- common/argus_util.c	Tue Sep 26 08:34:44 2006
> ***************
> *** 2134,2145 ****
>      unsigned char ether_addr_octet[6];
>   };
>   #endif
> ! #if !defined(__APPLE_CC__) && !defined(__APPLE__)
> ! #if defined(__OpenBSD__)
>   extern int ether_hostton(char *, struct ether_addr *);
>   #else
>   extern int ether_hostton(const char *, struct ether_addr *);
> - #endif
>   #endif
>   #endif
>
> --- 2134,2143 ----
>      unsigned char ether_addr_octet[6];
>   };
>   #endif
> ! #if defined(__APPLE_CC__) && defined(__APPLE__)
>   extern int ether_hostton(char *, struct ether_addr *);
>   #else
>   extern int ether_hostton(const char *, struct ether_addr *);
>   #endif
>   #endif
>
>
> 	and there is a count issue still:
>
> %argus -r newcount.tcp -w newcount3.argus
> %argus_bpf -r newcount.tcp -w newcount2.argus
>
> %ra -r newcount2.argus -n
> 26 Sep 06 22:03:19           man  229.97.122.203   
> v2.0                   1 0     0        0         0             
> 0           STA
> 28 Aug 06 15:48:13           tcp    12.10.219.36.48467  ->    
> 206.12.128.12.http  57       91        3903         64769       FIN
> 28 Aug 06 15:48:36           tcp    12.10.219.36.40669  ->     
> 206.12.128.5.http  5        5         627          528         FIN
> 28 Aug 06 15:49:15  d        tcp    12.10.219.36.12561  ->     
> 206.12.128.5.http  119      167       7708         22910       FIN
> 28 Aug 06 15:48:46           tcp    12.10.219.36.30907  ->     
> 206.12.128.5.http  40       57        3167         16727       FIN
> 28 Aug 06 15:48:57  d        tcp    12.10.219.36.36414  ->     
> 206.12.128.5.http  142      582       8640         51781       FIN
> 28 Aug 06 15:49:30           tcp    12.10.219.36.33739  ->     
> 206.12.128.5.http  48       72        3559         40476       FIN
> 28 Aug 06 15:51:40  d        tcp    12.10.219.36.27353  ->     
> 206.12.128.5.http  163      622       9810         54074       FIN
> 26 Sep 06 22:03:19           man  229.97.122.203   
> v2.0                   8 0     2170     0         292752        
> 7           SHT
>
>
> %ra3 -r newcount3.argus -n
>     15:48:13.671089             tcp       12.10.219.36.48467     - 
> >      206.12.128.12.80           57       91         4173         
> 64781   FIN
>     15:48:36.068000             tcp       12.10.219.36.40669     - 
> >       206.12.128.5.80            4        3          585           
> 426   CON
>     15:48:46.044857             tcp       12.10.219.36.30907     - 
> >       206.12.128.5.80           40       57         3353         
> 16739   FIN
>     15:48:52.426051             tcp       12.10.219.36.40669     - 
> >       206.12.128.5.80            1        2           60           
> 120   FIN
>     15:48:57.270715   r         tcp       12.10.219.36.36414     - 
> >       206.12.128.5.80          142      582         9336         
> 52312   FIN
>     15:49:15.931324   i         tcp       12.10.219.36.12561     - 
> >       206.12.128.5.80          119      167         8236         
> 23117   FIN
>     15:49:30.634693             tcp       12.10.219.36.33739     - 
> >       206.12.128.5.80           48       72         3805         
> 40488   FIN
>     15:51:40.001284             tcp       12.10.219.36.27353     - 
> >       206.12.128.5.80          157      616        10194         
> 47855   FIN
>     15:51:45.817270   d         tcp       12.10.219.36.27353     - 
> >       206.12.128.5.80            6        6          366          
> 6806   FIN
>     22:02:47.290866             man                  0       
> 0                       29      1     2170       10            
> 29      1466880   STP
>
> 2.0.6 sum:
>
> 12.10.219.36 288679 251265 37414
>
> 3.0 sum:
>
> 12.10.219.36 292752 252644 40108
>
> when most (but not all) other values are correct
>
> 2.0.6
>
> 12.10.166.35 3890 2037 1853
> 12.10.217.50 157986 151332 6654
> 12.10.217.70 765 273 492
> 12.10.219.36 288679 251265 37414
> 12.10.248.90 1190 466 724
> 12.10.254.2 213 81 132
> 12.10.254.3 246 81 165
> 12.10.30.136 73 73 0
>
> 3.0
>
> 12.10.166.35 3892 2038 1854
> 12.10.217.50 158106 151368 6738
> 12.10.217.70 765 273 492
> 12.10.219.36 292752 252644 40108
> 12.10.248.90 1190 466 724
> 12.10.254.2 213 81 132
> 12.10.254.3 246 81 165
> 12.10.30.136 73 73 0
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>
>

Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20061002/ef45c02c/attachment.html>


More information about the argus mailing list