Re: Dumpcap 2.x trouble

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

On Apr 18, 2016, at 10:37 AM, Jasper Bongertz <jasper () packet-foo com> wrote:

>  I noticed that captures taken with Wireshark 2.x (meaning, with
>  dumpcap coming with those versions) showing unexpected results (see
>  Glossary below for the abbreviations).
>
>  With 1.12, the dumpcap version is written to the application option
>  field in the SHB, and the OS build in the OS option field. Both
>  values are omitted in 2.0.2 and later. As far as I can tell the OS
>  is now written as option code 12 to the IDB instead,

I.e., it's written as the OS option in the IDB rather than in the SHB.

The underlying issue here is that a capture file can pass through a sequence of multiple programs on multiple OSes.  I 
think a good case can be made for an IDB to record the OS - and probably the application - used to capture the traffic, 
with no additions made for further processing, so you know what program, on what OS, captured it.

And, for libpcap/WinPcap-based programs, it might also be useful to record the version of libpcap/WinPcap as well.

For the IDB, I could see three ways of handling this:

        1) rename if_os to if_software and have it be a human-readable string with *all* that information;

        2) add an if_userappl option and have it hold the application *and*, for libpcap/WinPcap-based programs, the 
libpcap/WinPcap version;

        3) add an if_userappl option for the application and an if_userapplib (or whatever) option for the 
libpcap/WinPcap version.

Now, the pcapng spec says of if_os "This can be different from the same information that can be contained by the 
Section Header Block (Section 4.1) because the capture can have been done on a remote machine.", but it could also be 
different because, for example, somebody might have run mergecap and merged captures done on two different OSes.

The remote capture issue is a *separate* issue, and you might well want to know that a given remote capture was done 
with the remote interface on a Fedora 25 server running rpcapd 2.17 using libpcap 1.9.1 and the machine doing the 
capture being a Windows 10 machine with dumpcap 2.4.0 and WinPcap 5.0 based on libpcap 1.9.0 - the version of libpcap, 
and the application, on *both* machines potentially being relevant if, for example, you're trying to figure out a 
problem with the capture file.  Therefore, we might want to have separate local and remote versions of the if_ options 
in question.

In *addition*, it might be useful to keep a record of all the programs through whose hands the capture has passed; that 
would mean having *multiple* OS and application options, in order.

But, then again, what happens if you do several captures with different applications, combine them with mergecap, split 
the resulting capture into multiple captures, process the different files with different applications, and then, just 
for the lulz, merge them back again?

Is this a sign that we need some scheme to record that level of history - which might involve some packets from 
interface eth0 being processed by applications A, B, and C and other packets from the same eth0 being processed by 
applications A, C, and D?

Or is this a sign that we shouldn't bother recording anything other than the software used in the original capture?

>  but the capture application is not found anywhere.

That's because there isn't an if_userappl option yet.

>  And Wireshark does not show the IDB OS option anymore anywhere (yet?).

It should.

>  I think losing the capture application is not a good idea, especially when we change behaviour
>  of dumpcap all of a sudden:

Yes.

>  In the latest 2.1.x dev builds the start/end timestamp options
>  (called isb_starttime and isb_endtime) for the ISB are written in
>  the wrong order, as lo-hi values instead of hi-lo (like it is
>  specified in the PCAPng specs) - in 2.0.2 they are written
>  correctly (from my point of view, at least).
>
>  I have to admit that the latest PCAPng specs are a confusing in this
>  point though - they state "format as for the EHB" (which is Hi-Lo,
>  clearly), but the examples for the options mentions "Little Endian"
>  and is given in Lo-Hi order (which contradicts the EHB order).

Confusing, perhaps.

*Ambiguous*, no.  Clearly, if the file is being written on a little-endian machine, the time stamp is in 
*middle-endian* format, with the upper 32 bits written out in little-endian fashion followed by the lower 32 bits 
written out in little-endian fashion.  If the file is being written on a big-endian machine, the time stamp *happens* 
to be written in big-endian format, but one shouldn't assume from that quirk that the value is a 64-bit 
writing-host-byte-order value.

>  Frankly I don't see the point why we should do Lo-Hi now all of a
>  sudden, as it makes it more complex to read PCAPng files from now
>  on.

Correct.

This is a dumpcap bug, and needs to be fixed - "fixed" as in "fixed for 2.0.3".  Please file the bug, so it's recorded 
in the bug database, and we can mark it as fixed when the change is made.

>  But maybe there's a good reason for that kind of change to the
>  timestamp order I can't see right now?

If there's a good reason, it's also a reason to change the *major version number* of pcapng, with 1.x files having the 
time stamp written as two 32-bit values and 2.x files having it written as a 64-bit value.
___________________________________________________________________________
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