Gianluca Varenni wrote:
1) the existing libpcap API, which will handle as much of pcap-ng as it
can (ignoring some records, discarding some data in others, failing as
soon as it sees a link-layer type other than the first one it saw);
I think the main problem here is how to deal with multiple capture
interfaces within a section and multiple sections.
The alternatives I see are
1) fail as soon as a second capture interface or a second section
header is seen;
2) fail as soon as a capture interface with a link-layer type or
snapshot length different from the first interface's link-layer type is
seen, and don't worry about section headers.
2) a newer API, which exposes the full capabilities of pcap-ng, and
also transparently supports reading old-style libpcap files.
I would prefer to have a separate API set (being it NTAR or anything else)
to deal with capture files.
One of the things I like less about libpcap is that the API to read/write
files is too much tied to the capture one without any specific reason.
Requiring the loop that reads a saved file to be different from the loop
that captures live packets wouldn't bother me too much.
However, there are capture APIs that should be tied to the file format;
for example, the APIs that return interface properties (there should be
"enumerate all interfaces" and "get interface property" APIs) should
return something very much like an Interface Description Block, and the
API to get capture statistics should return something very much like an
Interface Statistics Block. (The current APIs for both suck because
they're not extensible, which is an issue for both - we'd have to change
a data structure to add properties such as link-layer addresses to the
interface properties returned by pcap_findalldevs(), and not only is
there no way to add new statistics to what you get from pcap_stats()
without changing the data structure, there's no way to indicate that
some statistics are unavailable without changing the data structure.)