Re: Tapping Behaviour [Was: Export PDU:s]

[Evan Huus <eapache () gmail com>]

On Thu, May 16, 2013 at 2:45 PM, Jeff Morriss <jeff.morriss.ws () gmail com>wrote:

> On 05/12/13 09:11, Evan Huus wrote:
>
> > On Sun, May 12, 2013 at 8:58 AM, Anders Broman <a.broman () bredband net>
> > 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

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe