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@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] 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@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
