Hi, I've recently read the draft of the new file format -- very interesting. I'd like to raise a question here on a feature I've always thought would be useful: An offset, in addition to the snaplen. This feature is surely almost self-explanatory and in the old format it would be something like this in my opinion: [ ... ] [ accuracy ] [ snaplen ] [ offset ] [ layer type ] [ content ]
So the content of each packet captured would be ``offset[snaplen]''. This simple addition has the obvious effect of permitting a more efficient use of the format in terms of disk space -- for instance, if for some reason the informations of a given layer isn't needed, it can be easily skiped. I was searching for a similar feature in the draft -- couldn't find, and while I was doing a carefully reading of the Interface Description Block, I was wondering what could be the values of the "Reserved" field. This is a theorical example of a field that could be used to specify an offset... The "list of valid options" in this block also does not specify an option for something like an offset. I thought at first that it would be easy to suggest an addition of such a type as one of the goals pursued by the new format is the extensibility -- and it surely does it very competently. So something like this would do it fine: Name: if_offset Code: 14 Length: 4 Description: An offset value used for each packet (...) This option would break the format though, as the definition of the Packet Block specifies the Packet Data field as "the data coming form the network, including link-layer headers". Would not this wording restrict the extensibility of the format? IMO this field should be specified as loosely as possible. Anyways, if I were to specify that feature of an offset value, would that be better applicable as an option to a block or as a field in a block (in the interface description block, more specifically). -- Felipe Kellermann - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
