Wireshark-dev: Re: [Wireshark-dev] How do I call the next dissector ...
From: Richard Sharpe <[email protected]>
Date: Sat, 31 May 2014 14:01:28 -0700
On Thu, May 29, 2014 at 10:24 PM, Richard Sharpe
<[email protected]> wrote:
> Hi folks,
>
> to fix the LDAP SASL integrity only stuff, I think I have to do
> something like the following:
>
> --- a/asn1/spnego/packet-spnego-template.c
> +++ b/asn1/spnego/packet-spnego-template.c
> @@ -1026,13 +1026,30 @@ dissect_spnego_krb5_cfx_wrap_base(tvbuff_t *tvb, int off
>
>         if (pinfo->gssapi_data_encrypted) {
>                 checksum_size = 44 + ec;
> +
> +               proto_tree_add_item(tree, hf_spnego_krb5_sgn_cksum, tvb, offset,
> +                                   checksum_size, ENC_NA);
> +               offset += checksum_size;
> +
>         } else {
> -               checksum_size = 12;
> -       }
> +               tvbuff_t *inner_token;
> +               int inner_token_len = 0;
> +               heur_dtbl_entry_t *hdtbl_entry;
>
> -       proto_tree_add_item(tree, hf_spnego_krb5_sgn_cksum, tvb, offset,
> -                           checksum_size, ENC_NA);
> -       offset += checksum_size;
> +               checksum_size = ec;
> +
> +               inner_token_len = tvb_reported_length_remaining(tvb, offset) -
> +                                       ec;
> +               inner_token = tvb_new_subset(tvb, offset, inner_token_len,
> +                               tvb_reported_length(tvb));
> +
> +               call_some_dissector(inner_token, pinfo, tree, FALSE);
> +
> +               offset += inner_token_len;
> +
> +               proto_tree_add_item(tree, hf_spnego_krb5_sgn_cksum, tvb, offset,
> +                                   checksum_size, ENC_NA);
> +       }
>
>         if(pinfo->decrypt_gssapi_tvb){
>                 /* if the caller did not provide a tvb, then we just use
>
> So, how do I call the next dissector?
>
> The only clue I have so far is that the inner token looks like it is
> ASN.1 encoded because it starts with 0x3073...
>
> Any clues out there?

OK, in looking at the data that is incorrectly dissected, it starts with this:

   3073020104636e041064633d

It looks like a BER encoded SEQUENCE or SEQUENCE off 0x73 bytes which
is 115 bytes, which looks like the payload ...

So, it looks like I need to call dissect_ber_SOMETHING ... maybe
dissect_ber_sequence_of ...

Does that help anyone provide a suggestion?

-- 
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)