Re: [Wireshark-dev] Export higer level PDUs, "Unbundled PDUs" decrypted PDUs etc
Yes, and this "function" would take arguments of original frame, offset where the interesting payload starts and length of this payload. Correct?? Regards, Vineeth On Thu, Apr 18, 2013 at 9:52 PM, Anders Broman wrote: > vineeth vijay skrev 2013-04-18 18:11: > > Hi Anders, > > Do you mean ability to export only the payload protocol from > tunneled/encapsulated captures like GTP-U etc? > If yes, +1 :) > > Yes that could be one use case. Probably every protocol using the > function would have to have code supporting it. > Regards > Anders > > Have been looking for such functionality for some time. > > Regards, > Vineeth > > > On Thu, Apr 18, 2013 at 2:23 PM, Anders Broman > wrote: > >> Hi, >> >> I think these topics in various forms has been cropping up lately, would >> it be possible/useful to have a generic feature to “Export” to a new file >> >> From a dissector using a tap writing a to a generic DLT with a pseudo >> header containing pseudo data such as extracts from lover layers like IP >> port or whatever can be useful >> >> and an Indication what the next level protocol is. As an example if I >> have decrypted and reassembled SIP traffic it could be useful to be able to >> export that to a new file >> >> Just containing the SIP traffic and the IP port combination used. The >> header would then Indicate the protocol as SIP and the meta data would be >> of type TLV and added to as >> >> Needs arises. Just a rough idea… >> >> >> >> Regards >> >> Anders >> >> >> ___ >> Sent via:Wireshark-dev mailing list >> Archives:http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org >> ?subject=unsubscribe >> > > > > ___ > Sent via:Wireshark-dev mailing list > > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > > > > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Export higer level PDUs, "Unbundled PDUs" decrypted PDUs etc
Hi Anders, Do you mean ability to export only the payload protocol from tunneled/encapsulated captures like GTP-U etc? If yes, +1 :) Have been looking for such functionality for some time. Regards, Vineeth On Thu, Apr 18, 2013 at 2:23 PM, Anders Broman wrote: > Hi, > > I think these topics in various forms has been cropping up lately, would > it be possible/useful to have a generic feature to “Export” to a new file* > *** > > From a dissector using a tap writing a to a generic DLT with a pseudo > header containing pseudo data such as extracts from lover layers like IP > port or whatever can be useful > > and an Indication what the next level protocol is. As an example if I have > decrypted and reassembled SIP traffic it could be useful to be able to > export that to a new file > > Just containing the SIP traffic and the IP port combination used. The > header would then Indicate the protocol as SIP and the meta data would be > of type TLV and added to as > > Needs arises. Just a rough idea… > > ** ** > > Regards > > Anders > > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] SCTP De-chunking support
Hi, I understood the idea. It would help in easier detection of the relevant upper layer info in large packets. What i would like to know is how it could be implemented. Setting some sort of flag for the filter specific chunk bytes, so that GUI/GTK colors it differently? Sorry, but i am not much familiar with GTK. Vineeth On Fri, Jan 11, 2013 at 4:08 AM, Michael Tuexen < michael.tue...@lurchi.franken.de> wrote: > On Jan 10, 2013, at 9:44 PM, vineeth vijay wrote: > > > Hi, > > > > Yes, highlighting would work too. Ultimately the application info > corresponding to display filter should be visible easily without the need > to scroll through the entire frame. Any suggestions on how to achieve this? > > I think GUI coloring implementation would paint the entire frame with > the same color,wouldn't it? > No, what I mean is the following: > Assume you have an SCTP packet with 5 DATA chunks each containing an M3UA > message. > The packet is shown because you filtered for a field in the third M3UA > message. > Then only the third M3UA part would be colored specifically. The rest of > the > packet is shown, but not in this color. Do you get the idea from my > description? > Would that address your issue? > > Best regards > Michael > > > > Vineeth > > > > On Fri, Jan 11, 2013 at 1:44 AM, Michael Tuexen < > michael.tue...@lurchi.franken.de> wrote: > > > > On Jan 10, 2013, at 8:49 PM, vineeth vijay wrote: > > > > > Hi, > > > > > > > Dissection is fine. What I was wondering is whether it is possible > to show these individual data chunks as separate frames themselves. > > > >But they are in the same frame. I really prefer not to show them in a > way they > > > have not been on the wire. > > > > > > Basically agreed on the above point. Changing the default behavior > may not be good due to all the copied lower layer bytes and resulting > increase in the size of capture in case there are 4-5 chunks per packet. > But still feel it would be a nice optional feature to have when doing > actual offline analysis. > > I do understand that it is sometimes hard to find the application layer > packet when using display > > filters and there are multiple application layer packets bundled in a > single frame. I also have > > traces with a large number of bundled chunks. > > > > > > > Hence, when i apply display filter , only the chunks with exact > matches should be visible. Is this supported currently? > > > >No. Filtering is based on packets. Not sure how to improve that. We > can't show 'half' of a packet. > > > However, there might be ways to draw your attention to the upper layer > packet which matches the > > > filter. > > > Regarding above point, would like to suggest that the packet > information being displayed can be restricted to the PDU which actually > matches the display filter. E.g out of an SCTP packet carrying 3-4 M3UA > chunks, the pinfo of only the chunk matching the filter can be displayed? > > Thinking about this... What about displaying only the frames, which > match a display filter (like today). > > However, it might be helpful to highlight that part (like the M3UA > packet) which matches the display filter. > > This should allow to find the upper layer packet pretty fast. What do > you think? > > > > Best regards > > Michael > > > > > > Vineeth > > > > > > On Fri, Jan 11, 2013 at 12:54 AM, Michael Tuexen < > michael.tue...@lurchi.franken.de> wrote: > > > On Jan 10, 2013, at 5:31 PM, vineeth vijay wrote: > > > > > > > Hi, > > > > > > > > Dissection is fine. What I was wondering is whether it is possible > to show these individual data chunks as separate frames themselves. > > > But they are in the same frame. I really prefer not to show them in a > way they > > > have not been on the wire. > > > > Hence, when i apply display filter , only the chunks with exact > matches should be visible. Is this supported currently? > > > No. Filtering is based on packets. Not sure how to improve that. We > can't show 'half' of a packet. > > > However, there might be ways to draw your attention to the upper layer > packet which matches the > > > filter. > > > > > > Best regards > > > Michael > > > > Currently , i use the below tool for this purpose: > > > > http://frox25.no-ip.org/~mtve/wiki/SctpDechunk.html > > > > > > > > Reg
Re: [Wireshark-dev] SCTP De-chunking support
Hi, Yes, highlighting would work too. Ultimately the application info corresponding to display filter should be visible easily without the need to scroll through the entire frame. Any suggestions on how to achieve this? I think GUI coloring implementation would paint the entire frame with the same color,wouldn't it? Vineeth On Fri, Jan 11, 2013 at 1:44 AM, Michael Tuexen < michael.tue...@lurchi.franken.de> wrote: > > On Jan 10, 2013, at 8:49 PM, vineeth vijay wrote: > > > Hi, > > > > > Dissection is fine. What I was wondering is whether it is possible to > show these individual data chunks as separate frames themselves. > > >But they are in the same frame. I really prefer not to show them in a > way they > > have not been on the wire. > > > > Basically agreed on the above point. Changing the default behavior may > not be good due to all the copied lower layer bytes and resulting increase > in the size of capture in case there are 4-5 chunks per packet. But still > feel it would be a nice optional feature to have when doing actual offline > analysis. > I do understand that it is sometimes hard to find the application layer > packet when using display > filters and there are multiple application layer packets bundled in a > single frame. I also have > traces with a large number of bundled chunks. > > > > > Hence, when i apply display filter , only the chunks with exact > matches should be visible. Is this supported currently? > > >No. Filtering is based on packets. Not sure how to improve that. We > can't show 'half' of a packet. > > However, there might be ways to draw your attention to the upper layer > packet which matches the > > filter. > > Regarding above point, would like to suggest that the packet information > being displayed can be restricted to the PDU which actually matches the > display filter. E.g out of an SCTP packet carrying 3-4 M3UA chunks, the > pinfo of only the chunk matching the filter can be displayed? > Thinking about this... What about displaying only the frames, which match > a display filter (like today). > However, it might be helpful to highlight that part (like the M3UA packet) > which matches the display filter. > This should allow to find the upper layer packet pretty fast. What do you > think? > > Best regards > Michael > > > > Vineeth > > > > On Fri, Jan 11, 2013 at 12:54 AM, Michael Tuexen < > michael.tue...@lurchi.franken.de> wrote: > > On Jan 10, 2013, at 5:31 PM, vineeth vijay wrote: > > > > > Hi, > > > > > > Dissection is fine. What I was wondering is whether it is possible to > show these individual data chunks as separate frames themselves. > > But they are in the same frame. I really prefer not to show them in a > way they > > have not been on the wire. > > > Hence, when i apply display filter , only the chunks with exact > matches should be visible. Is this supported currently? > > No. Filtering is based on packets. Not sure how to improve that. We > can't show 'half' of a packet. > > However, there might be ways to draw your attention to the upper layer > packet which matches the > > filter. > > > > Best regards > > Michael > > > Currently , i use the below tool for this purpose: > > > http://frox25.no-ip.org/~mtve/wiki/SctpDechunk.html > > > > > > Regards, > > > Vineeth > > > > > > what problem are you trying to solve? Wireshark supports dissecting > the upper layer paylaod > > > for bundled DATA chunks for ages... > > > > > > Best regards > > > Michael > > > > > > > > Vineeth > > > > > ___ > > > > Sent via:Wireshark-dev mailing list > > > > > Archives:http://www.wireshark.org/lists/wireshark-dev > > > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > > > > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > > > > > > > ___ > > > Sent via:Wireshark-dev mailing list > > > Archives:http://www.wireshark.org/lists/wireshark-dev > > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > > > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > > > > > > >
Re: [Wireshark-dev] SCTP De-chunking support
Hi, > Dissection is fine. What I was wondering is whether it is possible to show these individual data chunks as separate frames themselves. >But they are in the same frame. I really prefer not to show them in a way they have not been on the wire. Basically agreed on the above point. Changing the default behavior may not be good due to all the copied lower layer bytes and resulting increase in the size of capture in case there are 4-5 chunks per packet. But still feel it would be a nice optional feature to have when doing actual offline analysis. > Hence, when i apply display filter , only the chunks with exact matches should be visible. Is this supported currently? >No. Filtering is based on packets. Not sure how to improve that. We can't show 'half' of a packet. However, there might be ways to draw your attention to the upper layer packet which matches the filter. Regarding above point, would like to suggest that the packet information being displayed can be restricted to the PDU which actually matches the display filter. E.g out of an SCTP packet carrying 3-4 M3UA chunks, the pinfo of only the chunk matching the filter can be displayed? Vineeth On Fri, Jan 11, 2013 at 12:54 AM, Michael Tuexen < michael.tue...@lurchi.franken.de> wrote: > On Jan 10, 2013, at 5:31 PM, vineeth vijay wrote: > > > Hi, > > > > Dissection is fine. What I was wondering is whether it is possible to > show these individual data chunks as separate frames themselves. > But they are in the same frame. I really prefer not to show them in a way > they > have not been on the wire. > > Hence, when i apply display filter , only the chunks with exact > matches should be visible. Is this supported currently? > No. Filtering is based on packets. Not sure how to improve that. We can't > show 'half' of a packet. > However, there might be ways to draw your attention to the upper layer > packet which matches the > filter. > > Best regards > Michael > > Currently , i use the below tool for this purpose: > > http://frox25.no-ip.org/~mtve/wiki/SctpDechunk.html > > > > Regards, > > Vineeth > > > > what problem are you trying to solve? Wireshark supports dissecting the > upper layer paylaod > > for bundled DATA chunks for ages... > > > > Best regards > > Michael > > > > > > Vineeth > > > > ___ > > > Sent via:Wireshark-dev mailing list > > > Archives:http://www.wireshark.org/lists/wireshark-dev > > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > > > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > > > > > ___ > > Sent via:Wireshark-dev mailing list > > Archives:http://www.wireshark.org/lists/wireshark-dev > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > > > > > ___ > > Sent via:Wireshark-dev mailing list > > Archives:http://www.wireshark.org/lists/wireshark-dev > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] SCTP De-chunking support
Hi All, Has the de-chunking of SCTP within wireshark been attempted yet? I noticed some old conversations in mailing list in this regard, but nothing concrete has turned up yet. While trying to do this in tshark, I have tried calling tshark's process_packet() function from packet-sctp.c file in dissectors but got nowhere due to linking issues. I feel the way to do this would be: 1) Create a global copy of entire frame at initial stage (Is there any other way to access the entire frame structure from packet-sctp where ultimately the decision whether to do de-chunking or not would be made. ) 2) In case there are several chunks in the packet, allow the completion of processing till first chunk and create composite tvbs consisting of eth+ip+sctp_header+remaining_individual_chunks. 3) Correct IP checksums and length in the composite Tvb. 4) Process these tvb's individuallly. (Is this possible with the rule to have a single capture file at a time?? Can a capture file structure be modified on the fly?) Is the above process doable without breaking wireshark/tshark processing structure? Can anybody suggest a better solution... Vineeth ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] SCTP De-chunking support
Hi, Dissection is fine. What I was wondering is whether it is possible to show these individual data chunks as separate frames themselves. Hence, when i apply display filter , only the chunks with exact matches should be visible. Is this supported currently? Currently , i use the below tool for this purpose: http://frox25.no-ip.org/~mtve/wiki/SctpDechunk.html Regards, Vineeth > > what problem are you trying to solve? Wireshark supports dissecting the > upper layer paylaod > for bundled DATA chunks for ages... > > Best regards > Michael > > > > Vineeth > > > ___ > > Sent via:Wireshark-dev mailing list > > Archives:http://www.wireshark.org/lists/wireshark-dev > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
