["Anders Broman (AL/EAB)" <anders.broman@xxxxxxxxxxxx>]

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