Re: Question regarding QT/future Wireshark version

[Guy Harris <guy () alum mit edu>]

On Jan 11, 2012, at 2:02 AM, Roland Knall wrote:

> On Wed, Jan 11, 2012 at 10:38 AM, Guy Harris <guy () alum mit edu> wrote:
>
> > On Jan 6, 2012, at 6:15 AM, Roland Knall wrote:
> >
> > > Ok, let me clarify the idea. Let's for instance say, that you want to
> > > have a graphical representation of the inner-workings of a
> > > communication of two machines.
> >
> > BTW, you're not thinking of something such as what you can get from the Statistics -> Flow Graph... menu item, are 
> > you?
>
> Actually, that is kind-of what I am thinking, but this flow-diagram is
> not applicable for openSAFETY or industrial-ethernet solutions in
> general. Such devices use so-called bus-controllers to communicate,
> behind which the network communication takes place. That leads to the
> situation that often a device behind bc1 talks to other devices behind
> bc2 and bc3. In the flow-diagram such communication would now appear
> as single communications between bc1 and bc2/3, which does not
> represent the correct message flow.
>
> 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.).

> The second thing is, that I want to implement a network analyzer for
> openSAFETY. openSAFETY ( as many industrial-ethernet protocols ) is a
> multi-stage protocol. You have a "boot"-phase, a "configuration"-phase
> and a "operational"-phase. Each having their own specific
> communication commands and messages. A graphical representation of the
> network based on the diessected messages, as well as a graphical
> representation of the network status would be a useful add-on for the
> openSAFETY dissector. I am currently implementing some sort of tool
> for this using wireshark, but it is very openSAFETY specific, and I
> would prefer a more generic approach.

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)?

>  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+)?

As indicated, we already support GUI plugins as taps.
___________________________________________________________________________
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