Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 3974] wrong decoding of gtp.target identification

Date: Wed, 9 Sep 2009 02:08:52 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3974





--- Comment #8 from Martin Zigo <martin.zigo@xxxxxxxxx>  2009-09-09 02:08:50 PDT ---
Hi,

from 25.413
LAI                             
>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).

e.g 
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
format

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

regards

Martin

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

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.