Re: Export PDU:s

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

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

>  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?

The purpose of your development is to export higher layer PDUs without the
transport stream / lower layer and I guess depending on the user, you will
have different needs and understanding of what this "higher layer" is. So a
user might be interested by the export of X while another user might want
only Y. But that's really a minor issue. The export of malformed packets
seems a must-have for me otherwise you would loose too much information.

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