Wireshark · Wireshark-dev: Re: [Wireshark-dev] asn2wrs conformance TYPE_ATTR problem

[Risto Paasila <risto@xxxxxxxxxxxxxxxx>]

> Subject: Re: [Wireshark-dev] asn2wrs conformance TYPE_ATTR problem
>
>>> Did I miss something? a arbitrary long field of binary data can not be FT_STRING.
>>> /Anders
>>
>>The field that I initially had in question was:
>>
>>  correlationID [0] IMPLICIT OCTET STRING (SIZE(14))
>>
>>So it should be maximum 14 octets. Is that still arbitrary?
> No, as the octet string has size constraints but still the hf field constructed for an OCTET STRING
> Should be FT_BYTES as its Binary data, if a implementation chooses to put a string in that field you
> Can override that by defining a .#ATTRIB (I think) but be aware that some other manufacturer/protocol implementer my put binary data in there and then the dissection would be wrong. Unless it's specified that even though the
> Asn1 spec is OCTET STRING a utf8 string should be put in that field.
> Regards
> Anders

You have given hope :-)
This is from my conformance file, but as I originally said, those are
taken and displayed in the debug output,
so I am wondering why it doesn't put them into the generated HF code:

#.TYPE_ATTR
operationCode TYPE = FT_INT32 DISPLAY = BASE_DEC STRINGS =
VALS(myOperationNames)
errorCode TYPE = FT_INT32 DISPLAY = BASE_DEC STRINGS = VALS(errorCodeNames)
correlationID TYPE = FT_STRING DISPLAY = BASE_NONE
uIScriptSpecificInformation TYPE = FT_STRING DISPLAY = BASE_NONE
uIScriptResult TYPE = FT_STRING DISPLAY = BASE_NONE
OCTET_STRING_SIZE_14 TYPE = FT_STRING DISPLAY = BASE_NONE
#.END


Regards
Risto