Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 7505] cannot convert a MS NetMon 3.4 .CAP file to .PCAPNG

Date: Thu, 19 Jul 2012 17:13:12 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7505

Guy Harris <guy@xxxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|x86                         |All
            Version|unspecified                 |1.8.0
         OS/Version|Windows Server 2008         |All

--- Comment #2 from Guy Harris <guy@xxxxxxxxxxxx> 2012-07-19 17:13:11 PDT ---
The code to write out pcap-NG files assumes that the data being written either

    1) has a set of interface descriptions

or

    2) has a single fixed link-layer type rather than, say, having per-packet
encapsulation.

Neither of those are true for newer NetMon captures.

The model we should probably have is that there are three types of capture file
formats:

    1) capture file formats with interface descriptions (assumed to have
per-packet encapsulation);

    2) capture file formats with per-packet encapsulations but without
interface descriptions;

    3) capture file formats with only one encapsulation type per file.

The code path for writing capture files should, when writing to a file format
that requires interface descriptions, be able to handle both packets with
interface indices and packets without interface indices being written to the
same file (see, for example, bug 7381).

If a packet is being written that has an interface index, the code path should
check whether a corresponding interface description has been supplied, and fail
if it hasn't; that was one in rev 43657.

If a packet is being written that has no interface index, the code path should
check to see whether a "synthesized interface" with that packet's link-layer
type exists and, if not, create one, assign an interface index to it, and write
out an interface description for it before writing out the packet (which is
done with the interface index for the appropriate synthesized interface).

This means that we *have* to support pcap-ng files with IDBs following packets;
there is nothing in the pcap-NG spec saying that all IDBs must precede all
packets, just that the IDB for an interface must precede all packets for that
interface and, in fact, there are other reasons why we should not require all
IDBs to appear at the beginning of the packet (consider, for example, capturing
on the Linux "any" interface and, instead of writing out a boring IDB for the
fake "any" device, writing out separate IDBs for each interface on which
packets are received, including interfaces that appear after the capture starts
- or capturing on "all interfaces" on a platform on which you can wait for
packets to arrive *or* interfaces to arrive and, when a new interface shows up,
start capturing on it).

When writing to a file format that supports only one encapsulation type, such
as pcap, *IF* we're reading from a file or files that might have more than one
link-layer type, then:

    in a multi-pass operation such as "Save As" or "Export Specified Packets"
from Wireshark, where we can determine what encapsulation types we have, we
should not allow writing to that file format if we have more than one
encapsulation type;

    in a single-pass operation such as editcap or one-pass TShark or mergecap,
we should use the encapsulation type of the first packet we're going to write
(yes, this means that, with mergecap, we can't create the output file until
we've read at least one packet from at least one of the input files, for
example) and fail somewhere in the writing code path if we encounter a packet
with a different encapsulation type.

I'll look at fixing all of this.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.