Project

General

Profile

Actions

Bug #4025

closed

gsm48_decode_bcd_number2(): incorrect output buffer truncation

Added by fixeria almost 5 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
libosmogsm
Target version:
-
Start date:
05/25/2019
Due date:
% Done:

100%

Spec Reference:

Description

For some reason, OsmoMSC truncates 15-digit long MSISDNs to 14 digits.

How to reproduce?

  • Create a subscriber with a 15-digit long MSISDN (e.g. 123456789012345)
  • Perform Location Update
DRR DEBUG ran_peer.c:596 ran_peer(GERAN-A:RI-SSN_PC:PC-0-23-3:SSN-BSSAP)[0x18c5680]{READY}: Received Event RAN_PEER_EV_MSG_UP_CO_INITIAL
DRLL DEBUG msc_a.c:1165 msc_a(unknown:GERAN-A-4:NONE)[0x18dfb30]{MSC_A_ST_VALIDATE_L3}: Dispatching 04.08 message: MM GSM48_MT_MM_LOC_UPD_REQUEST
DMM DEBUG gsm_04_08.c:337 msc_a(IMSI-262073993158656:GERAN-A-4:LU)[0x18dfb30]{MSC_A_ST_VALIDATE_L3}: LOCATION UPDATING REQUEST: MI=IMSI-262073993158656 LU-type=NORMAL
DMM DEBUG gsm_04_08.c:380 msc_a(IMSI-262073993158656:GERAN-A-4:LU)[0x18dfb30]{MSC_A_ST_VALIDATE_L3}: USIM: old LAI: 262-07-0
DVLR DEBUG fsm.c:423 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: Allocated
DVLR DEBUG fsm.c:453 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: is child of msc_a(IMSI-262073993158656:GERAN-A-4:LU)[0x18dfb30]
DVLR DEBUG vlr_lu_fsm.c:1525 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: rev=GSM net=GERAN (no Auth)
DVLR DEBUG vlr_lu_fsm.c:1531 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: Received Event VLR_ULA_E_UPDATE_LA
DVLR DEBUG vlr.c:435 set IMSI on subscriber; IMSI=262073993158656 id=262073993158656
DVLR INFO vlr.c:386 New subscr, IMSI: 262073993158656
DVLR DEBUG vlr_lu_fsm.c:933 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: vlr_loc_upd_node1_pre()
DVLR DEBUG vlr_lu_fsm.c:910 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: vlr_loc_upd_node1()
DVLR DEBUG vlr_lu_fsm.c:864 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: vlr_loc_upd_post_auth()
DVLR DEBUG vlr_lu_fsm.c:831 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: vlr_loc_upd_post_ciph()
DVLR DEBUG vlr_lu_fsm.c:792 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: vlr_loc_upd_node_4()
DVLR DEBUG vlr_lu_fsm.c:801 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: State change to VLR_ULA_S_WAIT_HLR_UPD (T0, 30s)
DVLR DEBUG fsm.c:423 upd_hlr_vlr_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e1c20]{UPD_HLR_VLR_S_INIT}: Allocated
DVLR DEBUG fsm.c:453 upd_hlr_vlr_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e1c20]{UPD_HLR_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]
DVLR DEBUG vlr_lu_fsm.c:176 upd_hlr_vlr_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e1c20]{UPD_HLR_VLR_S_INIT}: Received Event UPD_HLR_VLR_E_START
DVLR DEBUG vlr_lu_fsm.c:87 upd_hlr_vlr_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e1c20]{UPD_HLR_VLR_S_INIT}: State change to UPD_HLR_VLR_S_WAIT_FOR_DATA (T0, 30s)

DVLR DEBUG vlr.c:778 IMSI:262073993158656 has MSISDN:12345678901234

DVLR NOTICE gsm_04_08.c:1364 SUBSCR(IMSI-262073993158656:MSISDN-12345678901234) VLR: update for IMSI=262073993158656 (MSISDN=12345678901234)
DVLR DEBUG vlr.c:879 vlr_lu_fsm(IMSI-262073993158656:MSISDN-12345678901234:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_HLR_LU_RES
  • Perform USSD: *#100#
OsmocomBB# service 1 *#100#
% (MS 1)
% Service response: Your extension is 123456789012345

What's happening?

As can be seen, the USSD response has the correct 15-digit long MSISDN, while the logs of OsmoMSC indicate a truncated one. I also checked GSUP message flow in Wireshark:

GSUP InsertSubscriberData Request, IMSI: 262073993158656, MSISDN: 123456789012345
    Message Type: InsertSubscriberData Request (16)
    IE: IMSI, 262073993158656
        Information Element Identifier: IMSI (1)
        Information Element Length: 8
        IMSI: 262073993158656
            Mobile Country Code (MCC): Germany (262)
            Mobile Network Code (MNC): Telefonica Germany GmbH & Co. oHG (07)
    IE: MSISDN, 123456789012345
        Information Element Identifier: MSISDN (8)
        Information Element Length: 9
        E.164 number (MSISDN): 123456789012345
            Country Code: Americas (1)
    IE: CN Domain
        Information Element Identifier: CN Domain (40)
        Information Element Length: 1
        CN Domain Indicator: CS (2)

Just to be sure, I had a closer look at the encoded OSMO_GSUP_MSISDN_IE, and parsed in myself manually:

RAW payload: 08090821436587092143f5

08 - T: OSMO_GSUP_MSISDN_IE
09 - L: 0x09 == 9 octets
        08 - L: 0x08 == 8 octets
                21436587092143f5 - V: Encoded MSISDN

MSISDN seems to be encoded correctly, so most likely OsmoHLR is not the one to blame. Most likely, the problem is somewhere in OsmoMSC.


Files

gsup_lu_msisdn.pcapng.gz gsup_lu_msisdn.pcapng.gz 819 Bytes fixeria, 05/25/2019 01:20 PM
Actions #1

Updated by fixeria almost 5 years ago

  • Tags deleted (<pre)
Actions #2

Updated by fixeria almost 5 years ago

  • Project changed from OsmoMSC to libosmocore
  • Subject changed from 15-digit long MSISDNs truncated to 14 digits: the last digit is lost to gsm48_decode_bcd_number2(): incorrect output buffer truncation
  • Category changed from VLR to libosmogsm
  • Status changed from New to Feedback
  • % Done changed from 0 to 80

As it turns out, this is a bug of gsm48_decode_bcd_number2() in libosmogsm. Please see:

https://gerrit.osmocom.org/#/c/libosmocore/+/14184 gsm0408/gsm0408_test.c: introduce BCD number encoding / decoding test
https://gerrit.osmocom.org/#/c/libosmocore/+/14185 gsm/gsm48_ie.c: fix output truncation in gsm48_decode_bcd_number2()
https://gerrit.osmocom.org/#/c/libosmocore/+/14186 gsm48_decode_bcd_number2(): fix: return -ENOSPC on truncation
https://gerrit.osmocom.org/#/c/libosmocore/+/14187 gsm48_decode_bcd_number2(): return -EINVAL if LV has too big length

Change number 14185 fixes the problem. Waiting for review now...

Actions #3

Updated by fixeria almost 5 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 80 to 100

Merged.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)