Hi Björn I realized something similar by implementing a tap interface in the original protocol and a UI using a similar code as in the plugin “pluginifdemo”
Would it be possible to go that route? Regards, Roland > Am 27.01.2021 um 12:17 schrieb Björn > <bjoern.peter...@missinglinkelectronics.com>: > > > Hi, > > we use a custom dissector to analyze custom protocol traffic. However, to > further increase the usability, we need to add protocol analysis specific GUI > elements. For now, we are not aware of a way to add a first level plugin > which can be called through an encapsulation type from a pcap file. One other > point is that we are not able to load a compiled plugin to wireshark, if we > don’t build it from source. We can’t link against wireshark and cmake will > not load the project if we install wireshark from the APT packages. > > Are implementations available to add an encapsulation type via a plugin? > Could anybody point us to examples of similar attempts? > Is there already some work in progress to provide such a plugin mechanism for > extending the encapsulation types? > We noticed that distributed packets, e.g. in Ubuntu 18.04 do not allow for C > plugins to be loaded. Do you know if this is common practice? > Our goal is creating an open source tool to analyze communication within > SoCs, e.g. SoC FPGAs by providing both insight into protocol structure as > well as bit and timing accurate analysis at the same time with > cross-references. > You may think about this like an analyzer for video data transport protocols, > which provides the ability to cross-reference actual pixels within the frames > to the protocol entities that has contained them by showing the picture and > enables clicking through the pixels / areas of the frames and the frames > within the timeline of the video. When you click on an images pixel/area, the > respective protocol unit containing the pixel is highlighted and vice versa. > This allows for much better interpretation than going through the payload > view or the image separately. > > We already built a proof of concept, but we feel that this approach to > basically create a fork of the wireshark GUI is neither maintainable and > efficient nor something the community is looking for. > We are seeking for any comment/reply or proposals to advance and/or continue > this idea! > > Björn Petersen > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
