Wireshark-dev: Re: [Wireshark-dev] [ntar-workers] Extending Wireshark libpcap format support, o
Gianluca Varenni schrieb:
First of all, sorry for taking a bit of time to answer this thread, I was
working on libpcap/WinPcap. libpcap 1.0 is planned to come out soon...
No problem, a few hours is still a good value ;-)
It's true. Consider that PPI and pcap-ng/ntar have different objectives (as
written in the PPI spec): PPI is used to append meta-information from
packets captured from a live source.
Yes, I understand. But at least some of the meta info (like the capture
interface info) is required already to be saved at capture time. So
pcapng would in fact be a capture file format.
So no annotations like "oh, this is an
interesting packet".
Yes, that would be done *after* the life capture was finished - and
probably on a copy of the original capture file.
pcap-ng/NTAR is a trace file format. I would consider
pcap-ng/ntar a super-set of PPI
ACK
PPI might even get obsolete once pcapng is implemented in Wireshark and
has gained wide acceptance.
The spec at www.winpcap.org/ntar is pretty stable. Back in March 2006 I
cleaned up the spec (some items were not clear) and added some appendices.
There are still things missing, in particular the definition of blocks for
easy navigation in the file.
I have reviewed that doc for a few hours today. Now I have a printout
with lot's of minor comments probably worth to be included. Most of them
is about clarifying stuff and make the document easier to read (well,
and some typos). The only really questionable thing I found was the name
resolution block. I don't see a reason to have optional block content
and options as well - in fact it was hard to understand. Why not use
only option fields there?
I guess it would be a good idea to include my review comments into the
spec. What would be best way to get them included?
As far as I know, no. What do you mean by "low level"? A more user-friendly
API like "OpenFile/ReadPacket/WritePacket/CloseFile"? One of the main
problems I had when developing NTAR was the richness and complexity of the
format (e.g. the problem of multiple sections in a file, the support for
multiple interfaces within a section).
Yes, I guess one of the problematic things to include pcapng into
Wireshark is to find a good interface between libwiretap and Wireshark
(or probably no interface at all). There are a lot of new concepts in
pcapng that has no counterpart in the current Wireshark implementation.
I can definitely create some trace files, either synthetic or real (with
ntar). A friend of mine developed a simple app to convert libpcap files into
pcap-ng files. I need to have a look at it. It depends if you want simple
captures or something using the various features of pcap-ng (multiple
interfaces, multiple sections, different byte order in the file).
Some simple example files would be enough, it's only to find a starting
point (but I'm not in a hurry about that).
NTAR is still alive, but in the last year or so I didn't have any time to
work on it. In order to work within wireshark, the big missing feature is
relative to random access in the file. I have some code on my machine to
deal with that, but it doesn't work properly. I might have some time to work
on it in the next weeks.
Yes, we need a way to handle random access in the file somehow.
Regarding changes in the file itself while it's open: I guess the best
way to include pcapng into WS is to treat the capture file read only (as
today). Additional stuff has to be kept in memory (user comments, name
resolvings, ...) until the capture file is saved to disk. After the file
is saved, it has to be read completely again, so file offsets of packet
data is "updated" in memory.
Regards, ULFL
