Wireshark mailing list archives
Re: Dumpcap 2.x trouble
From: Jasper Bongertz <jasper () packet-foo com>
Date: Tue, 19 Apr 2016 11:39:11 +0200
Hello Guy, Tuesday, April 19, 2016, 1:04:15 AM, you wrote:
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.
Honestly, I like 3) - I think it's always better to have separate information entries than having to guess/parse parts from a combined entry.
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.
Merging is always a nightmare on a scale from 1-10 :-)
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.
Valid point.
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.
I like that, too (I know that it also means a PCAPng file can carry a ton of meta data depending on what happened with it), and I think it doesn't happen too often that a file is read and written by multiple programs.
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?
I'd say, someone's going to have a major headache in this case :-)
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?
Maybe something in between - most PCAPng files are not edited/split/merged that much, so I don't think going for record level histories is helping that much. Having good information (and risking to lose some details on crazy split/merge operations) in the IDB is a good way to cover most of the cases.
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.
Okay, I'll file a bug report for it to make sure it's covered.
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.
Right, I didn't realize little-endian applies to the 32-bit parts. My bad.
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.
Yes, it would be. As you already found out libpcap is writing the values in the wrong order, so I think we don't need to touch the PCAPng major version number. Cheers, Jasper
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
___________________________________________________________________________ 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
Current thread:
- Dumpcap 2.x trouble Jasper Bongertz (Apr 18)
- Re: Dumpcap 2.x trouble Guy Harris (Apr 18)
- Re: Dumpcap 2.x trouble Guy Harris (Apr 18)
- Re: Dumpcap 2.x trouble Jasper Bongertz (Apr 19)
- Re: Dumpcap 2.x trouble Jasper Bongertz (Apr 19)
- Re: Dumpcap 2.x trouble Guy Harris (Apr 18)
- Re: Dumpcap 2.x trouble Guy Harris (Apr 18)