Re: where to get libpcap-ng?

["Gianluca Varenni" <gianluca.varenni () cacetech com>]

----- Original Message ----- 
From: "alexander medvedev" <alexm () pycckue org>
To: <tcpdump-workers () lists tcpdump org>
Sent: Tuesday, January 10, 2006 8:40 AM
Subject: Re: [tcpdump-workers] where to get libpcap-ng?


> 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);

Yes, apart for some minor fixes/modifications in the last year (I added 
several details related to alignment of the structures in summer 2004, for 
example).

> - there exists an implementation of pcap-ng called NTAR project,
> but that implementation is not quite complete (?);

The implementation supports the basic block/section scheme, has an initial 
infrastructure for the definition of plugins to deal with new block types 
(that I still want to work on), plus some plugins to save and read the 
following block types:
- interface description block
- simple packet block
- packet block

The name resolution block has not been implemented yet, but it should be 
quite easily to add.
Same for the interface statistics block.
All the blocks under paragraph "Experimental blocks" have not been 
implemented because they are not completely specified.

My main concern is not usually in these blocks or in working with the NTAR 
code (although a lot of work still needs to be done, and the my spare time 
is always few...). I'm more worried in the specification itself, and if 
there are still breaking changes that need to be done to it; for example the 
problem of seeks and a further block nesting level to group packets in 
chunks. And I think the only solution is to add an experimental support for 
pcap-ng (with NTAR?) to a common tool like ethereal (I'm open to any other 
tool, actually) and see if there limits with the current file specification. 
What do you think?

GV

> - 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.

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