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?
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe

Reply via email to