On Fri, Mar 23, 2007 at 07:34:23AM +0100, Sake Blok wrote:
> It turns out that the recent hunt for warnings resulted also in a few
> casts in column-utils.c. I incorporated these casts in my patch so it
> should now be able to load the patch against the latest SVN (21147).
>
> Could you give it
On Thu, Mar 22, 2007 at 06:56:19PM -0700, Stephen Fisher wrote:
> On Tue, Mar 20, 2007 at 09:45:16PM +0100, Sake Blok wrote:
>
> > I was able to build a patch for this bug over the last couple of days.
> > I have chosen to use the second option. Also because frame.time_delta
> > in tshark alread
On Tue, Mar 20, 2007 at 09:45:16PM +0100, Sake Blok wrote:
> I was able to build a patch for this bug over the last couple of days.
> I have chosen to use the second option. Also because frame.time_delta
> in tshark already provided the delta time between *captured* packets.
>
> Could someone r
On Wed, Mar 14, 2007 at 10:24:10AM +0100, Sake Blok wrote:
>
> 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
On Tue, Mar 20, 2007 at 05:47:59PM +0800, Jeff Morriss wrote:
> Sake Blok wrote:
> >
> > I assigned the bug to myself, I hope that is the proper way to use
> > bugzilla (as this is my first time to write code to solve an
> > already listed bug).
>
> I don't know if there is a "proper way" but I
Sake Blok wrote:
> On Mon, Mar 19, 2007 at 10:45:42AM +0800, Jeff Morriss wrote:
>>> 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
>
On Mon, Mar 19, 2007 at 10:45:42AM +0800, Jeff Morriss wrote:
>
> > 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 s
Sake Blok wrote:
> 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
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].
>
> I
Jeff Morriss wrote:
>Guy Harris wrote:
>> Jeff Morriss wrote:
>>
>>> What about renaming the current field "frame.time_delta_displayed" and
>>> name the new one "frame.time_delta"? That changes the current field
but
>>> it sounds a whole lot more intuitive to me.
>>
>> Or "delta_displayed" a
Guy Harris wrote:
> Jeff Morriss wrote:
>
>> What about renaming the current field "frame.time_delta_displayed" and
>> name the new one "frame.time_delta"? That changes the current field but
>> it sounds a whole lot more intuitive to me.
>
> Or "delta_displayed" and "delta_captured", which m
Jeff Morriss wrote:
> What about renaming the current field "frame.time_delta_displayed" and
> name the new one "frame.time_delta"? That changes the current field but
> it sounds a whole lot more intuitive to me.
Or "delta_displayed" and "delta_captured", which means that any
"frame.time_delt
Sake Blok wrote:
> On Fri, Mar 09, 2007 at 09:59:33PM +0800, Jeff Morriss wrote:
>> Sake Blok wrote:
>>> 1) add another field to incorporate the "Time delta since previous
>>>frame in the tracefile". This is an option Jeff Morriss suggested
>>>already.
>>>
>>> 2) have an option in the "fr
On Fri, Mar 09, 2007 at 09:59:33PM +0800, Jeff Morriss wrote:
> Sake Blok wrote:
> >
> > 1) add another field to incorporate the "Time delta since previous
> >frame in the tracefile". This is an option Jeff Morriss suggested
> >already.
> >
> > 2) have an option in the "frame" protocol pr
Sake Blok wrote:
> Hi All,
>
> Last week I ran into bug 491 which describes the unexpected behaviour
> of frame.time_delta. This filter is calculated as "Time delta since
> previous displayed frame", where one could expect it to be calculated
> as "Time delta since previous frame in the trace-fi
Hi All,
Last week I ran into bug 491 which describes the unexpected behaviour
of frame.time_delta. This filter is calculated as "Time delta since
previous displayed frame", where one could expect it to be calculated
as "Time delta since previous frame in the trace-file".
When you do a filter like
16 matches
Mail list logo
