On Aug 18, 2010, at 10:34 AM, Mark Landriscina wrote:
> I'd like to contribute some work that I've done to the wireshark community and need some advice on the best way to do this, assuming there is interest. If not, that would be good to know as well. I suspect that it might be best to fork this off as a separate project vs. incorporating it directly into ongoing SVN builds.
>
> My initial goal was to modify the tshark (command line wireshark) and wrap it as a Python module. I wanted to expose tshark dissections as Python objects during packet capture or capture file processing. In addition this, I found that it was quite easy to extend this idea a bit more, so that other scripting languages (in additional to Python) could leverage the same code base. See below for details.
>
> My motivation was that I wanted to do some work with Scapy and needed to access application layer protocol dissections within Python without re-writing all the dissection code already available in tshark/wireshark.
>
> This is what I have done to date (all Linux for now,
...which hopefully really means "all UN*X for now", so that it largely Just Works on Solaris, *BSD, Mac OS X, HP-UX, etc.
> but am porting to Windows):
>
> a. Modified tshark code base and compiled it as a library, libtshark.a. This is the original tshark executable, more or less, with some notable additions. In particular, after packet dissection, the epan dissection tree data is copied off into another tree structure that I've defined.
The tshark executable image, by default, actually contains no code to parse packets or to read capture files; it's linked with two dynamically linked libraries, libwireshark (which contains all the dissection code) and libwiretap (which contains all the capture-file reading code).
What code other than that code is in your libtshark.a? Or does anything linked with libtshark.a also have to be linked with libwireshark and libwiretap?
> This t_dissect_node tree is then serialized and written out over a named-pipe. The name of the named-pipe is defined by the user at run-time. The code to unserialize the t_dissect_node tree is also part of libtshark.a.
So what's the reason for the named pipe?