LEGO wrote:
Well supporting a (rw) file type that allows for several different
encapsulations to coexists in the same capture file would be great.
But, is the pcap-NG spec already usable?
ie. are we already at the point where future changes in the format
won't broke backwards compatibility?
I'm not sure; it's already being used in one product, although it's a
somewhat specialized one (used for an avionics protocol).
That's something probably best asked on the ntar-workers list.
Note that "ntar" is a library for handling the "syntax" of pcap-NG
files; it doesn't handle the semantics of particular record types. Its
developers have suggested that it be used, even in Ethereal, for reading
pcap-NG files; they've added a mechanism to support a "plug-in"
lower-level access library, so we'd plug in support for handling
compressed files, for example.
The library has not, as far as I know, been released yet. That'd be a
bit of an obstacle for using it in Ethereal. :-)
There's also an issue somebody noted, namely that parts of a pcap-NG
file could be big-endian and other parts little-endian, and random
access to the file - which Ethereal requires - would have to be able to
figure out what byte order a particular part is in. A data structure
mapping file offsets to byte orders could probably handle this, as there
probably won't be a *lot* of parts (that would be the result of
concatenating files captured on big-endian hosts and on little-endian
hosts). However, I'm not sure that issue's been resolved yet - which
would be another obstacle.
At this point, just converting the headers of one of the captures to
another format would probably be the simplest and best solution.