Wireshark-bugs: [Wireshark-bugs] [Bug 3974] wrong decoding of gtp.target identification
Date: Wed, 9 Sep 2009 02:08:52 -0700 (PDT)

--- Comment #8 from Martin Zigo <[email protected]>  2009-09-09 02:08:50 PDT ---

from 25.413
>PLMN identity 	OCTET STRING (SIZE (3))	
- digits 0 to 9, encoded 0000 to 1001,
- 1111 used as filler digit, two digits per octet,
- bits 4 to 1 of octet n encoding digit 2n-1
- bits 8 to 5 of octet n encoding digit 2n

-The PLMN identity consists of 3 digits from MCC followed by either 
-a filler digit plus 2 digits from MNC (in case of 2 digit MNC) or 
-3 digits from MNC (in case of a 3 digit MNC).

5 digit PLMN id : 46000 for China Mobile - this "human readable format"
- after inserted filler : 460f00
- such string is on interface received nibble reversed : 64f000 - computer

6 digit PLMN id 310010 for Quantum Communications Group
- no filler
- nibble reversed : 130001

I think the problem is that in 29.060 is not correctly described Target
"7.7.37  Target Identification
The Target Identification information element contains the identification of a
target RNC. Octets 4-n shall be encoded as the Target RNC-ID part of the
‘Target ID’ parameter in 3GPP TS 25.413 [7]"

I think there should be written that Target RNC-ID shall be coded without
SEQUENCE tag => If you decode 64 f0 00 ... as SEQUENCE than the first octet is
considered as SEQUENCE tag (or some bits from this 1st octet) and than
interprets rest of bytes as Lai, RAC...

This is ambiguous description in 3GPP spec. 



In attached traces there is cominucation between Alcatel-Alcatel SGSN's and

Alcatel encode Target Identification as Target-ID (choice) what is not correct
but in wireshark it is decoded also as Target-ID 
octets: 8a 00 09 20 64 f0 70 a8  2a 00 01 9a
In next trace, Ericsson SGSN encoded it
octets: 8a 00 08 64 f0 70 a8  2a 00 01 9a

So the difference is in length and there is missing 20 after length (I thing
here is encoded choice)

Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.