Re: where to get libpcap-ng?

[alexander medvedev <alexm () pycckue org>]

Hi,

i am trying to figure out how seriously one should consider the new format
and the extra useful information it supplies to the user.
here is my understanding of the current state of pcap-ng.
please, correct me, if i am wrong:

- the format for pcap-ng is somewhat finalized and has not changed
since March 2004 (almost 2 years);
- there exists an implementation of pcap-ng called NTAR project,
but that implementation is not quite complete (?);
- pcap-ng will eventually be a part of the current libpcap,i.e. libpcap
will be able to read both formats: current pcap and pcap-ng;
NTAR will possibly be a back-end for libpcap's API to hide details;
- there are no dates when pcap-ng functionality will be included in the
current libpcap.

thanks,

-alexm
10:38 10/01/2006

On Tue, 10 Jan 2006, Guy Harris wrote:

> Gianluca Varenni wrote:
> > ----- Original Message ----- From: "Guy Harris" <guy () alum mit edu>
> > To: <tcpdump-workers () lists tcpdump org>
> > Sent: Monday, January 09, 2006 12:09 PM
> > Subject: Re: [tcpdump-workers] where to get libpcap-ng?
>
>       ...
>
> > > At least as I understand it, it's an implementation of *part* of that
> > > standard - it handles the general structure of pcap-ng files (the
> > > "general block structure"), but doesn't interpret anything in the
> > > blocks that's not part of the general structure.
> >
> > Uhm, it dependes on what you mean by "general structure".
>
> I mean "I don't see any APIs in NTAR that deal with specific types of
> blocks; I just see APIs that deal with blocks in general".
>
> > I agree with you of having some basic support in libpcap to read and
> > write pcap-ng files using the existing libpcap APIs.
> > Instead, does it make sense to add new APIs on top of NTAR to support
> > all the features exported by it?
> > Whenever I think about this problem, I'm always struggling between two
> > visions:
> > - on one side, NTAR exports (or better, will exports) all the features
> > of pcap-ng, so it gives you complete control over the file format.
>
> At least from the online documentation, it "exports" them in the sense
> that you can read or write any type of block (including ones that don't
> exist in the pcap-ng specification).
>
> > Adding a libpcap layer on top of it means that every new feature in NTAR
> > may need a corresponding new API in libpcap.
>
> What sort of new features are you thinking of?  New block types?  Or
> something else?
>
> > This actually depends on
> > how the new libpcap APIs are defined, they could be general enough to
> > easily fit future enhancements of NTAR (or pcap-ng).
>
> At least some features of NTAR correspond to APIs for capturing (e.g.,
> "capturing packets" corresponds to the Packet Block, "enumerating
> interfaces" corresponds to the Interface Description Block, "getting
> capture statistics" corresponds to the Interface Statistics Block), so,
> at minimum, I don't see a problem with libpcap having routines to write
> the data fetched by those operations, rather than requiring the
> application to create the block and put some of the information into it
> with ntar_create_block(), add the rest of the information to the block
> with ntar_add_block_option() calls, and then close the block with
> ntar_close_block() when it's done - that code would be done the same for
> all libpcap applications, so it could go into libpcap.
>
> In addition, as there'd already by data structures supplied by those
> capture APIs, routines to process particular types of blocks and fill in
> those structures would also be useful.
>
> There'd probably be an API to get the next record, which would just call
> ntar_get_next_block(), ntar_get_block_type(), and ntar_get_block_data()
> when reading pcap-ng files (and fake those values when reading regular
> libpcap files, claiming that it has a Packet Block), and APIs to convert
>   the fixed data and options for a particular block into the data
> structure corresponding to that block.  For all other block types, the
> application would have to process the fixed data and options itself,
> with ntar_get_block_options().
> -
> This is the tcpdump-workers list.
> Visit https://lists.sandelman.ca/ to unsubscribe.


-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.