aboutsummaryrefslogtreecommitdiffstats
path: root/src/libmsc
AgeCommit message (Collapse)AuthorFilesLines
2019-08-24Implement a global switch on the network to disable call waiting.cccamp2019Keith Whyte2-3/+47
Add a network -> callwaiting VTY command as boolean. When this is enabled (default) there is no change to operation previous to this commit. When this switch is disabled with "no call-waiting" in vty then when a call arrives, we will check if we have an active call transaction for this subscriber, no matter if it is establishing, established, or alerting, in any of these cases we will return USER BUSY to the calling party. Change-Id: I3eb6f23f7103e3002874fb5d3a30c9de952202ae
2019-08-24do not set more sms waitinggsmevent admin1-1/+1
2019-08-23smpp_openbsc.c: check acl before deref itAlexander Couzens1-1/+1
All other calls check acl before deref because in a setup with no access policy, there won't be any acl structure Change-Id: Ibe0256535b40351594d79baa05a0147a9f89dc26
2019-08-22tweak CC cause for incoming call to unattached nrNeels Hofmeyr1-1/+1
So far we sent CC cause "Unassigned Number" But the MSC doesn't trivially know whether the HLR has the number assigned or not: any handset that is currently switched off would cause "Unassigned number" to be displayed on the caller's handset. Rather send a temporary failure cause code. Send this cause code for all cases, because claiming that an assigned number is unassigned is worse than rejecting an unassigned number with a temporary failure. Change-Id: Ia3d4f67b53fcc2654ff048fbc338e92cb763a095
2019-08-22ran_dec logging: log message sizes on errorsNeels Hofmeyr1-3/+7
Change-Id: Id08e4ee5a4dbf552dbb107d8f0519110664f6acb
2019-08-21fix segfault: don't send CC REL on NULL msc_aNeels Hofmeyr2-2/+19
Apparently, if a conn disappears during an ongoing call, the CC code tried to send a CC REL on a NULL msc_a during cleanup, which lead to a crash (cccamp2019). Guard against that. Crash: #0 msc_a_tx_dtap_to_i (msc_a=0x0, dtap=0x55a4bf2fa0f0) at ../../../../src/osmo-msc/src/libmsc/msc_a.c:1565 #1 0x000055a4be1bb03c in trans_tx_gsm48 (trans=0x55a4bf2d52a0, trans=0x55a4bf2d52a0, trans=0x55a4bf2d52a0, msg=<optimized out>) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:82 #2 gsm48_cc_tx_release (trans=trans@entry=0x55a4bf2d52a0, arg=arg@entry=0x7ffdd731a0e0) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:1101 #3 0x000055a4be1bee65 in _gsm48_cc_trans_free (trans=trans@entry=0x55a4bf2d52a0) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:278 #4 0x000055a4be1ab654 in trans_free (trans=trans@entry=0x55a4bf2d52a0) at ../../../../src/osmo-msc/src/libmsc/transaction.c:170 #5 0x000055a4be1bd091 in mncc_tx_to_gsm_cc (net=<optimized out>, msg=msg@entry=0x55a4bf2d3b68) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:1971 #6 0x000055a4be1bf1e5 in mncc_tx_to_cc (net=<optimized out>, arg=arg@entry=0x55a4bf2d3b68) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:2049 #7 0x000055a4be18ed63 in mncc_sock_read (bfd=0x55a4bf2563b8, bfd=0x55a4bf2563b8) at ../../../../src/osmo-msc/src/libmsc/mncc_sock.c:121 #8 mncc_sock_cb (bfd=0x55a4bf2563b8, flags=1) at ../../../../src/osmo-msc/src/libmsc/mncc_sock.c:189 #9 0x00007fcfad607ce1 in osmo_fd_disp_fds (_eset=0x7ffdd731a9a0, _wset=0x7ffdd731a920, _rset=0x7ffdd731a8a0) at ../../../src/libosmocore/src/select.c:223 #10 osmo_select_main (polling=<optimized out>) at ../../../src/libosmocore/src/select.c:263 #11 0x000055a4be17dd56 in main (argc=3, argv=<optimized out>) at ../../../../src/osmo-msc/src/osmo-msc/msc_main.c:723 Change-Id: Ia1bb0410ad0618c182a5f6da06af342b6d483eff
2019-08-20mncc: send payload type matching chosen codecNeels Hofmeyr1-13/+25
Change-Id: Id32f32d77d24b753adb96b5393c0363439e312c2
2019-08-19msc_a: switch RAN type back to SGs when a CSFB-Call is clearedPhilipp Maier1-0/+5
When a CSFB call is over the MS changes back to LTE after the call is cleared. However, at the moment the MSC does not change the cs.attached_via_ran flag. This may cause problems with the next call. Lets make sure that if there is an SGs association present, the ran type is set back to SGs when the call is cleared. Related: SYS#4624 Change-Id: I104adecb0645b81b90ee230c57bf8b463c9e7045
2019-08-16sgs_iface: do not use SGsAP-MO-CSFB-INDICATION for CSFB returnPhilipp Maier1-4/+4
When the VLR/MSC receives an SGsAP-MO-CSFB-INDICATION message it sets the RAN type back to SGs. This is wrong, the message SGsAP-MO-CSFB-INDICATION has just an informative character. It informs the VLR that the UE has initiated an MO CSFB call (service request). Change-Id: I625574fc42fc915ba483db3bb406922ad6df370d Related: SYS#4624
2019-08-13add 'encryption uea 1 2' cfg / fix ttcn3 iu testsNeels Hofmeyr3-8/+53
Recently, the ability to run UTRAN without encryption was added, but the config for it was tied to the A5 GERAN encryption configuration. This affected osmo-msc's default behavior of Iu, breaking osmo-msc ttcn3 Iu tests: the ttcn3 test suite sets A5 to 0 (no encryption) but still expects Iu to enable air encryption. Fix this "regression". Add a separate vty config option for UEA encryption, even if it does not provide full granularity to select individual UEA algorithms yet. As a result, Iu default behavior remains to enable encryption regardless of the A5 config. UTRAN encryption can be disabled by the new cfg option "encryption uea 0" alone. Even though the new vty command already allows passing various combinations of the UEA algorithm numbers, only '0' and '1 2' are accepted as valid combinations, to reflect current osmo-msc capabilities. Revert most changes to the msc_vlr test suite in commit "do not force encryption on UTRAN" (I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7): use new net->iu_encryption instead of net->a5_encryption_mask. Adjust/add to test_nodes.vty transcript tests. Related: OS#4144 Change-Id: Ie138f2fcb105533f7bc06a6d2e6deccf6faccc5b
2019-08-12cosmetic: make function mncc_tx_to_gsm_cc staticPhilipp Maier1-1/+1
The function mncc_tx_to_gsm_cc() is declared as non static but only used from within gsm_04_08_cc.c. Lets declare it as static to increase readability of the code Change-Id: Icd02c669cfee6dd7e6b154e303cd0f4c148c83c4
2019-08-05do not force encryption on UTRANNeels Hofmeyr2-4/+7
Remove the conditions that always enable encryption on UTRAN. We so far lack an explicit configuration for UTRAN encryption, and this patch does not add any either. Instead, whether UTRAN encryption is enabled is simply triggered on whether GERAN has A5 encryption enabled (A5/n with n > 0). Though GERAN and UTRAN encryption are not technically related at all, this makes UTRAN behave like GERAN for now, until we implement a proper separate configuration for UTRAN encryption. Adjust the msc_vlr_test_* configuration by setting the net->a5_encryption_mask such that the expected output remains unchanged. A subsequent patch (I54227f1f08c38c0bf69b9c48924669c4829b04b9) will add more tests, particularly cases of UTRAN without encryption. Adjust manual and vty doc. Related: OS#2783 Change-Id: I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7
2019-08-02Set coding in mncc_set_cause()Keith Whyte1-0/+1
GSM 04.08 10.5.4.11 The Release indication needs to have the Coding Standard set. For phones that would display a message on screen, such as "Number not in use", if the coding standard is not defined, the display may show "Error in Connection" Change-Id: Ib28b62a41d433e231cff5910d19455296b284df6
2019-07-29minor comments in msc_vty.cNeels Hofmeyr1-0/+2
Change-Id: I83d8c778190adb1e74debc8f8ddac6996de7c513
2019-07-18replace osmo_counter with stat_itemsAlexander Couzens3-7/+15
osmo_counter will be soon deprecated. Use the newer and more flexible osmo_stat_item instead. Depends on: Id2462c4866bd22bc2338c9c8f69b775f88ae7511 (libosmocore) Change-Id: I6a20123b263f4f808153794ee8a735092deb399e
2019-07-16fix spelling detected by lintianThorsten Alteholz1-3/+3
Change-Id: I01e54b5cf111677079a8ad57645d3ceb7834702a
2019-07-09libmsc/msc_vty.c: print subscriber expiration timeVadim Yanitskiy1-0/+17
Change-Id: I092691a8c443f4c5ed4d33de2e551fef592c1baf
2019-07-09Fix: add missing semicolons to OSMO_ASSERT statementsVadim Yanitskiy1-1/+1
Change-Id: I4fae5fbab5fdbcce35906601d4f1031d971f4931
2019-06-20libmsc/ran_msg_iu.c: fix: properly handle SAPI IE of RANAP_DirectTransferVadim Yanitskiy1-2/+12
The RANAP DirectTransfer message may contain an optional SAPI IE. Thanks to our TTCN-3 tests (and Wireshark!), it was discovered that this IE is ignored, so even if the MO SMS related messages arrive on SAPI 3 (as per GSM TS 04.11, section 2.3) OsmoMSC sends MT messages on SAPI 0. In ran_iu_decode_l3() we need to check if the SAPI IE is present, and tag the NAS PDU message buffer with a proper DLCI value. This change makes the failing SMS related test cases pass. Change-Id: I728b55b04e87fc23be6d4f8735e8cad82b6f640e
2019-06-20libmsc/gsm_04_11.c: do not abuse LOG_TRANS() in gsm411_alloc_mt_trans()Vadim Yanitskiy1-2/+2
This change is similar to I6b68a0f0b32eb126e0f7e914a314130254d28467. If we 100% sure that trans == NULL, it makes more sense to use generic LOGP(DLSMS, LOGL_*, ...) call, so the logs can reflect more information than such dummy prefix: trans(NULL NULL callref-0x0 tid-0) ... Change-Id: I3c1e633aee5dd7cd0d367404a3def9cffe0b3baa
2019-06-20gsm_04_11_gsup.c: fix broken reference counting for vsubVadim Yanitskiy1-4/+11
This change is similar to I5540556b1c75f6873883e46b78656f31fc1ef186. In gsm411_gsup_rx() we do call vlr_subscr_find_by_imsi(), which increases subscriber's reference count by one using the function name as the token. However, we never release this token, so the reference count grows on every received GSUP FORWARD-SM message. Change-Id: Ic729beb5f94cbbfbb251bc9ab66a5e7b799286c0
2019-06-20sms_queue.c: Improve misleading log linePau Espin Pedrol1-1/+1
Otherwise when read in a log file it seems it's really going to send 20 sms even if there's none to send. Change-Id: Ieb9bb61a90f295d2ba5fb67a2abee2d30785876d
2019-06-17libmsc/gsm_09_11.c: do not suppress rc of gsup_client_mux_tx()Vadim Yanitskiy1-1/+1
Change-Id: Ide2440188fb6fe1c54681fef8ec4fed9e6da66e2
2019-06-17libmsc/gsm_09_11.c: do not abuse LOG_TRANS() in gsm0911_rcv_nc_ss()Vadim Yanitskiy1-3/+4
If we 100% sure that trans == NULL, it makes more sense to use generic LOGP(DSS, LOGL_*, ...) call, so the logs can reflect more information than such dummy prefix: trans(NULL NULL callref-0x0 tid-0) ... Change-Id: I6b68a0f0b32eb126e0f7e914a314130254d28467
2019-06-17libmsc/gsm_09_11.c: fix broken reference counting for vsubVadim Yanitskiy1-2/+12
In gsm0911_gsup_rx() we do call vlr_subscr_find_by_imsi(), which increases subscriber's reference count by one using the function name as the token. However, we never release this token, so the reference count grows on every received GSUP PROC-SS message. Change-Id: I5540556b1c75f6873883e46b78656f31fc1ef186
2019-06-17libmsc/gsm_09_11.c: avoid double zero-initialization of gsup_msgVadim Yanitskiy1-1/+1
Change-Id: Ib991b01534499401e7a0c3de49ceba770fdd9b48
2019-06-17libmsc/gsm_09_11.c: properly handle OSMO_GSUP_MSGT_PROC_SS_ERRORVadim Yanitskiy1-3/+25
This message can be used by the HLR/EUSE to indicate that something went wrong, e.g. the connection with EUSE is lost, EUSE or the MS did not respond in time, etc. OsmoMSC needs to release the SS/USSD transaction, and send GSM 04.80 RELEASE COMPLETE message to the MS if there is an active RAN connection. Change-Id: I076d12ef24d7320eda1df1ee4588da7375ef3d9e Related: (TTCN-3) I5586a88136c936441a842f49248824680603672e Related: OS#2931
2019-06-17libmsc/gsm_09_11.c: inform HLR/EUSE if Paging has failedVadim Yanitskiy1-1/+17
Change-Id: Ie2ac06aadb18251310e0cfd85bb0d9865470aab7 Related: (TTCN-3) I1f53c56d569c8ac4071835685bbe3bc9e0ebd7f0 Related: OS#2931
2019-06-17libmsc/msc_net_init.c: pass pointer to gsm_network directlyVadim Yanitskiy3-31/+12
Change-Id: I122d2880b356997c60df5f0cf4f5ecb3abb2e672
2019-06-17libmsc/gsm_09_11.c: drop meaningless check for concurrent pagingVadim Yanitskiy1-15/+1
This check was copy-pasted from the CC handling code during the initial development of "SS/USSD over GSUP" feature. It probably makes sense for MT calls, but definitely not for SS/USSD. Change-Id: I2899a23ee49fd7917443943629603700a5025cf4
2019-06-17libmsc/gsm_09_11.c: drop rudimentary vsub->cgi.lai.lac checkVadim Yanitskiy1-7/+0
This check was copy-pasted either from CC, or from SMS handling code during the initial development of "SS/USSD over GSUP". Now this is the only one survived after the recent refactoring. I doubt this is exactly the right way to check whether subscriber is attached or not. Moreover, this check should rather be done in a single place, rather then in each CC/SS/SMS handler separately. Change-Id: I7bd48860e923cb1f1a5bccc4b0f497ec1a7bcf84
2019-06-17libmsc/gsm_09_11.c: log network-originated session establishment errorVadim Yanitskiy1-0/+3
Change-Id: I090c25de3421f770115ed68a7ecc050694cedff7
2019-06-17libmsc/gsm_09_11.c: do not abuse LOG_TRANS() and early trans allocationVadim Yanitskiy1-29/+19
In case of network-originated SS/USSD session establishment, we need to verify the received GSUP PROC_SS_REQ message and make sure that all mandatory IEs are present. There is no sensible need to allocate a new transaction before doing all the checks, other than the ability to use LOG_TRANS(). This complicates the code, so let's avoid the early allocation. Change-Id: I4e027b19e8065a39324a1647957cef4066b82ce7
2019-06-16libmsc/paging.c: cosmetic: remove leading space in log lineVadim Yanitskiy1-1/+1
Change-Id: Ie7816f3b30a6c6ac5175646b479eb9a3e76429e1
2019-06-16libmsc/paging.c: cosmetic: actually use default branch of switchVadim Yanitskiy1-4/+2
Change-Id: I9b566885f722a28816760532b645f606fdf4faeb
2019-06-16libmsc/paging.c: avoid double zero-initializationVadim Yanitskiy1-1/+1
Change-Id: Icc839370fc39ab57078ec6deeac337ed2f37793c
2019-06-16libmsc/msc_a.c: fix: remove dummy allstate_action of msc_a_fsmVadim Yanitskiy1-13/+0
Since [1] has been merged to libosmocore, it was discovered that the 'msc_a' FSM has a dummy 'allstate_action' handler assigned, but 'allstate_event_mask' is 0x00 at the same time. It basically doesn't make any sense, and moreover does cause warnings and build failures. [1] https://git.osmocom.org/libosmocore/commit/?id=b3f94eb39e19366c3458643ee329a73155d46ff8 [1] https://gerrit.osmocom.org/#/c/libosmocore/+/14361/ Change-Id: Ieb81b7a07ced1c40ba70d2adb0df68160ee62118
2019-06-15libmsc/gsm_04_08.c: clean up unused leftover includesVadim Yanitskiy1-13/+0
During the recent refactoring, some code parts has been moved out of 'gsm_04_08.c', but the related header files were forgotten. Change-Id: I61e728069a1e79bf72c01ef9d9fc5fb171d3892e
2019-06-15libmsc/gsm_09_11.c: send GSUP PROS_SS ERROR message when neededVadim Yanitskiy1-3/+4
OsmoMSC should notify the remote SS/USSD entity if: - received GSUP message has unexpected session state; - received GSUP message has unknown session ID; - received GSUP message missing mandatory IE(s); - NCSS transaction establishment failed; - NCSS message delivery failed. Change-Id: Ief9f8a197b0860072b671edfc55180f619860d9d Related: (TTCN-3) Ie267ee174c5061cd3fc102a2824abe03d73f3aac Related: OS#2931
2019-06-15libmsc/gsm_09_11.c: fix: return trans from establish_nc_ss_trans()Vadim Yanitskiy1-1/+1
It is expected that establish_nc_ss_trans() returns an allocated transaction in successful case, or NULL in case of error. The function assumes two scenarios: - the subscriber already has an active RAN connection, - RAN connection needs to be established (Paging). In the first case, a pointer to the transaction is returned as expected, but in case of Paging, NULL has always been returned, even if there were no errors. Let's fix this. Change-Id: I9dcee64dd0b435ef29630c223132b81724701f93
2019-06-15gsup_client_mux_tx_error_reply(): fix: do not omit SM-RP-MR IEVadim Yanitskiy1-0/+3
The SM-RP-MR (Message Reference for SM Service) value in the response (no matter result or error) shall match the value from the request. Change-Id: Ifb6e749928548e6febfe7768aefe9a2a3ecf4de0
2019-06-15gsup_client_mux_tx_error_reply(): fix: do not omit message class IEVadim Yanitskiy1-0/+1
Found using the new TC_mt_ussd_for_unknown_subscr test case. Change-Id: Id00a99b713a6b97c455b8e6ae49abea163e8281f Related: (TTCN-3) Id35cd3ec15d1bab15260312d7bbb41e2d10349fe Related: OS#2931
2019-06-15gsup_client_mux_tx_error_reply(): fix: do not omit session IEsVadim Yanitskiy1-0/+6
For SS/USSD, it's important to have both session state and ID IEs. Found using the new TC_mt_ussd_for_unknown_subscr test case. Change-Id: I57317a7b8036d1ffd36e2021efc146db4633da84 Related: (TTCN-3) Id35cd3ec15d1bab15260312d7bbb41e2d10349fe Related: OS#2931
2019-06-14gsup_client_mux_tx_error_reply(): fix: do not override IMSIVadim Yanitskiy1-2/+2
I am not a big fan of using such syntax sugar for initializing structures, and this is one of the reasons: it's much easier to shoot yourself in the foot. IMSI was copied to the new GSUP message, but then overridden. Found using the new TC_mt_ussd_for_unknown_subscr test case. Change-Id: If81c3fa56951185339f33a523ab6364594101be1 Related: (TTCN-3) Id35cd3ec15d1bab15260312d7bbb41e2d10349fe Related: OS#2931
2019-06-15libmsc/gsm_0(4|9)_11_gsup.c: print error message if subscr is not knownVadim Yanitskiy2-0/+4
Change-Id: I0b9d4128c853866d7d834f381ad520f78f441afe Related: (TTCN-3) Id35cd3ec15d1bab15260312d7bbb41e2d10349fe Related: OS#2931
2019-06-14libmsc/mncc_builtin.c: drop dummy switch in int_mncc_recv()Vadim Yanitskiy1-4/+0
Change-Id: I24153919596d58b495f9c9057dfc230e1501b95f
2019-06-07libmsc/db.c: get rid of hard-coded SMS expiry thresholdVadim Yanitskiy1-17/+11
The initial idea of the SMS expiry threshold was to avoid storing SMS messages with too long validity time (e.g. 63 weeks). Unfortunately, neither this feature was properly documented, nor the expiry threshold is configurable. Moreover, it has been implemented in a wrong way, so instead of deleting the oldest expired message, it would delete the youngest one or nothing: SELECT ... FROM SMS ORDER BY created LIMIT 1; while it should be sorted by 'valid_until' in ascending order: SELECT .. FROM SMS ORDER BY valid_until LIMIT 1; Thus, if the oldest message is expired, it gets deleted. If the oldest message is not expired yet, there is nothing to delete. Change-Id: I0ce6b1ab50986dc69a2be4ea62b6a24c7f3f8f0a
2019-06-06libmsc/db.c: warn user about SMS text truncationVadim Yanitskiy1-0/+10
In general, neither TP-User-Data nor decoded text should be truncated. If the SMSC's database for some reason does contain such weird messages, let's at least let the user know about it. Change-Id: I75e852ebe44ba4784572cbffa029e13f0d3c430c
2019-06-06libmsc/db.c: introduce and use parse_sm_ud_from_result()Vadim Yanitskiy1-49/+37
The following functions: - sms_from_result(), - sms_from_result_v3(), - sms_from_result_v4(), do retrieve the TP-UD, TP-UDL and text in the same way. A consequence of such duplication is [1], which fixed potential NULL-pointer dereference for sms_from_result(), but not for two other functions: sms_from_result_v3() and sms_from_result_v4(). [1] I545967464c406348b8505d1729213cfb4afcd3e2 Change-Id: If67dfb9f7d2a55fa3d45dc4689a2acff9909faf6
2019-06-06libmsc/db.c: fix potential integer overflowVadim Yanitskiy1-9/+27
The value of 'sms->user_data_len' is fetched from the database: sms->user_data_len = dbi_result_get_field_length(result, "user_data"); and this is where the problem is. As per the libdbi's documentation (see 3.5.3), dbi_result_get_field_length() returns the length in bytes of the value stored in the specified field: unsigned int dbi_result_get_field_length(dbi_result Result, const char *fieldname) so 'unsigned int' is assigned to 'uint8_t', what could lead to an integer overflow if the value is grather than 0xff. As a result, if the database for some reason does contain such odd TP-UD, the truncation of 'user_data' would be done incorrectly. Let's avoid such direct assignment, and use a separate variable. Also, let's warn user if TP-UDL value is grether than 140, as per 3GPP TS 03.40. Change-Id: Ibbd588545e1a4817504c806a3d02cf59d5938ee2 Related: OS#3684
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-30 02:16:18 +0000