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 13:33:59 -0800 (PST)
> ... and I just checked about the suggested possible limitations: it 
> stops around 180 - 270,000 frames (no consistency in terms of 
> number of frames), and around 100 - 150 MB size (no pattern on 
> size, either), and nothing else points to any limitation other than 
> just the fact that it does not "save" everything

It attempts to write to the capture file every packet that it receives
from libpcap; it reads from the capture stream by calling
"pcap_dispatch()" with the callback routine argument pointing to
"capture_pcap_cb()", which calls "wtap_dump()" for every packet, unless
somehow the pointer to the stream to which "wtap_dump()" writes got
zeroed out by some bug.

Unless "wtap_dump()" gets an error writing to the file, or there's some
bizarre bug that zeroes out that pointer or something such as that, that
means every packet Ethereal receives from libpcap *will* be saved.

Now, there's no guarantee that libpcap will see every packet on the
wire; the kernel packet capture mechanism might drop packets if they
arrive too fast and the buffer it uses fills up, for example. 
Unfortunately, Linux libpcap doesn't currently report the number of
dropped packets, and Ethereal doesn't use "pcap_stats()" to get the
statistics in any case, so there's no way to know whether packets have
been dropped.