argus-*-rc.30 on the server

[Peter Van Epp]

On Mon, Oct 02, 2006 at 12:30:42PM -0400, Carter Bullard wrote:
> 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
> 

	Ah! our friend ethernet padding! I think for most things the libpcap value is probably better. Whats happening is there 
is a minimum packet size of 60 bytes on the wire and the ethernet cards will pad an underlength packet out to 60 bytes. For
rate calculations this is the count we would like to use, because it is actual bytes on the wire and indicates how long the
packet really was on the wire for utilization purposes so I'd vote for leaving the value at the libpcap value. 

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