[Matthijs Melchior <mmelchior@xxxxxxxxx>]

Thomas,
   Including the ethereal-dev list again.

Thomas Steffen wrote:

> Hi Matthijs
>  
>
> > I have merged my packet-asn1.c with the 0.10.5 version.  A patch file
> > to include the sctp in version 0.10.5 packet-asn1.c is attached.
> >    
>
> Thank you very much, that is excellent. It works very well here: the 
> recognition by port number works, SCTP traffic is handled correctly now, 
> and I solved the problem with the multiple top PDUs by adding a CHOICE 
> type.
>
>  
OK!!, I will offer this patch for inclusion in ethereal.

> Now I would like to add a few representation of specific data fields 
> that we use. For example we use OCTET STRINGS in a few places that can 
> be interpreted as UNIX times, numbers etc. Is there an easy way to add 
> some concept of content representation?
>  
This is on my TODO list. I even know how to do this, conceptually.
If you have time to implement this, please do.
I envision the following:
   The plugin has a list of shared libraries it loads using dlopen etc.
   These libs are supposed to contain functions with names like
   'Print_TimeStamp', that are called when the ASN.1 type 'TimeStamp'
   is to be decoded and converted to a text string. The resulting text
   string is then added to the protocol tree. Currently I have no clear
   vision how the input interface for such functions should work and
   how we should enable to compile these things outside the ethereal
   source tree.

   A system like this enables you to easily build a nice dissector
   for any protocol using ASN.1 messages.  The ASN.1 spec is converted
   to a .tt file describing the overall structure and some C-code in
   a .so file gives special representations of octet-strings and
   integers, etc.

> Unless you have a better idea, I will probably hack snacc to output 
> different type codes for the special types (although in the end they are 
> just OCTET STRINGS), and I will add some case statements in 
> packet-asn1.c to handle these. Is there a way to make this more useful 
> to others? E.g. UNIX time might be interesting, and printing HEX data 
> backwards might also be.
>
>  
That is already part of the ASN.1 encoding, if your ASN.1 code is any good,
it will have different names for different things even though, eventually,
most things are octet strings or integers. Liberal use of ENUMERATED types
is also a good idea.

> We will also have some extra header in front of every ASN.1 packet. Is 
> there an easy way to handle that? There is a configuration option for a 
> header before the first packet, but that is not what we have here.
>
>  
The configuration option is used to synchronize a tcp capture that does
not start with the begining of a top-level PDU. Thereafter it is not needed
any more. PDU boundaries in the tcp stream are detected by decoding all
messages. My understanding of sctp is that there message boundaries are
preserverd, and thus finding the ASN.1 messages is easy.

I understand you have some control over the ASN.1 encoding...., why
do yo need a non-ASN.1 header. A SEQUENCE with the extra fields will
also be possible and no special header is nessecary...


> Yours,
>       Thomas
>  

--
Regards,
----------------------------------------------------------------  -o)
Matthijs Melchior                                       Maarssen  /\\
mmelchior@xxxxxxxxx                                  Netherlands _\_v
---------------------------------------------------------------- ----