[bugzilla-daemon@xxxxxxxxxxxxx]

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2251





--- Comment #3 from Guy Harris <guy@xxxxxxxxxxxx>  2008-02-09 02:55:26 GMT ---
Frames 3971 and 3972 have, at least according to some debugging code I put into
the code to read files in the old DOS Sniffer format (which is the format of
the file in question), in their REC_FRAME2 headers:

    time_high = 0x000a, time_med = 0x0eb9, time_low 0x9c8c
    time_high = 0x000a, time_med = 0x0ebb, time_low 0x53b2

Frames 3973 and 3974 have:

    time_high = 0x0100, time_med = 0x00b2, time_low = 0xd4aa
    time_high = 0x0100, time_med = 0x00b2, time_low = 0xd678

Those are 48-bit time stamps, in 2-microsecond units, so:

    The jump between frames 3971 and 3972 is 43196718220 2-usec units to
43196830642 2-usec units, or 112422 2-usec units, or 224844 usec, or .224844
seconds.

    The jump between frames 3972 and 3973 is 43196830642 2-usec units to
1099523347626 2-usec units, or 1056326516984 2-usec units, or 2112653033968
usec, or 2112653.033968 seconds, or over 24 days.

So either:

    1) Wireshark is somehow reading the time_high value wrong

or

    2) if the IPCS analyzer reads the .cap file, *it's* reading or interpreting
the time stamp wrong (and Wireshark is right)

or

    3) if the IPCS analyzer doesn't read the .cap file, and some other part of
z/OS writes out the .cap file from the same data that the IPCS analyzer reads,
that part of z/OS is buggy (and both IPCS and Wireshark are correct).

If you have another program that can read Sniffer capture files (such as the
Sniffer software from Network General, or version 2.x of Microsoft's Network
Monitor), could you try reading the .cap file with one of those programs and
see whether it gets the time stamps right?  If not, this is a bug in whatever
code wrote out the .cap file, not in Wireshark.

If you have WildPackets ProConvert:

    http://www.wildpackets.com/products/free_utilities/proconvert/overview

it can read a number of capture file types, including DOS Sniffer files, and
write out the file in a number of other formats, including Wireshark's native
format, which WildPackets calls "tcpdump/libpcap".  Try converting the file to
tcpdump/libpcap format and reading it in Wireshark; if that gets the time
stamps right, Wireshark's code for reading DOS Sniffer files is buggy, and if
that gets the time stamps wrong, either

    1) the code that wrote out the .cap files is buggy

or

    2) both Wireshark's code for reading DOS Sniffer files *and* ProConvert's
code for reading DOS Sniffer files is buggy

(and I'd bet on the code that wrote the .cap file being buggy in that case).

(NOTE: most of us aren't z/OS experts, so most of us don't know what the z/OS
tools do - when you say "when I view these records via the IPCS analyzer under
z/OS", does that mean that the IPCS analyzer reads the .cap file, or is it
reading some other file format and showing the records?  And what software
writes out the .cap file?  Does IPCS read that other file format and write out
a Sniffer .cap file, rather than showing the records?

At least as I interpret the slide on page 12 of

   
http://publib.boulder.ibm.com/infocenter/ieduasst/stgv1r0/topic/com.ibm.iea.commserv_v1/commserv/1.8z/hardware/VLANosaenta.pdf?dmuid=20061231220911880776

what IPCS reads is a "Ctrace data set", and it can "format the trace data to
produce IPCS reports" - is this what you're talking about when you say "when I
view these records via the IPCS analyzer under z/OS"? - and it can also "format
the trace data into a Sniffer data set" - is that how you produced the .cap
file?

If the answer to both of the latter questions is "yes", I suspect this is a bug
in IPCS's code to write out Sniffer files, not in Wireshark.)


-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.