Taking Anders comment into consideration first, I'd also make a patchset available for review, so we can take a look at it.
Personally I still do not fully get the idea behind this project, but that does not mean it should not be submitted. I am in favor however of adding more remote capabilities to Wireshark, as well as extend the plugin if structures. Therefore I'd say just submit a patch set, and we go from there. regards, Roland On Fri, Jan 6, 2017 at 2:41 PM, Anders Broman <[email protected]> wrote: > Does this overlap with sharkd by Jacub, currently under review in gerrit? > Regards > Anders > > Den 6 jan. 2017 2:35 em skrev "Paul Offord" <[email protected]>: > > Hi, > > > > Some time ago I wrote a Wireshark plugin (called Syncro) that enables a > program to send commands to Wireshark. The command set is based on the > capabilities provided by the Wireshark Plugin IF API (go to frame, apply > filter, etc.). > > > > The commands are sent to Wireshark via a TCP connection, and so there is a > small TCP service running on a separate thread in Wireshark. The TCP > service, multi-threading and thread-to-thread communications are built on > Qt. Note the email trail below, where Roland suggests that it might not be > necessary to use Qt. > > > > I’d like to submit this to the Wireshark project as I think it could form > the basis for a general capability of controlling Wireshark from a loosely > coupled application. Is this code suitable for submission to the project? > > > > Thanks and regards…Paul > > > > *From:* [email protected] [mailto:wireshark-dev-bounces@ > wireshark.org] *On Behalf Of *Roland Knall > *Sent:* 05 August 2016 11:57 > *To:* Developer support list for Wireshark <[email protected]> > *Subject:* Re: [Wireshark-dev] Adding Qt5 libs via VS Additional > Dependencies > > > > This is exactly what I do here with my plugin. Although without the TCP > part. The method to do it without using Qt in the dissector is to implement > a tap interface in the dissector, and register the plugin on that > interface. The plugin than can start the TCP server and monitors the tap > interface and reacts accordingly to the commands. Would work fine for you, > the same way you do it now, but would be far easier to maintain. The > dissector would be stable and does never need to change, and all you would > have to recompile is the plugin. > > > > regards > > Roland > > > > On Fri, Aug 5, 2016 at 12:46 PM, Paul Offord <[email protected]> > wrote: > > Hi Roland, > > No, not really an RPC interface. Some very simple commands and events > flow back and forth, like this: > > Command|GoToFrame|55 > > Response|MovedToFrame|55 > > Event|MovedToFrame|67 > > We needed it to be a dissector to enable us to detect when the user moves > within a trace so that we can generate a suitable asynchronous event. We > also needed the functionality now, and it had to work with standard WS > releases, so it had to be a plugin of some sort. By the way, we are not > planning to submit this to be incorporated into the main stream code. > > You can see Syncro in action here http://www.youtube.com/watch?v > =anEZGfF4P10&t=5m5s if you are interested. > > Best regards…Paul > > > > *From:* [email protected] [mailto:wireshark-dev-bounces@ > wireshark.org] *On Behalf Of *Roland Knall > *Sent:* 05 August 2016 11:10 > > > *To:* Developer support list for Wireshark <[email protected]> > *Subject:* Re: [Wireshark-dev] Adding Qt5 libs via VS Additional > Dependencies > > So, if I understand it correctly, it is a RPC interface? I still think, > implementing this as a dissector is a major overkill, and will also lead to > issues further down the line, if dissectory API changes or similar issues. > I'd implement such an interface via a simple plugin architecture, which > would have the added benefit, that you do not have the need for an active > dissection runnning, to query the instance. A dissection should be mainly > about "How to interpret packet data", which is not the case here. > > regards > > Roland > > > > On Fri, Aug 5, 2016 at 11:33 AM, Paul Offord <[email protected]> > wrote: > > Hi Roland, > > The dissector is called Syncro and it allows a remote process to access > the WS plugin_if extensions through a TCP connection. We wanted to be able > to achieve this without building a custom version of WS and so built it as > a dissector. We don’t use any of the GUI stuff from Qt, just the TCP > server functionality, multi-threading functions and Signals & Slots to > communicate between threads. > > Best regards…Paul > > > > ______________________________________________________________________ > > This message contains confidential information and is intended only for > the individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. > > Any views or opinions expressed are solely those of the author and do not > necessarily represent those of Advance Seven Ltd. E-mail transmission > cannot be guaranteed to be secure or error-free as information could be > intercepted, corrupted, lost, destroyed, arrive late or incomplete, or > contain viruses. The sender therefore does not accept liability for any > errors or omissions in the contents of this message, which arise as a > result of e-mail transmission. > > Advance Seven Ltd. Registered in England & Wales numbered 2373877 at > Endeavour House, Coopers End Lane, Stansted, Essex CM24 1SJ > > ______________________________________________________________________ > This email has been scanned by the Symantec Email Security.cloud service. > For more information please visit http://www.symanteccloud.com > ______________________________________________________________________ > > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscr > ibe > > > > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject= > unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
