Wireshark mailing list archives
Re: Question regarding QT/future Wireshark version
From: Roland Knall <rknall () gmail com>
Date: Wed, 11 Jan 2012 16:28:51 +0100
On Wed, Jan 11, 2012 at 11:25 AM, Guy Harris <guy () alum mit edu> wrote:
On Jan 11, 2012, at 2:02 AM, Roland Knall wrote:The same goes for the "Conversation List", "IO Graph" as well as the "Endpoint List". Also, following a specific conversation could be tricky.That just sounds like insufficient generality in Wireshark's notion of endpoints. Presumably there's something in the industrial-control protocols in question that identifies the particular device being talked to rather than just the controller (presumably the controllers can be identified by a MAC address). This problem is not unique to industrial-control protocols. Wireshark also lacks sufficient generality in its notion of conversations - for example, an "NFSv2/v3 conversation" might include traffic between several different transport-layer endpoints (NFS, Network Lock Manager, etc.).
What sort of generic approach are you thinking of? I.e., what sort of capabilities would be in the Wireshark UI core (and possibly in TShark as well, e.g. to run some tap in TShark with a capture file and have it write out a PDF containing those graphical representations)?
Yeap, that is mainly my issue. My preferred solution would be to add the information via an expert info or a similar notion directly to the packet itself, where it could be read in the gui and displayed accordingly. The dissector would have to identify the endpoints and individually name them, so that they can be differentiated. But he would also only provide the information. The gui itself would then be able to individually display a graph using those endpoints. This should be able to be set for each dissector individually. So I would be able to display the graph either using the MAC endpoints for the BC's or the individually defined endpoints for my dissector, and additionally would there be able to gain the information which other endpoints are in use for my specific one, enabling some sort of packet tracer through more heavily defined networks. Allowing additional customized endpoints I could identify the conversation between two individual applications, even if they use different protocols or path-ways.
And I have some hopes, that with a good plugin mechanism this could be solved using the Qt solution.So why would Qt make any difference here (other than perhaps being a more convenient API than GLib/GTK+)?
You are on to me here, I have developed Qt applications for the past 6 years now, so it is for me an easier way.
As indicated, we already support GUI plugins as taps.
I am currently looking into that. kind regards, Roland ___________________________________________________________________________ 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
Current thread:
- Re: Question regarding QT/future Wireshark version, (continued)
- Re: Question regarding QT/future Wireshark version Stephen Fisher (Jan 05)
- Re: Question regarding QT/future Wireshark version Guy Harris (Jan 05)
- Re: Question regarding QT/future Wireshark version Gerald Combs (Jan 05)
- Re: Question regarding QT/future Wireshark version Roland Knall (Jan 06)
- Re: Question regarding QT/future Wireshark version Anders Broman (Jan 06)
- Re: Question regarding QT/future Wireshark version Guy Harris (Jan 06)
- Re: Question regarding QT/future Wireshark version Guy Harris (Jan 11)
- Re: Question regarding QT/future Wireshark version Roland Knall (Jan 11)
- Re: Question regarding QT/future Wireshark version Guy Harris (Jan 11)
- Re: Question regarding QT/future Wireshark version H Sivank (Jan 11)
- Re: Question regarding QT/future Wireshark version Roland Knall (Jan 11)
- Re: Question regarding QT/future Wireshark version Guy Harris (Jan 05)
- Re: Question regarding QT/future Wireshark version Stephen Fisher (Jan 05)
- Re: Question regarding QT/future Wireshark version Andreas Sikkema (Jan 13)
- Re: Question regarding QT/future Wireshark version Guy Harris (Jan 13)