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