Re: asn2wrs conformance TYPE_ATTR problem

[Anders Broman <a.broman () bredband net>]

Risto Paasila skrev 2011-05-03 03:13:
> Hi,
>
> 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:
>
>      {&hf_ivrasn_correlationID,
>        { "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':
> 'FT_STRING', 'DISPLAY': 'BASE_NONE'}
> ./myasn.cnf     128 TYPE_ATTR       correlationID        {'TYPE':
> 'FT_STRING', 'DISPLAY': 'BASE_NONE'}
> ./myasn.cnf     127 TYPE_ATTR       errorCode            {'TYPE':
> 'FT_INT32', 'DISPLAY': 'BASE_DEC', 'STRINGS': 'VALS(errorCodeNames)'}
> ./myasn.cnf     126 TYPE_ATTR       operationCode        {'TYPE':
> 'FT_INT32', 'DISPLAY': 'BASE_DEC', 'STRINGS':
> 'VALS(myOperationNames)'}
> ./myasn.cnf     130 TYPE_ATTR       uIScriptResult       {'TYPE':
> 'FT_STRING', 'DISPLAY': 'BASE_NONE'}
> ./myasn.cnf     129 TYPE_ATTR       uIScriptSpecificInformation
> {'TYPE': 'FT_STRING', 'DISPLAY': 'BASE_NONE'}
>
> 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:
>
>      {&hf_myasn_correlationID,
>        { "correlationID", "myasn.correlationID",
>          FT_STRING, BASE_NONE, NULL, 0,
>          "OCTET_STRING_SIZE_14", HFILL }},
>
> So is there some other trick I may have missed?
>
> Many thanks,
> Risto
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.
Regards
Andes
> ___________________________________________________________________________
> 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