[Evan Huus <eapache@xxxxxxxxx>]

On Thu, May 16, 2013 at 2:45 PM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:

On 05/12/13 09:11, Evan Huus wrote:

On Sun, May 12, 2013 at 8:58 AM, Anders Broman <a.broman@xxxxxxxxxxxx> wrote:

Well as long as the tap, "taps" after reassembly is done I suppose it does
not matter but if y is on top of x why tap y
and not only X as that would include Y any way?

Tangent on the tapping behaviour: this is bringing to mind bug 8321
and the regression it cause which was bug 8610. The tap was originally
after dissection which was causing statistics to be wrong if a
malformed packet threw an exception. We moved the tap before
dissection, at which point the taps were missing some information that
they needed which hadn't been dissected yet. We eventually just
wrapped the entire thing in a Try/Catch block and called the tap at
the end again, but that was a fairly ugly solution.

I think what we need is to have taps simply get queued when called by
a dissector, and then have them actually called at the bottom of
packet-frame (or somewhere like that) so that they're always run
regardless of exceptions and with the entirety of what we were able to
dissect. I'm not sure how much work this would be, but I'm hoping it
would actually be a fairly minimal change.

[Without having read either bug recently and without having ever really looked at tapping--so beware of glaring ignorance on my part...]

Would it make any sense to do call the tap in a frame-end routine (register_frame_end_routine())?  That's another way to handle exceptions without having to catch them.

So it looks like we already basically do what I was suggesting. The bug was a special case of inter-tap dependencies. Using a frame-end routine might make for a simpler fix than all the manual try-catch blocks though.

Evan