Ethereal-dev: Re: [Ethereal-dev] Stop capture trigger. RFC
From: "Dinesh G Dutt"
Sent: Thursday, June 26, 2003 1:53 AM
Subject: Re: [Ethereal-dev] Stop capture trigger. RFC
> Hi Ronnie,
>
> One problem that I have with your scheme is making it work for start
capture
> trigger seems ugly (maybe my brain isn't fully upto speed yet). I'd very
much
> like a scheme that supports both start and stop capture triggers.
>
> I'm willing to put in some time to help with the implementation.
It should be possible to do both using bpf_filter() as Guy suggested.
I think it is reasonably at least for a first implementation to just support
the capture filter syntax and then later if there really is any need for it
to
add some sort of display-filter languange subset to capture filter
translation.
However, many many useful constructs in teh displayfilter language will
never be possible to
implement using capture filters so it might be confusing to the users.
Using capture filter syntax then it is clear to the user: this is what you
get this is what you can do.
Maybe start with implementing a stop trigger and make it work in
conjunction with teh stop-capture-after...
so that the stop-capture-after... starts counting after the trigger has
been activated.
As a second phase, when the stop trigger is working, add a start-trigger
using a similar approach.
The start trigger might be useful if
before the start trigger has been activated, packets are just stored in a
linked ring-buffer of n packets
but the packets are not passed to ethereal decode proper yet. The size of
this rng buffer can be selectable from
the gui and means how many packets prior to activating the start trigger
should be captured.
when the trigger is activated all the packets in the ringbuffer are fed to
ethereal and capturing continues normally.
I dont know how this will affect performance calling bpf_filter() in
userspace for every packet in addition to this or something similar being
called on the packets inside the kernel/driver as well.
But even if it affects capturing performance it would be better than no
functionality at all.
The optimal might be if this would be implemented inside the pcap part of
the os but until such a time in some unknown future we can do it ourself
inside ethereal.
Can you hack up a prototype using bpf_filter() and stop-capture-triggers?
so we can test how it works and affects performance.
I am not familiar with this part of the code myself and would not know where
to even look.
This would be a very very useful addition to ethereal and tethereal.
