Re: libtshark + scripting language support

[Eloy Paris <peloy () chapus net>]

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 () 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