wireshark-dev August 2010 archive
Main Archive Page > Month Archives  > wireshark-dev archives
wireshark-dev: Re: [Wireshark-dev] Wireshark-dev Digest, Vol 51,

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

From: Mark Landriscina <mlandri1_at_nospam>
Date: Wed Aug 18 2010 - 20:04:42 GMT
To: wireshark-dev@wireshark.org

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