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

["Anders Broman" <anders.broman@xxxxxxxxxxxx>]

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

But
>     -- IMSI must be present if SendRoutingInfoRes is not segmented.
I take that to mean that IMSI must be present but in the case of segmentation
IMSI is only in the first segment(?)
E.g message ASN1 syntactly correct but not according to spec?
But from WS point of view it does not mather, for a GSM system it would(?)
Regards
Anders

-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Cristian Constantin
Sent: den 28 januari 2009 11:51
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] map decoding problems

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