Wireshark · Wireshark-dev: Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?

["Gianluca Varenni" <gianluca.varenni@xxxxxxxxxxxx>]

----- Original Message ----- 
From: "Benn Bollay" <benn@xxxxxx>
To: "Developer support list for Wireshark" <wireshark-dev@xxxxxxxxxxxxx>
Sent: Friday, January 12, 2007 9:43 AM
Subject: Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?


> Hello GV -
>
> Thanks for the reply!
>
> It's interesting to see how people work around the limitations in the
> current pcap format.  One I'm is thinking of doing is utilizing the
> Ethernet Trailer (which you almost /never/ see anymore) to associate a
> lot of the data that pcap-ng would provide in a more elegent fashion.
> With a custom dissector, that should give us a lot of the features we're
> looking for.
>
> Is the seeking problem a mechanics issue, or an API issue?  I'd be

It's an API problem, in the sense that I haven't found a set of APIs that 
satisfies me 100%. I don't know if you ever looked at the NTAR APIs, however 
there are basically three handle types: file handles, section handles and 
block handles.
When you have an open block handle, you also have a corresponding section 
and file handle.
When you perform a seek between blocks, if the block is within the same 
section, everything works ok. What happens to the section handle block when 
you jump to a block in a different section?
Also, should it be possible to have a section seek pointer as well (so jump 
from a section to another, instead of block-to-block).

Regarding the implementation, it's not 100% trivial, and actually depends on 
how the new APIs are designed. At the moment i'm trying to create some 
samples with different API designs and see if they make sense or not...

> interest in talking about it more with you, or perhaps contributing a
> bit if that makes sense.

It would be definitely useful.

> How difficult will the integration into the std tools (tcpdump,
> Wireshark, et al) be once a consistent API is implemented?  One wonders
> if it would be possible to provide a pcap interface to a pcap-ng file,
> and circumvent a lot of the immediate compatibility issues.

Modifying libpcap to write pcap-ng files is quite easy, as pcap-ng is a 
superset of the pcap format. Reading is much more tricky. The problem is 
that the current libpcap API to read pcap files doesn't support all the 
features of pcap-ng (the most important one is probably the fact that a 
capture file can contain packets coming from multiple interfaces and link 
layers at the same time). In this case an idea is to modify the internals of 
libpcap to support a minimal set of the pcap-ng features without changing 
the current API (e.g. files with only one section and packets from one 
interface).

IMHO the best thing to do would be better decouple packet capture from 
packet logging to file. libpcap is the capture library, NTAR (or any other 
library) is the library used to read/write capture files.

Just my two cents.
GV

> Cheers!
> --Benn
>
> > -----Original Message-----
> > From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-
> > bounces@xxxxxxxxxxxxx] On Behalf Of Gianluca Varenni
> > Sent: Thursday, January 11, 2007 4:39 PM
> > To: Developer support list for Wireshark
> > Subject: Re: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?
> >
> > Benn,
> >
> > regarding the NTAR project (i.e. the only implementation of the
> pcap-ng
> > "wannabe" spec so far) that I "maintain", I've been pretty busy in the
> > last
> > year or so, thus not being able to work on it. The project is not dead
> at
> > all, I'm simply giving priority to other tasks...
> >
> > As far as the integration with wireshark is concerned, technically
> > speaking
> > there is one big feature missing from NTAR that is needed by
> wireshark,
> > that
> > is seeking within a file.
> > I started working on it during the xmas holidays, but I haven't come
> out
> > with a definitive API for it. The main problem I'm having is the
> hierarchy
> > of the file (packets are embedded in blocks which are grouped into
> > sections)
> > that make everything much more complicated. I plan to work on it in
> the
> > upcoming weeks and post something on the NTAR website as soon as
> possible.
> > I think that the wireshark devs have a great interest in moving to
> pcap-ng
> > as the standard trace format (being it through NTAR or reimplementing
> the
> > spec), I have no idea where this task sits within the Wireshark
> roadmap,
> > and
> > if this task would fit before or after the 1.0 milestone.
> >
> > Have a nice day
> > GV
> >
> >
> >
> > ----- Original Message -----
> > From: "Benn Bollay" <benn@xxxxxx>
> > To: "Developer support list for Wireshark"
> <wireshark-dev@xxxxxxxxxxxxx>
> > Sent: Wednesday, January 10, 2007 2:27 PM
> > Subject: [Wireshark-dev] Is pcap-ng/ntar still in roadmap?
> >
> >
> > > Hello all -
> > >
> > > Is the next-gen pcap format still in the roadmap at all?  I've heard
> > > nothing about it for ages; there doesn't seem to be any discussions,
> nor
> > > any implemention details for well over a year now.
> > >
> > > I'm trying to decide whether I should hack-up the libpcap format or
> > > spend more development effort and move entirely to something else.
> > >
> > > Cheers,
> > > --Benn
> > > _______________________________________________
> > > Wireshark-dev mailing list
> > > Wireshark-dev@xxxxxxxxxxxxx
> > > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >
> > _______________________________________________
> > Wireshark-dev mailing list
> > Wireshark-dev@xxxxxxxxxxxxx
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev