Re: Wiretap changes for pcapng

[Guy Harris <guy () alum mit edu>]

On Aug 31, 2015, at 6:05 AM, Hadriel Kaplan <the.real.hadriel () gmail com> wrote:

> Howdy,
> I'd like to modify tshark/wireshark/etc., to fully handle the pcapng
> file format.
>
> But to do that, wiretap needs to be changed in a non-trivial fashion.
>
> So instead of enumerating all the changes I propose to make to wiretap
> in an email, I've created a page on the wiki to describe my proposal:
>
> https://wiki.wireshark.org/WiretapPcapng
>
> That way folks can modify the wiki page to make corrections, add
> ideas, whatever.
> Please give it a look-over if you're interested.

I'm not so sure that "pcapng is essentially a super-set of all file formats we support".  It might be a superset of 
what subsets of the capabilities of those file formats we currently support in libwiretap, but that's a different 
matter.

The whole REC_TYPE_ thing I added was an attempt to handle all formats, including pcapng, in a fashion that *didn't* 
assume pcapng was a superset, and that would allow us to support some capabilities of other file formats that we don't 
currently support.  I've edited the page to use the REC_TYPE_ mechanism, with some new record types.

*If* we are willing to commit to making whatever changes are necessary to pcapng to make it a superset of all 
capabilities of all file formats we currently support *and* continue to make changes to it to handle future file 
formats and future capabilities added to those file formats (the only exception being that I don't think we need to 
commit to adding LINKTYPE_ values for every link-layer header type supported, although that might be a worthwhile 
project as well) as part of this process, then we can go with pcapng block types rather than REC_TYPE_ types.

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.

We might also have to add new options to the IDB to handle:

        interfaces having separate "friendly name" and "description" strings (which we should do *anyway*), the 
"friendly name" being a description of what the interface is from the user's point of view and the "description" being 
a description of the hardware (or, for non-hardware interfaces, software) corresponding to the interface;

        the MTU of the interface;

        a GUID for the interface (at least on Windows; it'd be nice if every OS generated an unchanging GUID for each 
interface, as I'm sure Jasper Bongertz would agree, but they don't);

        gateway, DHCP server, and DNS server IPv4 and IPv6 addresses;

in order to losslessly convert NetMon interface information into IDB information.



> -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-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe