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 <[email protected]> wrote: > Hi Craig, > > Le jeu. 8 nov. 2018 à 19:44, Craig Jackson <[email protected]> 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 <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected] > ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
