The tapping subsystem highly interests me, but I've only just started
looking at it :( I'm interested in various extensions of the tapping
system. Below are some of my more basic thoughts on tap
functionality...
1)
I was looking at rpcstat_init and its hard coded link into tethereal.
My initial reaction is that there should be a way of handing off a tap
string to the tap subsystem for validation. I would also think that the
tap initialization core would merely hand off the string (without "rpc,"
etc...) to a lower level initialization routine... like changing
void rpcstat_init(guint32 program, guint32 version, char *filter) /*
current preparsed info */
to something like one of the following
int rpcstat_init(const char *args) /* let rpcstat parse everything */
int rpcstat_init(guint32 argc, char **argv) /* standard program input
argument format? */
int rpcstat_init(guint32 argc, char **argv, char *filter) /* parse out
filter expressions */
int rpcstat_init(guint32 argc, char **argv, char *filter, FILE* output)
/* why limit to stdout? Probably too text based */
... various forms depending on how much the tap subsystem handles/parses
itself.
I would think that such an approach would require yet another
register.c/proto_register_XXX-like approach. The method has appeal to
me because it allows easier growth of the tap system (even plug-in
capability)
2)
I can envision the need for a more selective tap calling trigger than a
packet of the right type being encountered. It would be nice to have a
tap listener called the first time that a packet is processed (or every
time except the first time). I imagine that this might be easy to do
based on pinfo, but somehow I think that such functionality should not
be inside the tap listener, but outside of it. By doing so, it helps
guarantee that all taps have a more uniform set of implemented
functionality and user interface. Initially I was thinking of
potentially having multiple trigger points inside of ethereal to allow
the registration/removal of various listeners, but the "update list of
packets in real time" feature prevents this method and potentially
requires something a bit more advanced. I'm sure that there could be
other triggers that I'm not thinking of at the moment...
Any and all responses, commentary, rebuttals, etc... are welcome :)
