wireshark-dev August 2010 archive
Main Archive Page > Month Archives  > wireshark-dev archives
wireshark-dev: Re: [Wireshark-dev] libtshark + scripting languag

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

From: Eloy Paris <peloy_at_nospam>
Date: Fri Aug 20 2010 - 15:54:38 GMT
To: wireshark-dev@wireshark.org

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

@@ -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.


Eloy Paris.-
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