Re: Proposed new pcap format

[Guy Harris <guy () alum mit edu>]

On Fri, Apr 09, 2004 at 06:29:42PM +1000, Ronnie Sahlberg wrote:
> A capture application could then initially write length==0 when it first
> writes out the SHB and then not seek() back and write the real length until
> it closes the SHB.

...unless it's writing to a pipe; I think people sometimes do run
tcpdump writing to the standard output and have another application
reading from it.

> I think one should add a 64bit length field to the SHB which can optionally
> be 0 meaning : length of SHB is unknown which would then cause
> the readed to fallback to read one block at a time until the next SHB is
> found.

Presumably, in that case, if writing to something non-seekable, it'd
just just leave the SHB length as 0.

> 3.3
> the packet block has a description of which interface the packet was
> captured on.
> It should also have a mandatory flag that describes whether we picked the
> packet from Rx or Tx on the interface.
> This should be a mandatory field in the header (1 bit) and not
> optional.

I'd prefer a general flag field, which would include a direction
indication (which might also include, for received packets, an
indication of how it was received, e.g.
unicast/multicast/broadcast/promiscuous/not specified), and could also
include some other information (length of FCS, with 0 meaning "absent",
and possibly link-layer-type-dependent error flags such as "runt frame",
"bad CRC", etc.).

> 2.1
> is it necessary to allow nesting?  would it be useful or wouldnt it only add
> complexity?

I don't see any place in the spec where nested blocks are used - is that
just a suggested possibility?

> Application specific blocks:
> ----------------------------
> It would also be nice to have a mechanism to store user/application specific
> data in a capture file.
> I would like to be able to store  etherealisms like  color-filters,
> capture-filters, display-filters etc etc inside a capture file
> I would later send to colleagues.

We'd just register block types for Ethereal and use that.

> I am certain there are other kinds of metadata that users of other tools
> would like to store in the file as well.

They'd do the same.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.