Wireshark-dev: Re: [Wireshark-dev] Wiretap changes for pcapng
From: Hadriel Kaplan <[email protected]>
Date: Mon, 31 Aug 2015 17:56:34 -0400
On Mon, Aug 31, 2015 at 2:43 PM, Guy Harris <[email protected]> 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

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)