Re: Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe

[Mark Landriscina <mlandri () verizon net>]

Google indicates that Protocol Buffers is portable across MAC, Windows, Linux though I've only used it in a Linux build 
env. My code is certainly platform agnostic. The business case for using Protocol Buffers instead of XML or JSON is 
performance wrt to data serialization and serialized data parsing. This was my specific need but certainly might not be 
a general need.


Just wanted to offer the code in the event that it'd be useful to others. Not seeing much demand at the moment. Not a 
big deal.


Appreciate the input!


Regards,
Mark



-----Original Message-----
From: Anders Broman <anders.broman () ericsson com>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Sent: Tue, Jul 11, 2017 11:20 am
Subject: Re: [Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe



> and requires pthread and protobuf libs be installed.
Is this portable to MAC and Windows?
Regards
Anders
 
From: Wireshark-dev [mailto:wireshark-dev-bounces () wireshark org]On Behalf Of Pascal Quantin
Sent: den 11 juli 2017 17:13
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Subject: Re: [Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe
 

 

 

2017-07-11 17:07 GMT+02:00 Mark () verizon net <mlandri () verizon net>:


I was concerned about the c++ issue, which helped motivate the question. 

 

Only one object file requires c++. In fact, I'm still compiling my modified tshark in C. The required function in the 
c++ object file is callable from C. 

 

Pascal, do you think that this is still to much of a barrier? 


 

As far as I know, given our current discussion state, I would say yes (or it might be a separated library). Moreover 
I'm not sure also how useful this feature would be for others but I might miss the point.

Let's see what kind of feedback you collect.

Pascal.


 

Sent from my iPhone




On Jul 11, 2017, at 10:47 AM, Pascal Quantin <pascal.quantin () gmail com> wrote:


Hi Mark,

 

2017-07-11 16:07 GMT+02:00 Mark () verizon net <mlandri () verizon net>:


Thanks Roland! 

 

I guess I'm asking if it'd be value added for me to submit my protobuf solution as an addition to current Wireshark dev 
branch. I've already written the code. I'd just have to figure out how to incorporate it into the Wireshark build 
process. It's written in c++ and requires pthread and protobuf libs be installed.


 

This is a first issue as all Wireshark code (except the Qt GUI) is written in C and this is not something we discussed 
changing so far.


 

Happy to do it but would be good to know beforehand if it'd be compatible with Wireshark design ethos and if the 
community would see value in it.

 

Sent from my iPhone




On Jul 11, 2017, at 9:00 AM, Roland Knall <rknall () gmail com> wrote:


Did you take a look at tshark's -T parameter? "tshark -T jsonraw" for instance, delivers full dissection in Json 
format. What would be needed is only to shove that into a pipe to capture from some other place.

 

Cheers

Roland


 

On Tue, Jul 11, 2017 at 2:48 PM, Mark Landriscina <mlandri () verizon net> wrote:

 
Apologies in advance if this question is a bit long-ish.
I've been wondering why Wireshark/tshark doesn't offer the option to export full packet dissection data via named pipe 
(serialized binary data). Is this due to design philosophy, lack of offers to write the code, or some other reason? Of 
course, packet dissection data can be written out to stdout or a file in xml format. Perhaps this meets most needs?
Reason for the question is that I needed a dissection data export option that was more efficient than xml. My solution 
was to modify tshark so it can leverage Google Protocol Buffers to export packet dissection data as serialized binary 
data. Serialized dissection data is written out to a named pipe. Protobuf dissect tree creation, serialization, export 
code is all written in C++ and takes advantage of all the optimization work Google has put into its Protobuf library. 
The client/read side of the pipe can be written in any language supported by the Protobuf library. I wrote mine in 
Python. The client reads and parses the serialized dissection data (again) using Google Protobuf lib recreating 
dissection tree data on client side.
Would it be advantageous to incorporate the above Protobuf approach into the Wireshark project or would the community 
consider it unnecessary or perhaps undesirable?
If you're curious about implementation, you can see my project at the following location: 
https://gitlab.com/MLandriscina/protoShark.git. This is the first time that I've used Protobuf, so I wouldn't be 
surprised to discover that better implementations are possible.

___________________________________________________________________________
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-request () 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-request () 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-request () 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-request () 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-request () wireshark org?subject=unsubscribe

 


___________________________________________________________________________Sent via:    Wireshark-dev mailing list 
<wireshark-dev () wireshark org>Archives:    https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.wireshark.org/mailman/options/wireshark-dev             mailto:wireshark-dev-request () 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-request () wireshark org?subject=unsubscribe