Hi,
>> Looking at the trace I have
>> http://www.ethereal.com/lists/ethereal-users/200506/msg00263.html
>> it seems like the context defenition is set up with two items
>> one to ACSE
>> and the second one pointing out the CMIP protocol. Further
>> looking into the code of ACSE
>> it does keep track of the Presentation context and uses that
>> for certain SES PDU types(Data).
>
>The ACSE dissector seems to keep track of the ACSE OIDS not the
>presentation context OIDs (it doesn't have access to that information).
Yes.
What I was traying to say was that the second "PC" of Frame 89
"register_ber_oid_name("2.9.1.1.4","joint-iso-itu-t(2) ms(9) cmip(1) cmip-pci(1) abstractSyntax(4)");"
sort of corresonds to the "aso-context-name (2.9.0.0.2 "CMIP") of the ASCE part of the message.
>> It would be no problem to register the CMIP dissector with
>> two OID's if thet's the right thing to do and
>> let the PRES dissector keep track of the presentation
>> context's and call the apropriate OID dissector.
>It would do no harm to register the dissector on the AC, but I don't think
>it should be called.
>The AC indicates to the responder what sort protocol it is proposing (e.g.
>P1) whilst the PCs
>indicate how the individual operations will be encoded (e.g. ROS over RTS,
>RTS) - which tells you how to dissect them.
Looking at the current trace the only way to know if it's a PC or an AC is to analyse the OID - correct?
Frame 86
presentation-context-definition-list: 2 items
Item
Length: 1
presentation-context-identifier: 1
Length: 4
abstract-syntax-name: 2.2.1.0.1 (acse-as-id)
transfer-syntax-name-list: 1 item
Item
presentation-context-identifier: 3
Length: 4
abstract-syntax-name: 2.9.1.1.4 (joint-iso-itu-t(2) ms(9) cmip(1) cmip-pci(1) abstractSyntax(4))
>I do the following in my P1 dissector (which uses two abstract syntaxes in
>addition to ACSE):
>
> /* provide a nice name for the P1 AC */
> register_ber_oid_name("2.6.0.1.6", "id-ac-mts-transfer");
>
> /* we register RTSE with BER (which is used by ACSE) for the AS */
> if(handle = find_dissector("rtse")) {
> register_ber_oid_dissector_handle("2.6.0.2.12", handle, 0 ,
>"id-as-mta-rtse");
> register_ber_oid_dissector_handle("2.6.0.2.7", handle, 0 ,
>"id-as-mtse");
> }
???
I think the OID registration should be done by the dissector "owning" that OID e.g RTSE in this case.
Currently there might a problem here as we don't distiguish between PER and BER in the OID tables in
practice we don't have any example of a protocol beeing encoded in both PER and BER (yet).
>I think there should also be a registration/dispatch for ACSE on the acse
>presentation context (in the acse handoff),
>but I haven't investigated that yet.
Yes
>This can lead to multiple dissectors being registered on the same PC (OID) -
>so I now have
>register_rtse_oid_dissector() and register_ros_oid_dissector() to enable the
>dissection of each wrapper based on the same PC.
I'm not shure I follow you here, using the example abowe a way to do dissection would be:
Register resentation-context-identifier: 1 to the OID of ASCE
Register resentation-context-identifier: 3 to the OID 2.9.1.1.4
call oid dissector of PCI 1
Then for frame 94 call the dissector registerd for the OID of PCI 3.
which might not be formally correct but would work(?).
>> I'm not that familiar with the ITU-T X/ISO protocols so I
>> don't know if ther'd be any pitfalls with this method.
>It's a while since I was looking at this level, but I think dispatching of
>the presentation context is correct.
Graeme
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
