Wireshark-dev: Re: [Wireshark-dev] Fwd: [PATCH] FTBP:ContentsTypeParameterandRelationship are O
Hi,
> Help with the OSI stuff would also be apriciated.
>I am happy to help out - anything particular to look at?
EXTERNAL is used in some of the dissectors ACSE FTAM etc
Now coded as EXTRNALt that should be replaced as packet BER
Should handle EXTERNAL now. The code in packet-ber.c for
EXTERNAL isn't quite finished though, for indirect regerence
A call back must be done to perform the same job as ACSE does today.
Starting with the dissectors importing EXTERNALt from ACSE.
Then all OSI dissectors should be regenerated with -X and -T option
Some of them have workarounds for tagged types which shouldn't be needed
Or asn2wrs fixed so it isn't.
Regards
Anders
-----Ursprungligt meddelande-----
Från: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] För Graeme Lunt
Skickat: den 22 juni 2007 08:42
Till: Developer support list for Wireshark
Ämne: Re: [Wireshark-dev] Fwd: [PATCH]
FTBP:ContentsTypeParameterandRelationship are OPTIONAL
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
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
