Re: Export PDU:s

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

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

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