Contents
If the -root command-line option is not specified, then the last (or only) module in this right-most ASN.1 input file is taken as the central ASN.1 module in the specification. So, only this last module's PDUs are listed when -listPduId is specified; ASN.1 definitions from other modules are only read if they are referenced from within this last module.
Additionally, only types that are not used to define other types are considered PDUs by ASN-1Step. If you would like to force a referenced type to be considered a PDU, apply the OSS.PDU directive to it. For example, type A below is used to define type B; thus, A is not considered a PDU. However to force ASN-1Step to consider A as a PDU, you can apply the OSS.PDU directive to it:
--<OSS.PDU ModuleName.A>-- ModuleName DEFINITIONS ::= BEGIN B ::= A A :: = INTEGER a-value A ::= INTEGER END
Also note that sometimes, due to name conflicts, the actual type name could be altered/mangled (e.g., prepended with the module name).
Value references of basic built-in types (e.g., INTEGER, IA5String, REAL, etc.) are not generated in the value reference table. Only value references that are based on user-defined types are there. You can convert value references of basic built-in types to those of user-defined types so they are included in the generated table. For example, if you change:
anInt INTEGER ::= 40
to
MyInt ::= INTEGER anInt MyInt ::= 40
the anInt value reference will be stored in the value reference table.
Also, if the desired value reference is not in the last input module, then specify the -root option to make sure it is included. For example:
asn1step input1.asn input2.asn input3.asn -root -valueRefTable
You must also specify the -root option when encoding the desired value reference.
Also note that sometimes, due to name conflicts, the actual value reference name could be altered/mangled (e.g., prepended with the module name).
Yes. Any command-line keyword can be abbreviated as much as you like, so long as the resulting abbreviation is unique. If the resulting abbreviation is not unique, then ASN-1Step will list all the keywords that the abbreviation matches so that you can choose a unique abbreviation.
You can try specifying the -noUniquePDU command-line option when ASN.1-compiling your syntax. Additionally, note that these messages are only relevant if you plan to encode/decode your specification using BER or DER.
You can add the AUTOMATIC TAGS keywords to your module definition statement to instruct ASN-1Step to automatically add the needed tags for component differentiation.
The following excerpt illustrates the use of the AUTOMATIC TAGS keywords:
ModuleName DEFINITIONS AUTOMATIC TAGS ::= BEGIN ChoiceA ::= CHOICE { a INTEGER, b INTEGER, c INTEGER } END
Note how the CHOICE elements do not have any context-sensitive tags applied to them. ASN-1Step provides all necessary tags when the AUTOMATIC TAGS keywords are present.
Yes: specify multiple -encodeValue options on the same command line. However, if you choose to specify multiple options, refrain from specifying any output filenames. INstead, the output filename will be derived from the value reference that is encoded. Also specify the encoding rules to be used with the -ber, -der, -per, -oer, -coer, and -uper options. For example, the command
asn1step mySyntax2.asn -ber -per -encodeValue myPdu1 -encodeValue myPdu2
will cause the myPdu1 and myPdu2 value references to be both encoded once using BER and once using PER. Four output files will be produced in the above example:
No. However, OSS Nokalva has a separate OSSTLV utility (included with the OSS ASN.1 Tools) that does exactly this. Contact info@oss.com for more information about obtaining OSSTLV.
No. As PER has no tag information coded for it, it is usually not possible to decode it without knowing which ASN.1 specification it corresponds to.
Yes. Apply the --<ASN1.HugeInteger>-- directive to the INTEGER type that will take on large values. For example:
--<ASN1.HugeInteger LengthModule.LengthData.lengthOfSolarSystem>-- LengthModule DEFINITIONS ::= BEGIN LengthData ::= SEQUENCE { lengthOfSolarSystem INTEGER, units ENUMERATED {mm(0), cm(1), m(2), km(3), lightyears(4)} DEFAULT mm } END
Yes. There is no need to modify your ASN.1 source in order to specify values using value notation. Simply add value notation to a separate file and specify it later on the command line. However, you will need to IMPORT the modules containing the types for which you are writing value notation into this last file. For example:
originalASN1.asn: D DEFINITIONS ::= BEGIN I ::= INTEGER B ::= BOOLEAN END myvalues.asn: F DEFINITIONS ::= BEGIN IMPORTS I FROM D; q I ::= 133 r I ::= -27 END
Then, invoke ASN-1Step as follows:
asn1step originalASN1.asn myvalues.asn -test
You can also add values to a separate file without enclosing them in an ASN.1 module. For example, use the originalASN1.asn file above and the following:
myvalues.txt: q I ::= 133 r I ::= -27
Then invoke ASN-1Step as follows:
asn1step originalASN1.asn -encodeValue myvalues.txt -ber
First, the 133 value is encoded using the Basic Encoding Rules (BER) and placed at the beginning of the output file. Then, the -27 value is encoded using BER and the result is appended to the end of the output file as a concatenated PDU. The output file will be named myValues.txt.ber by default. Note, the values are specified in the form <valueName> <PduTypeName> ::= <value_notation>. So the PDU identifier can be determined from the value.
You can omit the start of value assignments and add values in the form <value_notation> as follows:
myvalues.txt: 133 -27
Then invoke ASN-1Step as follows:
asn1step originalASN1.asn -encodeValue 1,myvalues.txt -ber
You must specify the PDU identifier, 1, obtained by specifying -listPduIdentifiers, in the -encodeValue option. The output file will be named myValues.txt.ber and contain two concatenated BER encoded values of INTEGER values 133 and -27.
Yes. See -xsl for details.
Yes. See -dtd for details.
Yes. You can specify an encoding rules option along with the -decodePdu option to convert an input encoding into another format. For example, to convert a BER encoding contained in myValue.ber to XER, type:
asn1step input.asn -decodePdu 0 myValue.ber -xer
The output file is named myValue.ber.xer by default. Since the -decodePdu 0 option is implied by default, you can omit it, except when converting from PER. In that case, you must specify the PDU type corresponding to the encoding as an argument to -decodePdu.
Yes. Specify the -asn1Value option along with the -decodePdu option to convert an input encoding into its ASN.1 value notation equivalent. For example, to convert a BER encoding contained in myValue.ber to ASN.1 value notation, type:
asn1step input.asn -decodePdu 0 myValue.ber -asn1Value
The output file will be named myValue.ber.txt by default. Since the -decodePdu 0 option is implied by default, you can omit it, except when converting from PER. In that case, you must specify the PDU type corresponding to the encoding as an argument to -decodePdu.
Specify the -listPduIdentifiers true option to print a subset of all PDU identifiers for unreferenced PDU types and some types with PDU directives. In this case, PDU types that are referenced in information objects or types with contents constraints will not be printed. Use -listPduIdentifiers without the argument to view the full list of PDU identifiers.
This documentation applies to release 8.2 and later of ASN-1Step®. For earlier versions, consult the PDF manual available in your product installation.
Copyright © 2024 OSS Nokalva, Inc. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means electronic, mechanical, photocopying, recording or otherwise, without the prior permission of OSS Nokalva, Inc.
Every distributed copy of ASN-1Step is associated with a specific license and related unique license number. That license determines, among other things, what functions of ASN-1Step are available to you.