Ethereal-users: Re: [Ethereal-users] [Q-OT] Size of a trace and hub functions

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Fri, 9 Feb 2001 11:32:00 -0800 (PST)
> 	1. I needed to "catch" a file transfer error (FTP process) 
> resulting in incomplete file transfer (as you know, file transfer are 
> reported as "success" 226 regardless of whether the file made it 
> completely or not!) . Unfortunately this doesn't happen on a regular 
> basis, so I had no other choice than getting a large disk capable 
> Linux box, and run and save each day the ethereal trace. After 
> having re-visited a couple of traces, I was very surprised to see that 
> some of them didn't contain the whole day worth of data but only a 
> couple of hours, , while other days it worked just fine! So - my 
> question is: is there any problem in ethereal which would keep it 
> from recording continuously, other than disk space or memory 
> (which I have plentiful of both)?

None I know of other than either

	1) a bug causing it to crash while capturing

or

	2) an OS limitation on the size of capture files (e.g., a 2GB
	   limit).

In 1), there'd probably be a core dump file, and there might well be a
too-short packet at the end of the file (as there's no guarantee that,
before the crash, Ethereal would've written out only complete packets;
the buffering is done by the standard I/O library, which doesn't flush
the buffers to the file on "fwrite()" boundaries).

In 2), we unfortunately don't currently check whether an attempt to
write to a capture file fails (Wiretap checks, but Ethereal doesn't
check the error code when it returns - note the comment

	/* XXX - do something if this fails */

in "capture_pcap_cb()"), so you won't get notified of this problem. 
However, if the couple-of-hours capture is about 2147483647 bytes long,
that might have been the problem.