Wireshark-dev: Re: [Wireshark-dev] Fwd: [PATCH] FTBP: ContentsTypeParameterandRelationship are
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: "Graeme Lunt" <graeme.lunt@xxxxxxxxx>
Date: Fri, 22 Jun 2007 08:42:11 +0200
On 21/06/07, Anders Broman (AL/EAB) <anders.broman@xxxxxxxxxxxx> wrote:
Hi,


The BER dissectors will also be changed to use the "field based"(?),method (-X option) to produce less code.
Tomas has also tried to solve the problem with tagged types (-T option). It should also be easier
to produce a single dissector from multiple asn1 files (see GSM MAP).


The multiple asn1 files looks useful as I have often concatenated
modules together in a single dissector, with the consequent munging
IMPORTS etc.


I guess the only reason to change existing stuff is if it produces less code, make future updates less
difficult or makes the relation ships easier to understand. For the TELCO stuff at least there is
relativly frequent updates to the protocols which makes that atractive(MAP CAMEL INAP etc).


Well X.400 and X.500 don't change that often - but if it is smaller,
easier to understand and consistent with other asn2wrs generated
dissectors then that is reason enough to change.


The only argument I have regarding FTBP is that "FTBP" doesn't say much of what it does or belongs,
where as if it was part of X.420 that would be clearer.


Making ftbp an additional module in the x420 dissector seems a sensible move.


Unfortunatly I think that the dissector does not yet compile with unchanged asn1 code but that may change.


It does compile and link - but doesn't successfully dissect much of
x420 any more unfortunately. I will have a look over the weekend and
send in some more detailed reports.


But the question extends to X.509x is there a good reason to have them splitted or should it
All be in one X.509 dissector? I tested X.509 unchanged as well but there is still problems with asn2wrs
To sort out.

If you could try to recompile them (unchanged) with -X and -T option and report anny problems that'd
help things along.



Help with the OSI stuff would also be apriciated.

I am happy to help out - anything particular to look at?


A stumble stone is how to solve ROS encodings in a generic way.


What exactly is the problem?

I use my own separate ROS dissector (packet-ros) with registration
procedures which may lend itself to a asn2wrs generated table driven
approach.

Graeme