Richard Sharpe wrote:
>
>Hmmm, you might want more bytes here, and this does not seem to get at
>your needs for multiple frame/PDU types in the capture, unless one of the
>values here is: 0xFF=frame/pdu type in the frame.
>
>I like the concept of TLVs here. Is this per-frame data or per-capture
>data? Above, you seem to have fields, like the version, that is
>per-capture data, but here we seem to have moved to per-frame data.
Actually in this specific example I was describing how the per-frame data could look when the LINKTYPE in the libpcap file header is indicating that there is multiple frame/PDU types in the capture, so actually all the data was "per-frame data" in my example.
I was maybe not so clear about that.
I'm not sure that there is a need for a "version byte" per frame but I had it there similar to Jeff Morriss's fakelink example.
I'm not sure right now exactly what data I want on per-fram-basis except the TLV data and some different ways to describe what frame/PDU type is included in that specific frame. The example I provided was very very preliminar ideas before discussing with other people etc.
As a start I was thinking of trying to look on how I can get multiple frame/PDU types into the existing libpcap format with optional TLV data
on per-frame-basis (and try to get a LINKTYPE value for it), but I also have been thinking a bit wider about what is lacking in the current libpcap format.
There is a lot of data that could be good to store on per-file basis. I think that a new file format should be designed to handle that.
When using a "multiple frame/PDU types" LINKTYPE in the current libpcap format you could maybe have one or several frames in the beginning of the file that includes "global meta data" (a specific frametype).
However this is not as nice as using a new file format where this data could be part of the file header, but it could at least be useful for some of the things I want to do.
