Darien,
That is indeed the conclusion I had come to. I'll see if I can incorporate
that detail in the documentation somewhere.
Craig
On Fri, Nov 9, 2018 at 1:34 PM Darien Spencer <cusn...@mail.com> wrote:
> Just wanted to add my 2 cents.
> I believe when dealing with reassembled TCP packets the packet info you
> are accessing is that of the latest segment, since it's the one the payload
> will be shown in it's tree in Wireshark.
> If you need this information available between different ASN.1 fields of
> the same packet, the packet info should be the right place to store it.
> If you need this information available between different reassembled
> payload, you should use the conversation.
>
> -- Darien
>
> *Sent:* Friday, November 09, 2018 at 5:37 PM
> *From:* "Pascal Quantin" <pascal.quan...@gmail.com>
> *To:* "Developer support list for Wireshark" <wireshark-dev@wireshark.org>
> *Subject:* Re: [Wireshark-dev] Question about asn2wrs
>
> 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 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
