----- Original Message ----- From: "Ulf Lamping" <[EMAIL PROTECTED]> To: "Developer support list for Wireshark" <[email protected]> Sent: Thursday, September 27, 2007 5:22 PM Subject: Re: [Wireshark-dev] [ntar-workers] Extending Wireshark libpcap format support, or start using pcapng now ?!?
> Gianluca Varenni schrieb: >>> 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. >> > The current approach is very IP centric. So if there's any name > resolution not so IP like (IPX, ...), the core block will contain > nothing but only (to be defined) option fields. Well, the records are TLV. In the future you can decide to define a new record type for other protocols like IPX. Older versions of a pcap-ng reader will skip the new block. What do you think? GV > > So in the end won't it be better to have only option fields here? >>> 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. >> > I'll continue to work on this probably from monday on ... >>> 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. >> > ACK > > Regards, ULFL > _______________________________________________ > Wireshark-dev mailing list > [email protected] > http://www.wireshark.org/mailman/listinfo/wireshark-dev _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
