Wireshark-dev: Re: [Wireshark-dev] Question regarding QT/future Wireshark version
On Wed, Jan 11, 2012 at 11:25 AM, Guy Harris <guy@xxxxxxxxxxxx> 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
