> In "logical transmission" mode, the multiple packets of a single
> transmission are grouped together. In "logical transmission" mode,
> some packets are still a single tranmission (like a BOOTP broadcast). In
> the table of packets, these packets would maintain their datalink
> types (DLT_FDDI, WTAP_ETHERNET, whatever). But the packets that have
> been grouped together get a different 'datalink' type, say LOG_TCP,
> LOG_SPX, LOG_IP, or whatever the layer at which the packets are
> grouped together is.
>
> Then the data from the group of packets,
Note that, currently, Ethereal remembers the offset in the file of the
data for each packet, and, when you click on a packet,
"packet_list_select_cb()" seeks to that offset and reads the packet data
into "cf.fh". There's currently no mechanism for keeping data for more
than one packet in memory.
"snoop" and, I suspect, Microsoft Network Monitor memory-map the capture
file. We could probably "mmap()" the file on most platforms and, on
those that don't support "mmap()" (if Ethereal works on any of them), we
could allocate a buffer the size of the file, and read the capture file
into it.
This wouldn't work if you're reading from a pipe, but we'd probably have
to modify "wiretap" not to do seeks in order to make reading from a pipe
work (it may be doable - read in the first 4 bytes of the capture file,
use that to figure out the type of capture file, and then read in the
rest of the header, etc.; that works as long as all capture file formats
are unique in the first four bytes - all of the ones we support appear
to be). On a pipe, we'd probably have to make multiple allocations and
read incrementally into them, as we don't know how much data there is to
read.
One disadvantage of this is that it can't handle capture files that
won't fit into Ethereal's address space, however.
