----- Original Message -----
From: "Ulf Lamping" <ulf.lamping@xxxxxx>
To: "Developer support list for Wireshark" <wireshark-dev@xxxxxxxxxxxxx>
Sent: Thursday, September 27, 2007 2:01 PM
Subject: Re: [Wireshark-dev] [ntar-workers] Extending Wireshark libpcap
format support, or start using pcapng now ?!?
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.
agreed
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.
uhm, pcap-ng serves a different purpose from PPI. Please remember that PPI
is what is received (in case of Airpcap) directly by the device driver (or
capture engine). I don't know if there can be problems in that. I simply
never tought about that...
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?
Uhm, i think i'm missing the point here. the block contains a list of dns
records in the form IP->name\0name\0, and then the options at the end of the
block itself.
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?
Just send them to me and i can include them. Otherwise, the XML source of
the document is available at
http://www.winpcap.org/ntar/draft/PCAP-DumpFileFormat.xml
just edit it and send it to me.
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.
Yeah. Reading a pcap-ng file can give some headaches...
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).
Sure, I will do that in a couple days.
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.
I will see if i can work on in within a week or so. no promises :-)
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.
I would use the same approach, at least for v1. If it proves to be too
slow/inefficient, there's always time to improve it.
Have a nice day
GV
Regards, ULFL
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
