Wireshark mailing list archives
Re: Can asn2wrs handle BER & PER in same protocol?
From: "Kukosa, Tomas" <tomas.kukosa () siemens-enterprise com>
Date: Tue, 31 Aug 2010 08:18:56 +0200
Hi, yes, it is not possible to generate BER end PER code in one asn2wrs calling. But you can call it more times for one protocol. Using asn2wrs with -s option (Single file output from template) and generating packet-proto.c with one asn2wrs calling is just one simple way how to use it. You can call asn2wrs more times without -s option and then combine generated source fragments in the way which you need. Regards, Tomas -----Original Message----- From: wireshark-dev-bounces () wireshark org [mailto:wireshark-dev-bounces () wireshark org] On Behalf Of Anders Broman Sent: Tuesday, August 31, 2010 7:15 AM To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Can asn2wrs handle BER & PER in same protocol? Stephen Fisher skrev 2010-08-31 01:33:
I'm making my first serious attempt at working with an asn2wrs generated dissector, T.125. I noticed (when looking at RDP traffic) that only the Connect Initial/Reponse packets are decoded. The rest of the packets simply say "T.125 payload" because t125.cnf doesn't support them. The next packet in an RDP session after the MCS connection response is Erect Domain. DomainMCSPDU is commented out in t125.cnf presumably because it doesn't work yet. Although I barely know the difference in BER and PER, I'm guessing that the problem is being caused by the connect packets being BER encoded and the domain packets being PER. Is it possible to switch between them when using asn2wrs? Glancing at all of the other .cnf files seems to indicate that each protocol is one or the other.
I don't think asn2wrs can handle a mix but looking at T.125 it may be a bit more complicated: http://www.itu.int/itu-t/recommendations/index.aspx?ser=T 9 Encoding of MCSPDUs Each MCSPDU is transported as one TSDU across a TC belonging to an MCS connection. Connect MCSPDUs are unlimited in size. Domain MCSPDUs are limited in size by a parameter of the MCS domain. A standard ASN.1 data value encoding is used to transfer MCSPDUs between peer MCS providers. Encoding rules are selected as part of protocol version negotiation. This negotiation involves the exchange of a Connect-Initial and a Connect-Response MCSPDU over the initial TC. Three versions of this protocol are defined: - Version 1 - All MCSPDUs are described in clause 7 and use the Basic Encoding Rules of Recommendation X.690. - Version 2 - All MCSPDUs are described in clause 7. This version uses Basic Encoding Rules for connect MCSPDUs and the Packed Encoding Rules of Recommendation X.691 for all subsequent domain MCSPDUs. Specifically, the ALIGNED variant of BASIC-PER shall be applied to the ASN.1 type DomainMCSPDU. The bit string produced shall be conveyed as an integral number of octets. The leading bit of this string shall coincide with the most significant bit of the first octet. - Version 3 - Connect MCSPDUs are described in clause 7 and use Basic Encoding Rules for backward compatibility with Version 2. Extended Parameters and Domain MCSPDUs are described in clause 8 and use Packed Encoding Rules as specified for Version 2, above. Version 3 enabled nodes must be able to translate version 3 protocol into version 2 protocol for transmission over a connection to a node which has specified version 2 protocol in the domain parameters. This translation is described in 13.11. NOTE 1 - The Packed Encoding Rules yield more compact MCSPDU headers. NOTE 2 - Both BER and PER are self-delimiting, in the sense that they contain enough information to locate the end of each encoded MCSPDU. It might be argued that this makes the use of TSDUs unnecessary and that this protocol could be implemented over non-standard transport services that convey octet streams without preserving TSDU boundaries. However, such an approach is more vulnerable to implementation errors. If the boundary between MCSPDUs were ever lost, recovery would be difficult We may have to have something like packet-t125v1.c packet-t125v2.c packet-t125v3.c(..v1 beeing BER) and some logic to call one or the other e.g connection establishment trough ...v1.. then v2 or v3 as appropriate a heuristic approach might work to. Regards Anders
___________________________________________________________________________ Sent via: Wireshark-dev mailing list<wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Can asn2wrs handle BER & PER in same protocol? Stephen Fisher (Aug 30)
- Re: Can asn2wrs handle BER & PER in same protocol? Anders Broman (Aug 30)
- Re: Can asn2wrs handle BER & PER in same protocol? Kukosa, Tomas (Aug 30)
- Re: Can asn2wrs handle BER & PER in same protocol? Anders Broman (Aug 30)