Re: Export PDU:s

[Anders Broman <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?
> 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

___________________________________________________________________________
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