On Mon, Mar 12, 2007 at 09:59:58PM +0100, Julian Fielding wrote:
> Jeff Morriss wrote:
> >Normally I'd see the use in not changing semantics for a field, but I
> >don't think the current semantics make any sense at all so I can't
> >imagine it is being used [therefor it's OK to change it].
>
> It makes no sense in a display filter, but it is useful in a colour filter
> or in Edit > Find Packet > By Display filter.
>
> I often use a colour filter to highlight frames with frame.time_delta>x,
> where x is something small. Of course it's only meaningful if the
> displayed frames are all related in some logical way, but that often
> applies because I've used capture or display filters to get such a
> display.
>
> I don't mind a name change, but don't want to lose the present
> functionality.
OK, I think an extra field needs to be added to the frame-dissector so
that both delta's are available, also for filtering, searching and
coloring. It would also be nice to be able to have both fields available
for the columns in the packet-list. The two options regarding field naming
so far are:
- use frame.time_delta_captured and frame.time_delta_displayed and drop
support of frame.time_delta to emphasize this change
- rename the current frame.time_delta field to frame.time_delta_displayed
since this is what it currently means. Then use the field frame.time_delta
for the delta in the capture as one would expect intuitively.
This is a choice the (core-)developers have to make, but since it is
trivial in the end, it can be decided just before the patch is ready.
I did however start to look into the code to see how I could implement
the extra field. I realise that I need to start to understand how
wireshark actually handles frames. Some fields are filled by the
dissector and some fields are filled while looping through the
packets it seems. It will take me some time to understand how this
works and where the field must be generated. Any help on this is
more than welcome.
Cheers,
Sake
