Re: Export PDU:s

[Anders Broman <a.broman () bredband net>]

Pascal Quantin skrev 2013-05-12 17:50:
> 2013/5/12 Anders Broman <a.broman () bredband net 
> <mailto:a.broman () bredband net>>
>
>     Pascal Quantin skrev 2013-05-12 11:08:
> >     2013/5/12 Anders Broman <a.broman () bredband net
> >     <mailto:a.broman () bredband net>>
> >
> >         Pascal Quantin skrev 2013-05-10 15:20:
> > >         2013/5/5 Anders Broman <a.broman () bredband net
> > >         <mailto: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.
Sure just saying that you would probably export x OR y.

> The export of malformed packets seems a must-have for me otherwise you 
> would loose too much information.
>
> Regards,
> Pascal.
Assuming malformed packets are due to dissector bugs, fixing those would 
fix the problem :-))

Seriously - I suppose one have to chose the tapping point as wisely as 
possible but it might differ between
protocols.
> ___________________________________________________________________________
> 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

___________________________________________________________________________
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