2013/5/12 Anders Broman <a.bro...@bredband.net> > Pascal Quantin skrev 2013-05-10 15:20: >> 2013/5/5 Anders Broman <a.bro...@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-requ...@wireshark.org?subject=unsubscribe
