On Mon, Aug 31, 2015 at 2:43 PM, Guy Harris <g...@alum.mit.edu> wrote: > > For example, in bug 4221 > > https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4221 > > Paul Long of Microsoft says that we discard interface information in Network > Monitor files *and* that, ideally, the NetMon record containing interface > information would show up in the "packet" list, so that packet numbers in > NetMon files as displayed by NetMon would be the same as packet numbers in > those files when displayed by Wireshark. That would mean that libwiretap > would have to present a single "IDB" record with information for *multiple* > interfaces.
I'm not sure I fully grok that. I think what you're saying is the Network Monitor file has IDB information, but that the NetMon tool displays that information as a single frame in its display (because internally in the file format it happens to be an array of interface info inside a single file "NetworkInfo record"). So he'd like wireshark to do the same in order to keep the frame numbers consistent. That seems to me like mixing the presentation layer with the data layer - I mean it's Wireshark's job to decide what to show, not a file format's job, no? (or maybe it's asking for some "presentation control bits" in the wiretap API?) But here goes my whacky way of thinking about it anyway... What would a Network Monitor file containing interface info for 3 interfaces look like if it were "converted" to a pcapng file, by some tool... *without* losing any semantic info? Like for example a tool built by Microsoft. Or put it another way, what if the NetMon program could save in pcapng format directly? I think the answer is: it would be a pcapng file with 3 IDBs, each IDB with a bunch of Custom Options for things not in the current pcapng spec (Gateway addr, DHCP server, etc.); and the pcapng file would also contain a Custom Block which represents the single "NetworkInfo record", which internally has indices to the IDBs. Those Custom Options and Custom Block would use Microsoft's PEN number, and they'd decide what their internal format for them is. In our case, we can't use Micorsoft's PEN obviously, so we'd use Wireshark's PEN and define the internal structure for that ourselves. And then we'd modify wiretap's netmon file reader - for example, changing its netmon_read() function to return that Custom Block when it finds this "NetworkInfo record" in the file. It would also adjust the file cursor so that on the next call to netmon_read() it can return the first IDB, and the third call to netmon_read() it can return the second IDB, etc. (this would undoubtedly require some internal state to be kept in the netmon reader, but we do that already for other file readers) -hadriel ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
