On Wed, Jan 11, 2012 at 11:25 AM, Guy Harris <g...@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-requ...@wireshark.org?subject=unsubscribe
