Re: where to get libpcap-ng?

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

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


> On Jan 9, 2006, at 9:12 AM, alexander medvedev wrote:
>
> > As far as i understood NTAR is an implementation of the pcap-ng 
> > standard,
>
> 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". At the moment it 
supports the Interface Description Block, the Simple Packet Block, and the 
Packet Block.
Moreover I plan to work in the next months to add an easier way to extend 
the library and support new blocks.

> > which uses different from libpcap API, i.e. ntar_open(), ntar_close (), 
> > etc.
> >
> > Are there any plans to implement this standard in libpcap?
>
> At some point I plan to implement support for reading pcap-ng files  in 
> libpcap, using NTAR.  I probably won't check that code into the  CVS tree 
> until NTAR is an Officially Released Project, so that  libpcap can rely on 
> it (it would become a dependency of libpcap).

This actually depends also on when the pcap-ng file format can be considered 
stable. There were some discussions last summer/fall to modify/enhance the 
spec to better support fast seeks in the file, but we didn't come out with a 
definitive solution (partially because I could find any time to work on it).

> > And, if there are plans, will there be a separate libpcap-ng or the  same
> > library will read/write two types of dumps?
>
> I intend to have one library for both file types.
>
> There will be new APIs; the current set can't support all pcap-ng  files, 
> and can't handle all types of blocks.  Applications using the  existing 
> APIs will support reading those pcap-ng files that, for  example, have 
> only one link-layer type, although not all of the  information in those 
> files will be available to those applications.

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. Adding a 
libpcap layer on top of it means that every new feature in NTAR may need a 
corresponding new API in libpcap. 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).
- on the other side, NTAR is very powerful, but it's also quite low level, 
so having a higher level libpcap interface may hide some details that 90% of 
the users are not interested in.

Any thoughts on it?

Have a nice day
GV


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