["Matthias" <matthias.nyffenegger@xxxxxxxx>]

Hi

I am new to the Ethereal developer mailing list.
Our team is currently working on a customer project which involves decoding
of
a proprietary protocol. Ethereal has been chosen as the basis for this task.
We have already implemented a prototype using the Ethereal protocol
dissector
plugin API.

Our customer wants us to enhance the Ethereal 'core' by the following
features:

   1. Stop capturing based on criterion:
      a) maximum disk usage reached
      b) maximum dump file size reached
      b) capture timer expired

   2. Dump captured packets to ringbuffer, i.e. only the most recently
captured
      packets are available (includes support for multiple dump files).

   3. Configuration GUI for 1. and 2.

In the mail attachement you can find a rough design proposal for points 1 &
2.
Any comment on this is much appreciated.

The customer is aware of the fact that Ethereal is an open source project
and
agrees to release these enhancements under GNU public license. We would like
to include the enhancements in the Ethereal development stream.

As mentioned above, the project involves decoding of a proprietary protocol.
The particular protocol is XML-style and sits on top of HTTP. Our customer
is currently specifiying another protocol which is also likely to be XML
based. We think about implementing a more generic protocol dissector for
XML-style protocols, configurable by XSLT style sheets.

The question is now, are there any plans or has anybody already started with
implemetation of one or more of the above mentioned features? I have been
sniffing through the Ethereal dev. mailing list archive but could not find
anything concrete.

Regards Matthias

--------------------
ICLIP AG
Matthias Nyffenegger
Sandrainstrasse 15
CH-3007 Bern
+41(0)313762017
--------------------

3.1. The autostop conditions

3.1.1. Information required to verify the stop conditions
       Criterion 1: stop logging based on time
         - The max. duration of the capture
         - The time passed since capture was started
         >> Must be checked periodically

       Criterion 2: stop logging cause max. disk usage
         - The allowed disk usage
         - The available disk space
         - The disk space required for the dump file
	 - The size of the next packet to be dumped
         >> Must be checked before dumping new data to the dump file.

       Criterion 3: stop logging cause max. log file size reached
         - The max. log file size
         - The current size of the logfile
	 - The size of the next packet to be dumped
         >> Must be checked before dumping new data to the dump file.

3.1.2. Actions to be performed when criterion is fulfilled
       (Criterion enumeration see chapter 3.1.1.)
       Criterion 1:
       Simply stop the capturing by setting capture loop condition to FALSE.

       Criterion 2 & 3:
       In case the current packet is still dumped, simply stop the capturing
       by setting capture loop condition to FALSE. If the current packet can't
       be dumped (because file size would exceed the max. size specified) there
       might be some cleanup work to do.

3.1.3. The stop condition verification handler
       The basic idea is to encapsulate the verification of a stop condition
       in a separate module while the associated action remains in the calling
       context. 

       A generic condition verification handler must be defined which would be
       called in appropriate places in order to check whether to stop capturing
       and possibly jump out of the normal program flow or to proceed without
       particular action. The calling context must supply sufficient
       information to the handler to enable it to verify the stop condition 
       (associated with the context) appropriately. The calling context is
       responsible for the actual 'stop signalling' and for the 'cleanup' after
       a stop has been signalled.

       Stop condition verifiers are functions that can be registered
       dynamically on the verification handler. The handler redirects the
       information recieved from the application at runtime to the appropriate
       verifier.   

       This design approach allows to dynamically change the stop conditions
       at runtime.

3.1.4. Where to hook into the application
       Timeout criterion:
       The timeout criterion could be verified in a timer callback function.
       The timer is started when capturing is started e.g. somewhere in the
       'capture()' function. In the timer callback we would call the generic
       verification handler which would invoke the appropriate stop criterion
       verification function.
	 
       File size, disk usage criterion:
       There is a generic point of access to the dump file provided by the 
       'wiretap' library in function 'wtap_dump()' in file '.\wiretap\file.c'.
	 
           'gboolean wtap_dump(wtap_dumper *wdh,
	                       const struct wtap_pkthdr *phdr,
                               const union wtap_pseudo_header *pseudo_header,
			       const u_char *pd,
			       int *err)'

       Here we have the size of the next packet to be dumped at disposal
       in argument 'phdr'. We also have the file descriptor of the dump file
       in argument 'wdh'. This is enough information to find out about the
       size of the dump file before and after dumping the current packet.

3.2. The ringbuffer
     A ringbuffer would be implemented by creating multiple dump files and
     overwriting them in round-robin fashion thus having only the most recent
     packets stored in the dump files.

     A process synchronization mechanism must be defined to synchronize access
     to multiple dump files in case of real time capturing where we have two 
     processes, the parent process which acts as the reader and the child
     process which acts as the writer. This implies ipc capabilities for the
     sync. mechanism.

     Ethereal currently supports a single dump file only. Dump file access
     is encapsulated through the 'wiretap' library, but it's not always
     used throughout the Ethereal 0.8.18 core. The 'wiretap' lib should be
     enhanced to be able to handle multiple dump files but not showing this
     to the application. The sync. pipe used for ipc should also be
     encapsulated in the 'wiretap' library.
    
     The following work must be considered:

     - 'wiretap' file access must support a configurable number of files
       of configurable size. The fact that there are multiple files must 
       not be visible outside 'wiretap'.

     - A synchronization mechanism between parent and child process for  
       multiple dump file access must be defined, preferably also encapsulated
       in the 'wiretap' lib.

     - All file access in the Ethereal application must be done by means
       of the 'wiretap' library, i.e. file descriptors, -handles should
       not be visible outside 'wiretap'. The filename is the only 
       reference directly visible to the application.

     - The dump file header for file type WTAP_FILE_PCAP must be extended
       for multiple dump file support.