Bug #4025
closedgsm48_decode_bcd_number2(): incorrect output buffer truncation
100%
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
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...
Updated by fixeria almost 5 years ago
- Status changed from Feedback to Resolved
- % Done changed from 80 to 100
Merged.