Actions
Bug #4025
closedgsm48_decode_bcd_number2(): incorrect output buffer truncation
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
Actions