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

[Pascal Quantin <pascal.quantin () gmail com>]

2013/5/12 Anders Broman <a.broman () bredband net>

> Evan Huus skrev 2013-05-12 15:11:
>
>  On Sun, May 12, 2013 at 8:58 AM, Anders Broman <a.broman () bredband net>
> > wrote:
> >
> > > Pascal Quantin skrev 2013-05-12 11:08:
> > >
> > > 2013/5/12 Anders Broman <a.broman () bredband net>
> > >
> > > > Pascal Quantin skrev 2013-05-10 15:20:
> > > >
> > > > 2013/5/5 Anders Broman <a.broman () bredband net>
> > > >
> > > > > Hi,
> > > > > I have added a basic implementation making it possible to export higher
> > > > > level PDU:s to file using a USER_DLT.
> > > > > The basic implementation makes it possible to export SIP traffic to a
> > > > > new
> > > > > file adding some meta data before the actual SIP message. The idea is
> > > > > that
> > > > > it should be possible to export the reassembled PDU:s(and mix several
> > > > > protocols) removing the under laying transport protocol but retaining
> > > > > some
> > > > > interesting data such as IP addresses and ports.
> > > > >
> > > > > The implementation is bare bones to get the demo to work. It would be
> > > > > nice to get some feedback on useful tags
> > > > > to add, helper functions to load tags and if some one is willing to
> > > > > work
> > > > > on the GUI part that'd be nice too.
> > > > >
> > > > > Would it be feasible/useful to apply for a link-layer type from
> > > > > tcpdump?
> > > > >
> > > > > Any comments welcome.
> > > > > Regards
> > > > > Anders
> > > >
> > > > Hi Anders,
> > > >
> > > > it looks interesting. I started playing a bit with it and fixed a few
> > > > bugs
> > > > in r49232. Moreover I added the tags content to a subtree. Feel free to
> > > > revert it if you do not like the output.
> > > > I would find it great to have a link layer type allocated. This way the
> > > > feature could work out of the box without any configuration.
> > > >
> > > > Yes
> > >   Then how should we proceed? Can Guy allocate us a DLT or must we send a
> > > request to someone?
> > >
> > > I was hoping Guy would comment :-)
> > >
> > >  Any idea on how to handle the export of several protocols ? Should we
> > > > allow the user to select them in the GUI or should we export all the
> > > > protocols registering the tap and let the user select afterwards which
> > > > ones
> > > > to keep with filters?
> > > >
> > > > My idea is to export all the protocols registering to the tap, if you
> > > > tap
> > > > with a filter only the filtered
> > > > protocols should be tapped I think.
> > > Fine with me.
> > >
> > > > By the way, I noticed that if a dissector and sub dissector both support
> > > > the export functionality, the sub dissector message is dumped twice
> > > > (once
> > > > per protocol). Not sure whether this should be considered as a feature
> > > > or a
> > > > bug.
> > > >
> > > > Do you mean protocol x+y in the first packet and y in the second? I
> > > > would
> > > > expect that.
> > > Yes that's what I meant. I think we should tap the packet at the
> > > beginning
> > > of the dissection and not at the end as it is currently done in the SIP
> > > dissector. I see two advantages:
> > > - packet x+y will be tapped before packet y and not the opposite (I find
> > > it
> > > awkward to have packet y displayed before packet x+y)
> > > - a malformed packet will still be tapped
> > >
> > > 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.
> >
> > Thoughts?
> If the tap is extracting information from the packet and a dissector bug
> occurs before that
> information is extracted that information will always be missing from the
> tap so having
> "correct" information from a tap is impossible if there are dissector bugs
> - right?


This is indeed a really good argument. If I remember correctly, the issue
with bugs 8321 / 8610 was that an exception triggered by a sub dissector
was preventing tapping the information for the parent dissector.
I guess there is no universal answer for this: depending on the information
we are tapping, you might need or not the call to the subdissector.

Regards,
Pascal.

___________________________________________________________________________
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