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