Re: Wireshark-dev Digest, Vol 51, Issue 22

[Mark Landriscina <mlandri1 () jhu edu>]

Eloy,

I found two references Python related projects. First embedded the Python interpreter into Wireshark, so that one could 
call Python scripts from with Wireshark. The other was a project that allowed one to write dissectors in Python. 
Really, the first effort is closest to what I was looking for. In fact, this was the first approach that I tried a 
while back due to its simplicity. However, it turned out to be awkward to use in a larger Python-based automated 
program/framework.

You're correct, I could have kept tshark as an executable instead of a lib and then spawned it off as a separate 
process from within Python. This would have worked. I would still be able to access all the dissection data from within 
Python (via the named-pipe and the serialized data structs that I wrote). In the end, it wasn't any additional work to 
instead compile it as a library. Compiling as a lib allows me to call tshark as a Python function and then fork it off, 
which is what my code does. In then end, just boils down to preference, I suppose. :)

I took a look at your site. Pretty cool. Looks like you were way ahead of me but in tcl instead of Python. I'm using 
thsarkPY with code from a project named Scapy (not my code) to do similar things.

> Hi Mark,
>
> On 08/18/2010 01:34 PM, Mark Landriscina wrote:
>
> [...]
>
> > 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.
>
> I am not a Python guy but my understanding is that there is Python 
> support in Wireshark trunk (perhaps in 1.4.x). Did you look into that 
>
> and determined that it wasn't good enough for what you need? Just curious.
>
> > 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. 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.
> > Also, I have incorporated some additional helper code that makes tree
> > navigation easier. A function named 'run' is called to start tshark
> > and accepts as parameters tshark command line args.
>
> Any reason you chose to integrate tshark instead of libwireshark, 
> which 
> is what does all the dissection work, as Guy mentioned? I would guess 
>
> that it is because it is easier to execute tshark than to fully 
> integrate libwireshark, but then I don't understand why you need to 
> make 
> tshark a library instead of just executing it from within Python.
>
> I actually had a similar need and my approach was to interface with 
> libwireshark. You can check out my work at 
>
> Cheers,
>
> Eloy Paris.-
> netexpect.org

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe