[Craig Jackson <cejackson51@xxxxxxxxx>]

I think I figured out my path for this particular case. I can remember the current attribute set, and then use custom functions for the display of AttributeElement/attributeType and AttributeElement/attributeValue/numeric. (I'll handle the other choice later.)

Now to choose where to store the current attribute set. It could either go into a record associated with the packet, or a record associated with the conversation. The "packet" in this case will be a reassembled TCP stream. I'm not sure what per-packet storage means in that case. I guess it's time for "Use the Source, Luke".

Craig

On Thu, Nov 8, 2018 at 2:06 PM Pascal Quantin <pascal.quantin@xxxxxxxxx> wrote:

Hi Craig,

Le jeu. 8 nov. 2018 à 19:44, Craig Jackson <cejackson51@xxxxxxxxx> a écrit :

I'm working on a decoder for the NISO Z39.50 protocol. This is an ASN.1/BER protocol used in the library automation community.

There some things I'm having trouble figuring out how to configure, and there are also a bunch of things which have never been documented in asn2wrs. I'm wondering if one or more of the undocumented things could help me.

Here's a problematic type definition:

   AttributeElement  ::=  SEQUENCE{

      attributeSet    [1]       IMPLICIT AttributeSetId OPTIONAL,

      attributeType   [120]  IMPLICIT INTEGER,

      attributeValue      CHOICE{

                     numeric    [121]   IMPLICIT INTEGER,

        complex    [224] IMPLICIT SEQUENCE{ 

                          list     [1] IMPLICIT SEQUENCE OF StringOrNumeric,

                   semanticAction  [2] IMPLICIT SEQUENCE OF INTEGER OPTIONAL}}}

The issue is that the "attributeType" values are actually enumerations chosen based on the value of "attributeSet". I see how I can supply a fixed set of strings using FIELD_ATTR (poorly documented), but I can't figure out how to get control so I could specify different sets of strings. (This might be done by specifying alternate hf values, perhaps.)

I think I could hard-code the type specifying my own choice array, but I'm wondering if there's a better way.

Several ASN.1 dissectors have fields with a dissection depending on another field. See for example s1ap.cnf file and the code for HandoverType and Source-ToTarget-TransparentContainer fields.

So you could store the attributeSet value in the packet (using the p_add_proto_data() function) and retrieve it when decoding the attributeType value (thanks to the p_get_proto_data() function) and select the right value_string (by selecting the relevant hg value, taht could be manually defined in your template file - like what is done in packet-s1ap-template.c). the PER dissector allows you to define a hf value to -1 to avoid getting the item added to the tree automatically and retrieving the field so as to manually select the right hf to use. I'm not playing with BER but presumably either is it also supported, or could probably be added.

I agree with you that asn2wrs is not well documented. But ther are plenty of ASN.1 based dissectors that you can look at to take ideas or check how things were done (this is how I learned myself). Looking at the python script itself also helps ;)

Best regards,

Pascal.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe