Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 33048: /trunk/ /trunk/epan/dissector
From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Tue, 29 Jun 2010 12:20:52 -0400
Hi Graeme,

Honestly I haven't a clue--that's why I punted and just reported the problem.

It does decode several of the capture files I have correctly, so I'd say check it in.

Regards,
-Jeff

Graeme Lunt wrote:
Jeff,.

Like the issue that the patch highlighted with Stig's presentation example, an IMPLICITly OCTET STRING looks similar to a EXPLICITly tagged ANY - until you start looking at the constructed bit.

The ansi_tcap dissector is decoding an OCTET STRING - when I don't think it needs to.

Attached is the fix I think you require to ansi_tcap - but it might break other things - I don't know much about the protocol. Certainly it makes your example capture file work and simplifies the conformance file. If it breaks other things, let me know and I'll go back to the drawing board.

Graeme

On 8 June 2010 15:20, Jeff Morriss <jeff.morriss.ws <http://jeff.morriss.ws>@gmail.com <http://gmail.com>> wrote:

    gal@xxxxxxxxxxxxx <mailto:gal@xxxxxxxxxxxxx> wrote:
     >
    http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=33048
    <http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=33048>
     >
     > User: gal
     > Date: 2010/06/02 07:43 AM
     >
     > Log:
     >  Bug 3597 - implicit octet string that is constructed causes
    PRES/FTAM dissect failure
     >
     >  Introduced some state to remember last dissected Tag/Length so
    that they can be recalled if an IMPLICIT tag is encountered and
    stripped. This allows its to be determined if the value has a
    constructed value - and so can be reassembled.
     >
     >  In this case, it is a IMPLICIT constructed OCTET STRING at the
    presentation layer.
     >
     >  Many thanks to Fred Gruman for identifying - and apologies for
    the delay in commiting.

    This breaks the ANSI TCAP dissector.  It now complains "BER Error:
    OctetString expected but class:CONTEXT(2) primitive tag:21 was
    unexpected" and then the packet is marked as unreassembled.

    I'm afraid I don't understand this stuff well enough to attempt a fix.
    Can someone take a look?  A sample capture that shows the problem can be
    found on the SampleCaptures page:

    http://wiki.wireshark.org/SampleCaptures?action=AttachFile&do=view&target=ansi_tcap_over_itu_sccp_over_mtp3_over_mtp2.pcap