Wireshark-dev: Re: [Wireshark-dev] Looking for a developer to code an ANSI/ITU mixed decoding m
From: Jeff Morriss <[email protected]>
Date: Wed, 23 May 2012 17:16:45 -0400
Hi Jean,

Yes, 1.6.7 is from the "stable" branch. You'd need 1.7.1 or one of the development (buildbot) builds from the trunk (development version). You can get these from the "Development Release" or "Go Spelunking" sections on the main download page.

ps. feel free to send me sample captures offline (no need to clog the list with them)
Jean Gottschalk wrote:

this is great news. I am running 1.6.7 at the moment (which does not show the heuristic option). Is this sufficient, or do I need a higher version? Then I can test it with our traces and let you know what I see, and we can go from there.
To answer your question: we only need SCCP, however all of our traces 
are usually M3UA (or M2PA) and I can provide you with more sample traces 
if necessary.
There will definitely be a few beers from us when this works!

Best regards,

Jean Gottschalk

Telecom North America Inc

On Wed, May 23, 2012 at 8:48 AM, Jeff Morriss <[email protected] <mailto:[email protected]>> wrote:
    Jean Gottschalk wrote:


        we often run traces on our network with MTP3/M3UA packets that
        are mixed between ANSI and ITU in the same trace.

        In Wireshark, under the MTP3 decoder, we have to select whether
        to decode packets as ANSI or ITU, but not both at the same time.
        When selecting ANSI, all ITU packets are unreadable, and vice-versa.

        I'm assuming that Wireshark is somehow aware that a packet could
        not be properly decoded using 1 mode, and if so, it could be
        smart enough to try with the other mode to see if that works
        better, and that on a packet by packet basis.

        We are looking for a wireshark developer who could code such
        enhancement for us, for a fee, and contribute it to the
        wireshark project. It could be a called "Auto" mode and try all
        available flavors when any packet cannot be decoded.

        Please contact me directly if you are interested in doing this.

    Aww nuts... I already implemented (most of) this for free!  (Well,
    maybe I can get Anders to buy me a beer at Sharkfest for that ;-).)

    In the current trunk (or 1.7.1 if you want a (development) release),
    MTP3 has a preference called "Try to determine the MTP3 standard
    heuristically".  When enabled, MTP3 will try to automatically
    determine the MTP3 standard (ANSI, ITU, China, or Japan).

    But, this only works for MTP3 (not M3UA) and only when the payload
    is SCCP.  I tried it for M3UA but because the SCCP payload always
    starts at the same offset (because the M3UA message format does not
    depend on the MTP3 standard) the heuristics generally weren't
    effective.  (Admittedly I didn't have many ANSI M3UA captures to try
    it against; maybe if I had more I could come up with some ideas to
    improve it.)

    Do you need it to work for non-SCCP traffic too?