Wireshark · Ethereal-dev: SV: [Ethereal-dev] ISO 8823 OSI Presentation Protocol

["Anders Broman" <a.broman@xxxxxxxxx>]

Hi,



>Here is a dump from my P1 associate:
>
>ISO 8823 OSI Presentation Protocol
>    PPDU Type: Connection request/confirm PDU (49)
>    Message Length: 122
>    Mode Selector
>        Mode selector: 160
>        Length:3
>        Integer
>    Sequence
>        Sequence: 162
>        Length:115
>        Presentation context definition list
>            Sequence
>                Presentation context identifier
>                    01
>                Abstract syntax name
>                    Value: 2.2.1.0.1 (joint-iso-ccitt.2.1.0.1) (ACSE)
>                Transfer syntax names
>                    Value: 2.1.1 (joint-iso-ccitt.1.1)
>            Sequence
>                Presentation context identifier
>                    03
>                Abstract syntax name
>                    Value: 2.6.0.2.12 (joint-iso-ccitt.6.0.2.12)(
mta-bind-unbind-rtse-abstract-syntax(12))
>                Transfer syntax names
>                    Value: 2.1.1 (joint-iso-ccitt.1.1)
>            Sequence
>                Presentation context identifier
>                    05
>                Abstract syntax name
>                    Value: 2.6.0.2.7 (joint-iso-ccitt.6.0.2.7)
message-transfer-abstract-syntax(7)
>                Transfer syntax names
>                    Value: 2.1.1 (joint-iso-ccitt.1.1)
>        User data
>            Fully encoded data 
>                Sequence
>                    Presentation context identifier
>                        01
>                    Single ASN.1 type
>                        User data
>ACSE
>    aarq
>        aSO-context-name: 2.6.0.1.6 (mts-transfer(6))
>        user-information: 1 item
>
>
>There are two PC (2.6.0.2.12 and 2.6.0.2.7) (in addition ACSE) that map to
>the one AC (2.6.0.1.6). 
>X.400 P7 and P3 protocols have 4 PCs in addition to ACSE. The dissectors
>must be able to handle this.
>So dissection must be based on PC (the AC does not aid dissection). 
>
>Note the dump above also shows that the ACSE dissector should register
>itself is ACSE syntax (2.2.1.0.1) dissector.
>The presentation dissector should then use the PCI in the "User data" (1)
>to
>lookup the ACSE AS oid (2.2.1.0.1) and then call call_ber_oid_callback().
>This way the presentation dissector does not explicitly know about the acse
>dissector. 
>I don't think you are ever forced to use ACSE in an application protocol?
>
>> Looking at the current trace the only way to know if it's a 
>> PC or an AC is to analyse the OID - correct?

>They are both presentation contexts. 
>The AC comes from ACSE (the "aSO-context-name") in my dump above.

Sorry a misunderstanding I thought you were referring to the two OID's
Used by CMIP as one being AC and the other PC.

>> I think the OID registration should be done by the dissector 
>> "owning" that OID 

>I agree.

>> e.g RTSE in this case.

>But in this case the OID is "owned" by X.400 (P1) and hence why the
>registration is done here.
>There are other PCs that use RTSE - depending on the application. RTSE
>could
>register itself on all of  
>them that it knows about but I think it is clearer to put it in the
>ultimate
>application dissector handoff.



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

>The issue here is that ACSE, RTSE and ROS will all use the same PC (OID) to

>call sub-dissectors for User Data (EXTERNALs) they find. 
>This can't be handled with register_ber_oid_dissector() as each dissector
>registration will override the last. 
>So each service element needs its own hash table (though ACSE can probably
>use the BER hash table).
>
>So for the P1 PC (2.6.0.2.12) I would have something like in the X411
>handoff:

>/* the ACSE dissector has self-registered and uses the BER callback list
>like : */
>/* register_ber_oid_dissector("2.2.1.0.1", dissect_acse, proto_acse,
>"id-as-acse"); */


>register_ACSE_oid_dissector("2.6.0.2.12", dissect_rtse, proto_rtse,
>"id-as-mta-rtse");
>register_RTSE_oid_dissector("2.6.0.2.12", dissect_ros, proto_ros,
>"id-as-mta-rtse");
>register_ROS_oid_dissector("2.6.0.2.12", dissect_x411, proto_x411,
>"id-as-mta-rtse");
(mta-bind-unbind-rtse-abstract-syntax(12))
>This way each service element can dispatch using the same PC.

>And then if the application protocol just uses ROS (i.e. no RTSE) (e.g.
>CMIP) you can do:

>register_ACSE_oid_dissector("2.9.1.1.4", dissect_ros, proto_rtse,
>"id-as-cmip");
>register_ROS_oid_dissector("2.9.1.1.4", dissect_cmip, proto_cmip,
>"id-as-cmip");

>Is this making any sense?
Sort of, I have made a change to the PRES dissector to store the PC and use
The OID of the PC to call the dissector of the data, thus bypassing ACSE for
PC 03 and 05 in the example above.
For PC 0 ACSE will be called which in turn will call 2.6.0.1.6
(mts-transfer(6)). Will that take care of the problem? I'll check the code
in and you can gave a look. If it does not work we can change it.

Brg
Anders




_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev