----- Original Message ----- From: "Ulf Lamping" <[EMAIL PROTECTED]> To: "Developer support list for Wireshark" <wireshark-dev@wireshark.org> 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@wireshark.org > http://www.wireshark.org/mailman/listinfo/wireshark-dev _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
