Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: Re: [Ethereal-dev] hanging graphs

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Jason House <jhouse@xxxxxxxxx>
Date: Thu, 19 Dec 2002 14:11:51 -0500
Martin Regner wrote:
> Yes, I think that a [time_delta < 0] indication seems to be a good idea.
> 
> Maybe it would be also good to add some warning in TCP stream analysis and similar analysis functions that are
> depending on the time stamp information.

I don't know if I like that idea.  One reason is that alerts could get
irritating if not done properly... I really hate pop-up windows. Another
reason is that most likely, new/existing tools will not be
tested/evaluated for how they perform with really odd data.
  I'm much more in favor of finding some way to alert the user when they
initially open the data and then allow them to use any and all tools
that they please.  If there is an active alert, I'd much prefer to see a
generic one (that maybe lists TCP graphs as an example)

> There were some discussion about having some default color filters that flags for incorrect checksum and similar.
> 
> I tried to prepare a color filter for negative frame.time_delta.
> 
> I thought that it would be possible to use a filter like
> frame.time_delta < 0
> or
> !(frame.time_delta >= 0)
> but I don't get it to work (Ethereal 0.9.8, Windows 2000/98).
> 
> I can filter out packets where frame.time_delta >= 0, but not the opposite.

I don't see why this wouldn't work.
fram.time_delta is of type FT_RELATIVE_TIME

Both FT_RELATIVE_TIME and FT_ABSOLUTE_TIME use fvalue_t->value.time for
storage, and use the same comparison functions.  The comparison
functions seem to work fine.

Now, time is typed as nstime_t, which has a secs field of type time_t,
and an nsecs field of type int.

On windows time_t is a long... and so should be signed... I don't see
any way for there to be a problem.  

I also tried to look at the code for computing delsecs and delusecs...
and it seems to work fine.