Le ven. 9 nov. 2018 à 16:27, Craig Jackson <cejackso...@gmail.com> a écrit :
> 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".
>
Per packet seems the right choice. See the s1ap_get_private_data() function
in packet-s1ap-template.c for an example.
Pascal.
> Craig
>
> On Thu, Nov 8, 2018 at 2:06 PM Pascal Quantin <pascal.quan...@gmail.com>
> wrote:
>
>> Hi Craig,
>>
>> Le jeu. 8 nov. 2018 à 19:44, Craig Jackson <cejackso...@gmail.com> 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@wireshark.org>
>> Archives: https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
