Wireshark · Wireshark-dev: [Wireshark-dev] map decoding problems

[Cristian Constantin <cristian.constantin@xxxxxxxxx>]

hi!

I have seen some problems in wireshark when decoding the response of an
SendRoutingInfo (locationInfoRetrievalContext-v3). the asn1 def of this
is:

SendRoutingInfoRes ::= [3] SEQUENCE {
    imsi            [9] IMSI        OPTIONAL,
    -- IMSI must be present if SendRoutingInfoRes is not segmented.
    -- If the TC-Result-NL segmentation option is taken the IMSI must be
    -- present in one segmented transmission of SendRoutingInfoRes.
    extendedRoutingInfo ExtendedRoutingInfo OPTIONAL,
    cug-CheckInfo   [3] CUG-CheckInfo   OPTIONAL,
    cugSubscriptionFlag [6] NULL        OPTIONAL,
    subscriberInfo  [7] SubscriberInfo  OPTIONAL,
    ss-List     [1] SS-List OPTIONAL,
    basicService    [5] Ext-BasicServiceCode    OPTIONAL,
    forwardingInterrogationRequired [4] NULL        OPTIONAL,
    vmsc-Address    [2] ISDN-AddressString  OPTIONAL,
    extensionContainer  [0] ExtensionContainer  OPTIONAL,
    ... ,
    naea-PreferredCI    [10] NAEA-PreferredCI   OPTIONAL,
    -- naea-PreferredCI is included at the discretion of the HLR operator.
    ccbs-Indicators [11] CCBS-Indicators    OPTIONAL,
    msisdn      [12] ISDN-AddressString OPTIONAL,
    numberPortabilityStatus [13] NumberPortabilityStatus    OPTIONAL,
    istAlertTimer   [14] IST-AlertTimerValue    OPTIONAL,
    supportedCamelPhasesInVMSC  [15]    SupportedCamelPhases    OPTIONAL,
    offeredCamel4CSIsInVMSC [16] OfferedCamel4CSIs  OPTIONAL,
    routingInfo2    [17] RoutingInfo    OPTIONAL,
    ss-List2        [18] SS-List    OPTIONAL,
    basicService2   [19] Ext-BasicServiceCode   OPTIONAL,
    allowedServices [20] AllowedServices    OPTIONAL,
    unavailabilityCause [21] UnavailabilityCause    OPTIONAL,
    releaseResourcesSupported   [22] NULL       OPTIONAL,
    gsm-BearerCapability    [23] ExternalSignalInfo OPTIONAL
    }

interestingly enough, extendedRoutingInfo is NOT tagged within the
SEQUENCE.

now, wireshark(1.0.5)/debian linux decodes the SendRoutingInfoRes/
extendedRoutingInfo/routingInfo/roamingNumber as:

                00.. .... = Class: UNIVERSAL (0)
                ..1. .... = P/C: Constructed Encoding
                ...1 0000 = Tag: SEQUENCE (16)
                Length: 9
                00.. .... = Class: UNIVERSAL (0)
                ..0. .... = P/C: Primitive Encoding
                ...0 0100 = Tag: OCTET STRING (4)
                Length: 7
                imsi: A8241021324344
                TBCD digits: 8:420112233444

(which is obviously wrong since the imsi within the sequence has the tag
0, but not an UNIVERSAL one, right?)

whereas ethereal (0.10.12) / windows recognizes it properly (!!):

        00.. .... = Class: Universal (0)
        ..1. .... = P/C: Constructed Encoding
        ...1 0000 = Tag: SEQUENCE, SEQUENCE OF (16)
        Length: 14
        returnResult_result: 02011630090407A8241021324344
            00.. .... = Class: Universal (0)
            ..0. .... = P/C: Primitive Encoding
            ...0 0010 = Tag: INTEGER (2)
            Length: 1
            invokeCmd: sendRoutingInfo (22)
            extendedRoutingInfo: routingInfo (0)
                routingInfo: roamingNumber (0)
                    00.. .... = Class: Universal (0)
                    ..0. .... = P/C: Primitive Encoding
                    ...0 0100 = Tag: OCTET STRING (4)
                    Length: 7
                    roamingNumber: A8241021324344
                    1... .... = Extension: No Extension
                    .010 .... = Nature of number: National Significant Number (0
x02)
                    .... 1000 = Number plan: National Numbering (0x08)
                    ISDN Address digits: 4201122334

what is wrong with the new version of wireshark?

bye now!
cristian