https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5254
Gary Chaulklin <GaryChaulklin@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #4 from Gary Chaulklin <GaryChaulklin@xxxxxxxxx> 2010-09-27 03:45:52 PDT ---
(In reply to comment #3)
> So far we have no evidence to indicate that the problem is the result of the
> capture being done with snoop.
> I'm assuming that "SNOOP" refers to the Solaris "snoop" utility, whose files -
> as indicated by the fact that editcap can convert them - can be read by
> Wireshark; editcap, Wireshark, and TShark use the same code to read particular
> file formats.
> Given, then, that Wireshark could, in fact, read the file without conversion
> (if not, that's a bug), I repeat Jeff's question - what happens if you try to
> read the snoop file directly?
> As we don't know why this is occurring, we might need to see the two files and,
> if it's taking more CPU time to read the slower file, read them in a "profiled"
> version of Wireshark to see where the extra CPU time is being spent.
Correct about SNOOP.
Wireshark can read without conversion, but the file has too many packets to be
processed by the XP PC. This problem was first presented to me by a user that
was reading the SNOOP capture in GZIP format not realizing how big the acutal
capture file was. Wireshark is able to begin processsing the file, but runs
out of memory. So this is just a case of a file needing to be split up first.
The small converted SNOOP files taking 5 minutes to process rather than 5
seconds for other simliar sized files is curious, but I can't share the capture
file.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
