Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] API hooks to specific points in flow

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Tue, 8 Jul 2014 14:33:45 -0700
On Jul 8, 2014, at 2:07 PM, Ben Burwell <bburwell@xxxxxxxxxx> wrote:

> I'm writing a plugin and I'm using register_init_routine() to have a function called (apparently when a capture is started).

No, it's not.

To quote the comment before the code that handles init routines:

	/* Allow protocols to register "init" routines, which are called before
	   we make a pass through a capture file and dissect all its packets
	   (e.g., when we read in a new capture file, or run a "filter packets"
	   or "colorize packets" pass over the current capture file). */

This is not tied to live captures - Wireshark can either read in a new capture file because it's opening an existing capture file or because it's started a live capture writing out a new capture file (all captures in Wireshark are written to files as the capture happens).  It's not even tied to opening a new file -  if Wireshark re-dissects all the packets in a capture, the init routine is called.

Do not depend on an init routine being called *only* at the beginning of a live capture.

> I'd also like a function to be called when a capture is finished. Are there any other API calls that can be used to hook in to other points?

No.  As indicated, we don't even have a "live capture starts" hook in the API exported to plugins (or even built-in dissectors or taps), much less a "live capture completes" hook.  We will *never* provide hooks specific to live captures for dissectors to use, as dissectors should not and must not dissect live captures and saved captures differently, and taps should not compute statistics differently for live captures and saved captures (for a live capture, the tap might update incrementally, whereas, for a saved capture, there's no point in updating the display until the entire capture is read, but that can be handled by calling a "redisplay" routine more often in the former case).

It might be useful to allow dissectors and taps to register routines called after the last packet has been read; this might, for example, allow dissectors to "finish" a partial reassembly and mark it as partially reassembled, so that some dissection can be done on the incompletely-reassembled packet.