On Mar 23, 2004, at 1:06 PM, Jefferson Ogata wrote:
Michael Richardson wrote:okay. Can we call the next release libpcap 1.0 then? Anyone want to make any non-backwards compatible changes to the file format?
A metadata packet-type would be useful. Then you could tag a file with the pcap expression it was captured with, along with other metadata. If it's just a packet type you can drop in new metadata wherever you like.
Yes.
My inclination would be to have the per-packet header contain:
a 32-bit interface index, for the interface on which the packet arrived;
a time stamp;
the captured data length;
the actual packet length.
I suspect few, if any, machines will have more than 2^31 interfaces, so if the interface index has the uppermost bit set, it'd be a record type - the time stamp and actual packet length might or might not be meaningful, and the captured data length would be the length of the data in the record (so that code that doesn't know about that type of record can just skip it).
If the file magic number has the uppermost bit set, the file header would look like a record - and if we decree that it *is* a record (with the requirement that the first record of a file must be such a record), that could enable concatenation of captures by just concatenating files (which Michael Richardson has mentioned as a desirable goal).
There would also be records for interface properties, so that a capture would start with the "file magic number" record and then have, before the first packet on an interface, a record giving interface properties such as link layer header type, name, interface index, etc..
Other records could contain the filter expression, comments, packet drop statistics, etc..
- This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
