> It would be useful to be able to start the capture based on the presence of
> a certain packet or perhaps even a sequence of packets.
Or, rather, given what current OS packet capture mechanisms support,
"start saving captured packets to the capture file based on the presence
of a certain packet or perhaps even a sequence of packets" - the checks
would have to be done in userland by the application, and pre-trigger
packets would have to be copied up to userland even though they'd be
discarded.
I don't know whether there'd be an advantage to having, say, BPF
programs as "trigger filters" in BPF or Linux PF_PACKET sockets or...,
where input packets are discarded until a packet passes a BPF filter
program, at which point all subsequent packets are passed up (if they
pass the capture filter).
The "sequence of packets" part would require that the program provide a
list of filters and the filtering mechanism arrange that starting at
filter 1, if the packet passes filter N filter N+1 becomes the trigger
filter, and if filter N is the last filter you start passing packets up.
This means the capture wouldn't start until the *last* packet in that
sequence; to have it start with the first one, intervening packets would
have to be buffered up and passed up to userland when the last filter
succeeds (which could be tricky if there's a long gap between the packet
that passes filter N and the one that passes filter N+1 - if "sequence"
implies that filter N applies to packet N of the sequence, the maximum
length of the sequence would probably keep that from being a problem
unless you allow really long sequences).
I'm CCing tcpdump-workers as that would be a capture-mechanism issue
(and might be of interest to programs other than just Ethereal).
