tcpdump mailing list archives
Re: Proposed new pcap format
From: Guy Harris <guy () alum mit edu>
Date: Fri, 9 Apr 2004 01:51:14 -0700
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.
Current thread:
- Re: Proposed new pcap format, (continued)
- Re: Proposed new pcap format Richard Sharpe (Apr 07)
- Re: Proposed new pcap format Michael Richardson (Apr 12)
- Re: Proposed new pcap format Loris Degioanni (Apr 13)
- Re: Proposed new pcap format Ronnie Sahlberg (Apr 09)
- Re: Proposed new pcap format Darren Reed (Apr 09)
- Re: Proposed new pcap format Guy Harris (Apr 10)
- Re: Proposed new pcap format Darren Reed (Apr 10)
- Re: Proposed new pcap format Michael Richardson (Apr 12)
- Re: Proposed new pcap format Ronnie Sahlberg (Apr 13)
- Re: Proposed new pcap format Darren Reed (Apr 09)
- Re: Proposed new pcap format Guy Harris (Apr 09)
- Re: Proposed new pcap format Darren Reed (Apr 12)
- Re: Proposed new pcap format Michael Richardson (Apr 12)
- Re: Proposed new pcap format Ronnie Sahlberg (Apr 13)
- Re: Proposed new pcap format Darren Reed (Apr 13)
- Re: Proposed new pcap format Guy Harris (Apr 13)
- Re: Proposed new pcap format Michael Richardson (Apr 16)