Re: Question about asn2wrs

[Craig Jackson <cejackson51 () gmail com>]

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 <cusneud () 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.quantin () 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 <cejackson51 () 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.quantin () gmail com>
> > wrote:
> >
> > > Hi Craig,
> > >
> > > Le jeu. 8 nov. 2018 à 19:44, Craig Jackson <cejackson51 () 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-request () 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-request () 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-request () 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-request () 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-request () wireshark org?subject=unsubscribe