Wireshark-dev: Re: [Wireshark-dev] map decoding problems
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Cristian Constantin <cristian.constantin@xxxxxxxxx>
Date: Wed, 28 Jan 2009 11:51:26 +0100
On Tue, Jan 27, 2009 at 09:33:26PM +0100, Anders Broman wrote:
> Hi,
> I have checked in a fix in revision 2731, formally I think the frame is
> wrongly Encoded as the tag [3] is missing but from comments in the code
> It looks like this is common, also from the comments in the asn1
> Description IMSI should be there as well, right?

cristian: than why is it marked as OPTIONAL??
(see below)

from the asn1 point of view, a SendRoutingInfoRes SEQUENCE w/o imsi is
correct. 
> 
> Best regards
> Anders
> 
> -----Ursprungligt meddelande-----
> Från: wireshark-dev-bounces@xxxxxxxxxxxxx
> [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] För Cristian Constantin
> Skickat: den 27 januari 2009 18:28
> Till: wireshark-dev@xxxxxxxxxxxxx
> Ämne: [Wireshark-dev] map decoding problems
> 
> 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,
cristian:                            ^^^^^^^^^^

>     -- 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.

bye now!
cristian
>     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
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
> 
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe