[Michael Cohen <michael.cohen@xxxxxxxxxxxxxxx>]

Hi Joerg,
  I am writing a GPL forensics package called pyflag:
  
  http://pyflag.sf.net/

  The application has a much wider scope from that of ethereal itself. I
  am writing a python binding for libethereal which is working really
  well actually. At least until I hit those problems with libethereal
  people have mentioned previously. Eventually I hope the python binding
  can make it into ethereal source tree, but that will simply make
  libethereal available for python developers - and we will need to deal
  with the same sort of problems we are dealing with now.
  
  PyFlag uses ethereal to dissect the packets, but ethereal itself
  doesnt really open a packet file per se. PyFlag parses the pcap file
  and gives libethereal parcels of data to dissect. This is done for
  persistance reasons (results are stored in a long term db).

  I understand that thread safety is an issue, and even having
  libethereal handle multiple dissections simultaneously. This can be a
  restriction for clients of libethereal which will be relaxed once the
  code plays nice enough. The way pyflag uses libethereal is to dissect
  each packet, look at the fields, store some of them in the db and then
  discard the dissector so thats not a huge problem. A generic library
  needs to handle concurency though.

  I think that having a proper libethereal opens ethereal to huge
  possibilities - for example imagine an ids using snort to trigger a
  packet capture for certain packets, and then using libethereal to
  dissect them in a more thorough/detailed way than snort does (im
  thinking netbios stuff - usernames for example). Providing a detailed
  gui of the packets to users over a web application etc.
  
  I am not very familiar with windows, but I thought that dlls can also
  have import tables. Currently libethereal imports some libraries just
  not all:

  $ ldd /usr/lib/ethereal/libethereal.so.0
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0
        libdl.so.2 => /lib/tls/libdl.so.2 (0x40c6c000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x40c6f000)
        libpcre.so.3 => /usr/lib/libpcre.so.3 (0x40cef000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40cff000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40d11000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40d20000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

  My goal is to allow people to compile pyethereal without access to the
  ethereal source tree. I can do this:

  $ gcc -I /usr/include/python2.3/ `glib-config --cflags glib` \
  pyethereal_wrap.c  -shared  -o _pyethereal.so $(ldd $(which tethereal\
  ethereal | head -n 1) | awk '{print $3};') 

  But its a little ugly (but works). The reason is that even if they
  have access to the ethereal source tree, its unlikely to configure
  exactly the same way that their distribution ships it, so the
  pyethereal binding cant work against the system libethereal. Of course
  there is the issue of the .h files which I mentioned before.

  This issue also needs to be solved for other developers. Other people
  on this list expressed a desire to be able to use libethereal in their
  projects. The same issues also apply to them.

  I appreciate that Guy mentioned that the API is still evolving. I
  think this is a chicken and egg problem - if people were able to link
  against libethereal, their requirements would influence the API in
  ways the original design did not anticipate. If only due to the fact
  the code is put into different usage situation to ethereal. So the API
  will always evolve to some degree when making libethereal user
  friendly. It may be possible to design a generic interface API to hide
  this for example in pyethereal I export high level python objects
  which use wraper functions to present a reasonably consistant view of
  the ethereal API.

  Michael.

On Sat, May 28, 2005 at 10:08:19AM +0200, Joerg Mayer wrote:
> On Sat, May 28, 2005 at 10:25:30AM +1000, Michael Cohen wrote:
> >    Would it be worth fixing the build problems first, and then tackling
> >    problems as they arise. For example you mention that libethereal does
> >    not support having multiple instances of everything. Do you mean that
> >    libethereal is not multi-threaded? or that all dissection trees share
> >    common static memory?
> 
> Yes, Ethereal (and especially libethereal) is not threadsave and it will
> be lots of work to make it that. We want to get there eventually, but
> it may take a long time until we actually do. You are free to speed up
> that process of course ;-)
> 
> >    I think I have a way to work around the build deficiencies, but it is
> >    an ugly hack (tm). I can do an ldd on the ethereal/tethereal binary
> >    and just link all those libraries into my binary as well.
> 
> The linking process deficiencies derive from restrictions on some platforms
> - we changed it to be the way it is today because of these problems
> (I don't remember which, maybe windows?). The restriction is: a library
> cannot link to other libraries directly.
> 
> >    Would it be worth having a look at the libethereal build process to
> >    see if I can easily fix this for inclusion into cvs?
> 
> If you talk about the linking dependencies problem: Probably not -
> unless I am wrong, which might also be the case :-)
> 
> Btw - what sort of program are you writing? Maybe it can be put
> into the Ethereal source tree directly, thus giving you the necessary
> dependencies for free.
> 
>   Ciao
>    Joerg
> -- 
> Joerg Mayer                                           <jmayer@xxxxxxxxx>
> We are stuck with technology when what we really want is just stuff that
> works. Some say that should read Microsoft instead of technology.
> 
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev