Wireshark · Wireshark-dev: Re: [Wireshark-dev] libtshark + scripting language support

[Mark <mlandri@xxxxxxxxxxx>]

Hey Eloy,

Great feedback on work associated with keeping up with libwireshark!

re:

> Well, I don't know much about this but would you not be re-inventing the 
> wheel because of the existing Python support in recent/development 
> versions of Wireshark? If so, wouldn't it be better to improve that 
> existing code?

Unless I've just overlooked something, which is always possible, the 
Python support referenced is different from what I've done/am 
considering. I've seen two Python related items.

1. Ability to write dissectors in Python and have Wireshark call those 
dissectors. Awesome but different.

2. Embedded Python interpreter in Wireshark, which allows you to call 
Python code as (more or less) a call back function. However, you still 
have to run Wireshark as a separate application. This approach is fine 
for many things. In fact, I'd used this same approach a while back. 
However, I found that this is a bit awkward when used in a larger 
Python-based framework. Still it is cool and I will look to see if I can 
contribute anything value-added to this.

Unlike the above, my code is integrated into Python as a Python module. 
Hence, Python calls tshark functionality instead of the other way 
around. Could still be more integrated. Before doing anything else, 
however, I want to take a close look at the code from the other projects 
and suggestions referenced in this thread. Will probably take me a while 
to digest all the info. In the end, I suspect that I will move to 
something closer to what you and Thierry have done.


Thanks!

Eloy Paris wrote:
> Hi Mark,
>
> On 08/19/2010 03:12 PM, Mark Landriscina wrote:
>
>   
> > Eloy,
> >
> > I've picked up on two separate threads in this discussion. First is,
> > "does my approach work for me?" I think that it does and I
> > appreciate your comments on this topic. Second is,"is there much
> > utility is offering my code up as another wireshark related
> > project?" I thought that the answer to this question might be 'yes'.
> > However, I am hearing that there might be better/more useful
> > approaches if the goal is to start a project that makes wireshark
> > dissection capabilties more available to scripting languages such as
> > Python, Ruby, etc. Also, the Wireshark listserve admin gods haven't
> > exactly been beating down my door to get ahold of my code ...
> >     
>
> Yup, this is a good summary of the discussion so far. With regards to 
> the second question I think the answer is "yes" although it is possible 
> that the general sentiment is that this is something that would better 
> be maintained outside of the Wireshark code base, which is probably why 
> you haven't heard from the Wireshark developers.
>
> They also have their hands full with Wireshark-related things and their 
> own code so don't read too much into the perceived lack of interest -- 
> that is not necessarily the case.
>
>   
> > Given the above, I was thinking about the following course of
> > action.
> >
> > 1. Use what I have already written for my current project. The folks
> > that I am working with are already familiar with tshark and having a
> > tshark-like Python experience works for them. Also, I am still in the
> > "this is so cool!" phase of my relationship with this code.
> >     
>
> Sounds reasonable.
>
>   
> > 2. Future work, however, might be more interesting/usable by others
> > if I try to develop something that more directly exposes Wireshark
> > dissection functionality and makes it more easily available to
> > scripting languages. Not sure how I would do this yet, however.
> >     
>
> Well, I don't know much about this but would you not be re-inventing the 
> wheel because of the existing Python support in recent/development 
> versions of Wireshark? If so, wouldn't it be better to improve that 
> existing code?
>
> Oh, there is also Lua support in Wireshark. That is another scripting 
> language with built-in support.
>
>   
> > I do have a quick related question for you. I noticed that you you
> > support specific versions of  libwireshark in your project. Has
> > keeping up with the evolution of wireshark code been terribly
> > onerous?
> >     
>
> This is a great question, and I'd love to hear Thierry's thoughts on 
> this as well since he is the other person I know that is using 
> libwireshark services in an application not related to the Wireshark 
> project (I actually learned about Thierry's use of libwireshark through 
> this thread).
>
> My personal take on this is that it is not hard to keep up with 
> Wireshark code changes. I started using libwireshark in my application 
> in the 0.99.x series, and I have been able to update my application to 
> interface with the libwireshark library used in the Wireshark 1.0.x, 
> 1.2.x, and now the 1.4rc series.
>
> The changes required haven't been too bad -- it usually takes looking at 
> what has changed in tshark.c and integrating those changes in your own 
> application. Tshark is the best and easiest example of an application 
> that uses libwireshark services, and since it is part of the project, 
> any API changes in libwireshark/libwiretap/libwsutil are reflected in 
> Tshark right away.
>
> So far, for the most part, the changes required to keep up with 
> Wireshark development have been like this (from the 1.0.x to the 1.2.x 
> migration):
>
> ------------------------------------------------------
> @@ -28,15 +28,14 @@
>
>   #include <epan/timestamp.h>
>   #include <epan/packet.h>
> -#include "cfile.h" /* Should be provided by libwireshark. Needed to avoid
> -                     compiler error when including epan/column.h */
>   #include <epan/column.h>
>   #include <epan/column-utils.h>
>   #include <epan/prefs.h>
> -#include <epan/privileges.h>
> +#include <wsutil/privileges.h>
>
>   /* These are used by epan_init() */
>   static void read_failure_message(const char *, int);
> +static void write_failure_message(const char *, int);
>   static void failure_message(const char *, va_list);
>   static void open_failure_message(const char *, int, gboolean);
>
> @@ -64,7 +63,7 @@
>
>       epan_init(register_all_protocols, register_all_protocol_handoffs,
>                NULL, NULL, failure_message, open_failure_message,
> -             read_failure_message);
> +             read_failure_message, write_failure_message);
> ------------------------------------------------------
>
> i.e. change in location/names of include files and small API change here 
> and there.
>
> In theory it should be easy to support different libwireshark version by 
> using #if statements in your application, but I personally haven't done 
> that with Network Expect.
>
> Something that I, as a developer using libwireshark services, would like 
> to see is work on polishing the APIs provided by the libwireshark, 
> libwiretap, and libwsutil libraries so they are easier to use by 
> external developers like myself and Thierry. For example, most 
> libwireshark data structures should be opaque and external developers 
> should not have visibility into them. This would require provided two 
> sets of include files; private include files and public include files, 
> just like libpcap does (for example, libpcap does not expose to external 
> developers the internal structure of the pcap_t type. libwireshark in 
> contrast exposes everything).
>
> Ultimately, what would be ideal, at least from the point of view of 
> external developers, is to develop each library independently of the 
> applications that use them, i.e. a source code repository for 
> libwiretap, another one for libwireshark, and then keep the application 
> like wireshark and tshark in other source code repositories. This will 
> be a radical change in the way things are developed today so this would 
> probably be a hard sell with the core Wireshark developers :-(
>
> As Thierry said, libwireshark is such an amazing piece of software that 
> does such an awesome job dissecting packets/PDUs. It does not make sense 
> for someone that needs to dissect stuff to reinvent the wheel. There are 
> so many Person-Years into this project that it'd be impossible to come 
> up with something like libwireshark in a reasonable amount of time.
>
> Cheers,
>
> Eloy Paris.-
> netexpect.org
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
>
>