I have thought a bit about that, too. I am interested in both start and
stop triggers. Here is what I have been thinking. Maybe it is flawed:
Given
F(S) - Start trigger filter string
F(P) - Stop trigger filter string
F(U) - User specified filter string
F'(P) - Filter string catching all packets except those matched by the
stop trigger F(P)
Tell pcap to capture grabbing one packet at a time using filter F(S).
When a packet is found, switch pcap filter to F'(P) or F(U) if no F'(P).
if using stop filter, when a packet is discarded by pcap, it must have
matched F(P), so stop capturing.
This means that using a Stop trigger prohibits use of user specified pcap
filters F(U) which may be an unreasonable restriction.
In my Ideal World (tm) libpcap would have start and stop triggers built in.
--john
Ronnie Sahlberg wrote:
Hi list.
I have been thinking recently about functionality to add capability to
ethereal/tethereal to have a trigger that would stop a live capture.
These are my ideas, please comment.
First of all, implementing a stop capture trigger as a filter string in the
display filter language
is probably not practical since this would require [t]ethereal to do a full
decode of the packet
in order to evaluate the trigger filter and thus would be slow.
It would probably not be practical or realistic for use with high speed
captures.
What about this instead:
If a "stop capture trigger" is enabled in the capture dialog
[t]ethereal would create TWO capture sessions instead of as currently one.
The first capture handle would be for the real capture and would apply the
normal
capture filter and work as capturing does today.
The second capture handle would capture from the same network interface but
specify a different
capture filter string. The stop capture trigger filter string.
--
John McDermott
Writer, Educator, Consultant
jjm@xxxxxxxxxx http://www.jkintl.com
V +1 505/377-6293 F +1 505/377-6313