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