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.
