Re: where to get libpcap-ng?

[Guy Harris <guy () alum mit edu>]

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.