> While I am at it I would like to try and seek acceptance for a new file
> format.
There have also been discussions on tcpdump-workers@xxxxxxxxxxx about a
new file format; I'd prefer to try to solve as many problems as possible
with one new file format, so I don't want to add new capture file
formats too quickly.
Some goals I see for a new capture file format:
able to handle multiple packet encapsulation types in a single
capture
somehow records the names of the network interfaces, so that in
a multiple-interface capture file the packets can be associated
with the interface (people have asked for this on
tcpdump-workers, as tcpdump 3.6[.x] can capture on the "any"
device on Linux (as can Ethereal 0.8.15) - names, *not* just
Linux-style indices, so that the capture file can be read on a
machine other than the one on which the capture was made
perhaps records packet loss, etc. statistics in some fashion
(snoop format does this, see RFC 1761, and Network Monitor does
this, too, albeit in a somewhat gross fashion - the statistics
look like fake Ethernet frames)
records, with each packet, an indication of whether the packet
was
sent by this host
unicast to this host
broadcast
multicast to an address this host accepts
received promiscuously ("none of the above")
was received for some unknown reason (as on platforms
where the capture mechanism doesn't tell you the above)
as both Linux and Digital UNIX supply at least some of that
information (and I saw something suggesting that the LBL folks
at least contemplated it as a good idea for BPF) - the
indication should be in a form readable even on platforms
*other* than the one on which it was captured
perhaps copes with the fact that some FDDI interfaces and the
drivers for same appear to supply MAC addresses in bit-reversed
form to the packet capture mechanism, so that you can tell from
the file what bit order was used
perhaps allows packets, on platforms with memory-mapped capture
devices (Linux 2.4 and later, perhaps some or all of the BSDs
with some stuff somebody's working on, perhaps others - I wish
I'd done the memory-mapped stream head stuff I was thinking
about when I was at Sun, as you could have gotten that on SunOS
4.x and 5.x and possibly other OSes), to be written directly
from the memory-mapped area, for speed (this might mean multiple
capture file formats for different platforms).
I also would want this capture file format to be readable by libpcap,
and to have tcpdump handle it, so that it could be used by more than
just programs that use Wiretap.
I'm CCing tcpdump-workers on this.