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 10190] The .cap files generated from Message Analyzer use

Date: Sat, 05 Jul 2014 11:09:23 +0000

changed bug 10190

What Removed Added
OS Windows 7 All

Comment # 9 on bug 10190 from
(In reply to comment #0)
> From: [email protected]
> If you install Microsoft Network Monitor, you can find .cap file format at
> Microsoft Network Monitor | network Monitor Overview | Capture File Format
> section in Help | Contents and SDK menu.
> 
> The TimeStamp field of the Frame Layout is introduced with Network Monitor
> 2.3 to resolve time zone issue, accuracy and file merging issue and should
> be used if ExtendedInfoOffset in the capture file header is not 0.
> 
> Technically, it is not a fault of Wireshark to use TimeOffsetLocal instead
> of TimeStamp as we don’t mark that field as deprecated. But it would be
> better to use TimeStamp field as TimeOffsetLocal is not UTC time and is not
> accurate as TimeStamp.

Technically:

    if the NetMon 2.3 format spec is to be read as saying the trailer is
present, *regardless* of the version number, if the ExtendedInfoOffset is
non-zero ("FILETIME structure UTC timestamp. In increments of 0.1μs (100 ns).
This is used if and only if ExtendedInfoOffset in the capture file header is
not 0."), it's a fault of Network Monitor 3.4 that it doesn't read the file
data trailer if the version number is 2.0 and the ExtendedInfoOffset is
non-zero;

    if the spec is to be read as implying that ExtendedInfoOffset should be
non-zero only in 2.3 or later format files, it's a fault of whatever program
wrote that file (Message Analyzer?) that it wrote out a version number of 2.0
and a non-zero ExtendedInfoOffset value.

> If you have any more question, please let me know via email.
> 
> Kim

Ken, could you send Kim a message about this?

We need to know from somebody at Microsoft:

    What is the correct way to handle NetMon files - the way NetMon 3.4 reads
them, or the way Message Analyzer writes them?

    And, if the format version is 2.0 but ExtendedInfoOffset is non-zero,
meaning that the packets *do* have record trailers, should the record trailer's
MediaType and ProcessInfoIndex fields be used?


You are receiving this mail because:
  • You are watching all bug changes.