Wireshark-dev: Re: [Wireshark-dev] asn2wrs conformance TYPE_ATTR problem
From: Anders Broman <[email protected]>
Date: Tue, 03 May 2011 06:26:30 +0200
Risto Paasila skrev 2011-05-03 03:13:

I have an issue with asn2wrs.

In the ASN file, I have for example this definition:

    correlationID [0] IMPLICIT OCTET STRING (SIZE(14))

This by default gets compiled into the following code:

       { "correlationID", "ivrasn.correlationID",
         FT_BYTES, BASE_NONE, NULL, 0,
         "OCTET_STRING_SIZE_14", HFILL }},

And of course when the data is displayed, the string is in hex.

I have added an entry in the conformance file, and the debug output of
the compiler shows the following :

# Conformance values
File            Line Table           Key                  Value
./myasn.cnf      11 PDU             MessageType          {'export':
False, 'new': False, 'hidden': False, 'need_decl':False, 'reg': None}
./myasn.cnf     131 TYPE_ATTR       OCTET_STRING_SIZE_14 {'TYPE':
./myasn.cnf     128 TYPE_ATTR       correlationID        {'TYPE':
./myasn.cnf     127 TYPE_ATTR       errorCode            {'TYPE':
'FT_INT32', 'DISPLAY': 'BASE_DEC', 'STRINGS': 'VALS(errorCodeNames)'}
./myasn.cnf     126 TYPE_ATTR       operationCode        {'TYPE':
./myasn.cnf     130 TYPE_ATTR       uIScriptResult       {'TYPE':
./myasn.cnf     129 TYPE_ATTR       uIScriptSpecificInformation

However, it still does the default code generation, and the output is hex.

The generated code should be something like the following, so that the
dissector display is in ascii text:

       { "correlationID", "myasn.correlationID",
         "OCTET_STRING_SIZE_14", HFILL }},

So is there some other trick I may have missed?

Many thanks,
OCTET STRING means a sequence of octets opaque to the protocol nothing to do with STRING as in text.
an implementation of the protocol can chose to put text in an OCTET STRING.
For example UserID := OCTET STRING can contain 0xfffff or "MyID".
You can use #.TYPE_ATTR to change hf definition but formally you should probably put code in the conformance file to check if the OCTET STRING contains printable characters and then output it as a string. Unless theres is something in the protocol description saying that the OCTET STRING should contain text there is no
guarantee that it will.
Sent via:    Wireshark-dev mailing list<[email protected]>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
              mailto:[email protected]?subject=unsubscribe