aboutsummaryrefslogtreecommitdiffstats
path: root/src/libmsc
AgeCommit message (Collapse)AuthorFilesLines
2019-03-19a_iface: OSMO_ASSERT() if we ever want to send BSSAP with invalid lengthHarald Welte1-0/+13
Let's add a safeguard against sending BSSAP messages with invalid length values. This should never happen, and we'd rather see osmo-msc assert during the development cycle than ever releasing a version which sends invalid messages out on the wire. Change-Id: I94327a0d276c65b528a8c7e33dde61ed53582284 Related: OS#3805
2019-03-15silent_call: use osmo_strlcpy() instead of strncpy()Philipp Maier1-1/+2
If gsm_silent_call_start() is called with an over long string in traffic_dst_ip, then the target string might be left unterminated. Lets use osmo_strlcpy() so that we can be sure the result in scd->traffic_ip is always terminated. Fixes: CID#196068 Change-Id: Ic81842175e412ae7d97d023b612412f33411d60c
2019-03-14libmsc: Allow different channel types to be requested as silent callsSylvain Munaut2-20/+154
Change-Id: I82645708dd27864cf33ea9cc993ead0983415602
2019-03-08vty: add cmd subscriber ID sms delete-allNeels Hofmeyr1-0/+25
In ttcn3-msc-tests, so far we leave an intentionally failed MT SMS in the SMS queue, which may cause it to re-appear in subsequent tests. Allow removing all SMS for a given subscriber from the SMS database for good. (I dimly remember a user report where the SMS queue spams failed SMS attempts, and the only way to get rid of SMS for a given subscriber is to tamper with the sms.db file directly. This should no longer be necessary with this command.) Related: I7dce12942a65eaaf97f78ca69401c7f93faacb9e (osmo-ttcn3-hacks) Change-Id: I637cbd7adc075a192f49752b38779391472ff06d
2019-03-07SMS queue: properly log failed attempts numberNeels Hofmeyr1-1/+2
Change-Id: I16f2d29855eb715eccbdc5def225f43c110fab8e
2019-03-07gsm_04_11_gsup.c: drop unused conn lookupNeels Hofmeyr1-11/+0
An earlier code state used the conn to lookup the transaction, but this is now done by vsub. Hence the conn lookup is not used and not needed. conn is no longer used since 36c44b210059bd75059008913ad05976dfef7d7e, change-Id I093f36d63e671e50e54fc6236e97a777cc6da77b, "transaction: change arguments of trans_find_by_sm_rp_mr()" Change-Id: Ia878d70138c883cb1a1d983516aff83efa6488ce
2019-03-07use only accepted ran_conns for new transactionsNeels Hofmeyr2-3/+11
In connection_for_subscriber(), do not return a ran_conn that is not yet authenticated nor one that is already in release. Using a ran_conn that is not yet authenticated may cause an auth/ciph violation. Using a ran_conn that is already in release may cause a use-after-free, see OS#3842 for a description. To be paranoid, upon releasing a conn, go through the transaction freeing motions again by calling trans_conn_closed(), just in case some odd code path added another transaction while the conn was already in release. Related: OS#3842 Change-Id: Id957032e0ae1ff8ba055a75c3523447d3d06cbc3
2019-02-28Don't deliver alert notifications to ESME not yet bound. Keith1-0/+5
We create a new ESME in smsc->esme_list on establishment of a TCP connection, yet we do not know the system id or anything else, until the ESME identifies and authenticates. So do not send alert notifications until we know the bind status (and system_id) Change-Id: Iec92d4c145ca050c2e212139572eeaae581b99df
2019-02-28libmsc/msc_vty.c: drop dead comparison against nullVadim Yanitskiy1-1/+1
Since vsub->sgs.mme_name is allocated statically, comparing it to null doesn't make sense - it's always != NULL. Change-Id: Ib2933a20471ebff9dfe1d9fdddf39d177504c951 Fixes: CID#178166 Array compared against 0 (NO_EFFECT)
2019-02-28libmsc/sgs_vty.c: always write server address and VLR nameVadim Yanitskiy1-6/+3
Comparing an array to null is not useful, because the expression will always evaluate as true. Let's just always write SGs server address and VLR name, no mater whether default values are used or not, same as we do for the HLR address and port. Change-Id: If045e42fca0315b0777eb86c44bf934ce58b340b Fixes: CID#190871 Array compared against 0 (NO_EFFECT)
2019-02-26libmsc/sgs_iface.c: fix SGS_STATE_NS11 counter referenceVadim Yanitskiy1-1/+1
The SGS_STATE_TS11 is not for counters, it's for timers! Change-Id: Ifbb1a37e644ae8bf8e7959f6f6cd6403ac1f2f1b Fixes: CID#190872 Out-of-bounds read (OVERRUN)
2019-02-26libmsc/ran_conn.c: add missing 'break' to OSMO_RAT_EUTRAN_SGSVadim Yanitskiy1-0/+1
Change-Id: I18dfd08ea0857f2751164a295dd9de20a2024ac3 Fixes: CID#190874
2019-02-20libmsc/gsm_09_11.c: implement guard timer for NCSS sessionsVadim Yanitskiy3-0/+78
It may happen that either the MS or an EUSE would become unresponsive during a call independent SS session, e.g. due to a bug, or a dropped message. In such cases, the corresponding transaction would remain unfreed forever. This change introduces a guard timer, that prevents keeping 'stalled' NCSS sessions forever. As soon as it expires, both sides (i.e. MS and EUSE) are getting notified, and the transaction is being released. By default, the timer expires after 30 seconds. As soon as either the MS, or an EUSE initiates any activity, the watchdog timer is rescheduled. The timeout value can be configured from the VTY: msc ... ! Use 0 to disable this timer ncss guard-timeout 30 Please note that changing the timeout value at run-time doesn't affect the existing NCSS sessions, excepting the case when the timer is disabled at run-time. This change makes TC_lu_and_ss_session_timeout pass. Change-Id: Icf4d87c45e90324764073e8230e0fb9cb96dd9cb Related Change-Id: (TTCN) I3e1791773d56617172ae27a46889a1ae4d400e2f Related: OS#3655
2019-02-18a_iface: Fix hexdumping of N-DATA.reqHarald Welte1-1/+1
For some reason the existing code was using msgb_hexdump_l2() while the L2 header is not used by the BSSAP transmit code. Let's fix this. Change-Id: I52a1eb3a867ece63fcfa4c2a720d035ebfb90a7b
2019-02-18a_iface: use 'const' qualifier for ran_conn whenever possibleHarald Welte1-3/+3
Change-Id: I8a15c9baae2071569e2ecc4635ddaf5a0001f959
2019-02-18a_iface: Centralize/wrap BSSAP / N-DATA transmissionHarald Welte1-11/+15
We don't want multiple callers to osmo_sccp_tx_data_msg() each having to hex-dump a log message about the to-be-transmitted message, with half of the caller sitest missing that printing. Let's centralize all calls of osmo_sccp_tx_data_msg() in a wrapper function which takes care of the related OSMO_ASSERT() and the related printing. Change-Id: I6159ea72cc8e0650eda6c49544acd65e9c15e817
2019-02-15transaction: fix description of trans_assign_trans_id()Vadim Yanitskiy1-2/+2
Change-Id: I80238d89e95b6fd791961c48de80aac69ff5b0e9
2019-02-15transaction: clarify magic 0xff transaction IDMax3-4/+5
Change-Id: I2d3a6334f49989bedbb1430d26ffad8b61dfd873
2019-02-15transaction: drop meaningless ti_flag of trans_assign_trans_id()Max4-13/+8
According to GSM 04.07, the TI flag takes one bit and can be either of the following: '0'B - transaction is allocated by sender of a message, '1'B - transaction is allocated by receiver of a message. Since we store transaction ID in gsm_trans structure, we also store TI flag (as a part of transaction ID), which in this context means: '0'B - transaction is allocated by us (OsmoMSC), '1'B - transaction is allocated by some MS. In 100% cases, trans_assign_trans_id() is used to assign transaction IDs to transactions allocated by us (i.e. OsmoMSC) for MT connections. And there is no need to use it for MO transactions, because they basically already do contain a valid transaction ID assigned by the MS. Change-Id: Ie11999900b1789652ee078d34636dcda1e137eb0
2019-02-14libmsc/osmo_msc.c: move connection ref-counting code to 'ran_conn.c'Vadim Yanitskiy2-111/+111
The connection ref-counting implementation is specific to RAN connections, and is not applicable for anything else. Moreover, the API of this code is declared in 'ran_conn.h', so let's move the code to a more logical place. Change-Id: I593675d9bf56eaef12afdaf596ee1337b9a44259
2019-02-13libmsc/gsm_04_80.c: add msc_send_ussd_release_complete_cause()Vadim Yanitskiy1-0/+28
According to GSM 04.80, section 2.5.1, Release complete message may have an optional Cause IE. Let's add a new function, that allows to specify cause location and value. This function will be used by the upcoming changes. Change-Id: I3b9e8e4f473d113d5b9e9e5d33f7914202077203 Depends Change-Id: (libosmocore) Ie3ac85fcef90a5e532334ba3482804d5305c88d7
2019-02-13libmsc/gsm_04_80.c: use gsm0480_create_release_complete()Vadim Yanitskiy2-3/+6
The previous implementation of msc_send_ussd_release_complete() was based on gsm0480_create_ussd_release_complete(), that doesn't allow to specify GSM 04.07 transaction identifier. The ability to specify particular transaction identifier is required for handling multiple SS/USSD transactions. Change-Id: Id2975c3383f18e83124ba38927c03980d67ddadb Depends Change-Id: (libosmocore) Ie3ac85fcef90a5e532334ba3482804d5305c88d7
2019-02-07a_iface: Include CSFB Indication into BSSMAP CLEAR COMMANDPhilipp Maier1-1/+6
When a call ends that has been established in an CSFB context, we should add a CSFB Indication IE to the BSSMAP CLEAR COMMAND to instruct the BSC to add further CSFB related IEs into the RR RELEASE. - Check if an SGs association exists and add CSFB Indication IE Change-Id: I6cfa4b3becdd0138d74e2e1eddd83a0b1568c1de Related: OS#3778
2019-02-04Add SGs InterfaceHarald Welte13-14/+1728
Add an SGs interface (3GPP TS 29.118) to osmo-msc in order to support SMS tunneling and Circuit Switched Fallback (CSFB) Change-Id: I73359925fc1ca72b33a1466e6ac41307f2f0b11d Related: OS#3615
2019-02-01libmsc/gsm_04_11.c: introduce and use gsm411_assign_sm_rp_mr()Vadim Yanitskiy1-3/+29
Initially, it was assumed that if there is no active RAN connection, we can just start counting from 0x00, as there are no other SMS related transactions, and transaction itself is allocated using talloc_zero(). Until now it was looking good, but... As soon as we establish RAN connection with subscriber, we already have a transaction with SM-RP-MR 0x00, but conn->next_rp_ref also remains 0x00 - it isn't being increased! It means that we can face a SM-RP-MR conflict (or collision) if another MT SMS would arrive to the MSC (from SMSC over GSUP) when this transaction is still active, i.e. the first SMS is still being sent, because conn->next_rp_ref++ would return 0x00 again. Moreover, there might be already a MO SMS transaction, and using the conn->next_rp_ref counter wouldn't prevent us from having duplicate SM-RP-MR value. Let's get rid of this per-connection counter, and introduce a function instead, that would iterate over existing transactions and look for an unused SM-RP-MR value. This change makes the following test cases pass: - TC_gsup_mt_sms_rp_mr, - TC_gsup_mo_mt_sms_rp_mr. Discovered by: Neels Hofmeyr Related Change-Id: (TTCN) I3a52d44f4abde9b6b471b9108c1cee905884c9bc Related Change-Id: (TTCN) I17cbbaa64d9bce770f985588e93cd3eecd732120 Change-Id: Ife6d954c46b7d8348a4221ab677d0355eb3ee7ac
2019-02-01libmsc/gsm_04_11.c: also assign SM-RP-MR to MO transactionsVadim Yanitskiy1-0/+2
Previously, SM-RP Message Reference was assigned to MT transactions only, but not to MO transactions. As a result, this could lead to having a few transactions with duplicate SM-RP-MR value, because in case of MO SMS, trans->sms.sm_rp_mr would remain 0x00. Let's parse SM-RP-MR from MO SMS messages in gsm0411_rcv_sms(), and assign it to the new transaction after allocation. Change-Id: I4d07354175444f9764fb0dd6ea188a64494d79fe
2019-02-01transaction: change arguments of trans_find_by_sm_rp_mr()Vadim Yanitskiy2-5/+5
The need to pass a pointer to RAN connection in order to find a transaction limits possible use cases of trans_find_by_sm_rp_mr(), e.g. when we need to find a transaction, but RAN connection is not established yet. Moreover, the pointer to RAN connection was only used to obtain pointers to gsm_network and vlr_subscr, so we can just pass them directly. Change-Id: I093f36d63e671e50e54fc6236e97a777cc6da77b
2019-01-26libmsc/ran_conn.c: cosmetic: use tabs instead of N * 8 spacesVadim Yanitskiy1-1/+1
Change-Id: I09515aea9da8e2b5836c5c6409f094fae05633d4
2019-01-26transaction.c: cosmetic: use 'default' branch in trans_free()Vadim Yanitskiy1-1/+4
Change-Id: Ia28ba52b0ea4771843a2a1faa346f7357604b8aa
2019-01-24Various logging fixesMax3-5/+5
Log transaction allocation errors as such. While at it, use proper subsystem to log missing VLR subscriber. Change-Id: I617be8793b9416ccd49022c72f7d93df7f4fb4d9
2019-01-24Handle LCLS-NOTIFICATION message from BSSMax1-0/+25
Change-Id: Ibf5f9cad1f70aee56d5bca8fe09a24ca417e7a63 Related: OS#2487
2019-01-22fix build: apply msgb_wrap_with_TL() renameNeels Hofmeyr1-1/+1
After libosmocore commit If1e851ac605c8d2fde3da565b0bd674ea6350c2e b27e6feb699712345373e87a48187dc622e4fa92 the osmo-msc master build is broken. Apply the msgb_wrap_with_TL() rename to msgb_push_tl() to unbreak the build. Change-Id: I1d4675e0c907b2f92f2ec79b02356391a6d72aa8
2019-01-17vty: make 'sh connect/transact' readable againMax1-9/+24
After recent changes to vlr_subscr_name() result became variable-length which messes up old vty code. Fix this by moving it to the very end and adjusting headers as necessary. While at it, make sure we don't print headers if we have nothing else to show. Change-Id: Id06b4277ff790d95457d0cc2f94ef6bf5366bb21
2019-01-17Cosmetic: Fix spelling in smpp vtyKeith1-2/+2
Change-Id: Id3fa3f26c333bf445590fd75ad7a08be68fed3e2
2019-01-17Make alert notifications vty configurable per ESMEKeith4-2/+35
Adds (no) alert-notifications as a per-esme vty command, in order to allow some ESMEs to be excluded from alerts. The default is still to send alert notifications to all esme, so no changes are required to the config file to maintain identical operation after this patch. Change-Id: I57f4d268ca6fe6a233f2caaffce62e4aade01274
2019-01-17SMS: remove code duplication in transaction initMax1-24/+27
Move code which allocates transaction for SMS and initializes corresponding FSM into separate function (shared by MT and MO code paths) to avoid code duplication and simplify further modifications. Change-Id: I3563e11bebb58e656592df2ff7db96f41deaf735
2019-01-16Enable SMS-related log in VLR testsMax1-2/+1
The likely reason why it was disabled is due to paging_cb_mmsms_est_req() logging pointers which results in unstable log output. Fixing this allows us to track SMS-related regressions properly. Change-Id: I44ae817d9edb73d182ff33ff5a2fd942e224e344
2019-01-14Fix trans_has_conn() doxygen descriptionMax1-1/+1
Change-Id: Ica5e498e03d0a157a661e428dfd68739f572d073
2019-01-12gsm_04_08: Fix nullpointer derefPhilipp Maier1-2/+5
The pointers conn, conn->vsub and conn->vsub->last_tuple are checked, but before the check those pointers are already dereferenced during assignment. This defeats the purpose of the check. Lets dereference those pointers after the check. Fixes: CID#190404 Change-Id: Ice4992606f3799eac13154ec0b9f53e46d2e178e
2019-01-12gsm_04_08_cc.c: drop non-sensible error messagegsmevent admin1-2/+0
Change-Id: Icbf099e418281eb908e7916503f178ab7ea26ffe
2019-01-12err log: fully log MS supported A5 algos on mismatchNeels Hofmeyr1-2/+38
Change-Id: Icb18e0f0bb420de066e7eb8fc683f192ba2a7368
2019-01-12tweak fsm_msc_mgcp FSM and FI nameNeels Hofmeyr1-6/+4
Instead of MGW(MGW_99) use a name of msc-mgcp(MSISDN:2331_GERAN_A:00000017_trans99) 1. The FSM is communication towards an MGW, not the MGW itself. When reading combined logging (gsmtap_log), it is confusing to read 'MGW' in a log coming from the MSC. The API is also called msc_mgcp_*. 2. Calling the FSM instance 'MGW_' again doesn't make sense. 3. Indicate 'trans' before the trans_id (trans_id was already shown, but not indicated what it was). 4. Also indicate the actual subscriber's identification. 5. Also indicate the RAN connection and conn_id. This comes up while trying to understand a call coming in on an already established call: parsing the log with a human brain is near torture without this info, taking extremely long to get grips on. Change-Id: Ie5fc1ffb7eba0209fee4666a075655cd24d27473
2019-01-12mm_rx_id_resp(): use osmo_mi_name()Neels Hofmeyr1-6/+4
Change-Id: I6bb053def223ed698351ad9f52c1e36293df5d59
2019-01-12refactor log ctx for vlr_subscr and ran_connNeels Hofmeyr3-42/+84
ran_conn_get_conn_id(): instead of a talloc allocated string, return a static buffer in ran_conn_get_conn_id(). So far this function had no callers. Refactor ran_conn_update_id() API: during early L3-Complete, when no subscriber is associated yet, update the FSM Id by the MI type seen in the L3 Complete message: ran_conn_update_id_from_mi(). Later on set the vsub and re-update. Call vlr.ops->subscr_update when the TMSI is updated, so that log context includes the TMSI from then on. Enrich context for vlr_subscr_name and ran_conn fi name. Include all available information in vlr_subscr_name(); instead of either IMSI or MSISDN or TMSI, print all of them when present. Instead of a short log, rather have more valuable context. A context info would now look like: Process_Access_Request_VLR(IMSI-901700000014706:MSISDN-2023:TMSI-0x08BDE4EC:GERAN-A-3:PAGING_RESP) It does get quite long, but ensures easy correlation of any BSSAP / IuCS messages with log output, especially if multiple subscribers are busy at the same time. Print TMSI and TMSInew in uppercase hexadecimal, which is the typical representation in the telecom world. When showing the RAN conn id GERAN_A-00000017 becomes GERAN-A-23 - We usually write the conn_id in decimal. - Leading zeros are clutter and might suggest hexadecimal format. - 'GERAN-A' and 'UTRAN-Iu' are the strings defined by osmo_rat_type_name(). Depends: I7798c3ef983c2e333b2b9cbffef6f366f370bd81 (libosmocore) Depends: Ica25919758ef6cba8348da199b0ae7e0ba628798 (libosmocore) Change-Id: I66a68ce2eb8957a35855a3743d91a86299900834
2019-01-12rx CM Service Req: reject double use soonerNeels Hofmeyr1-7/+8
When a CM Service Req is being rejected, we should do so before changing the state of the current conn. Concerning multiple CM Service Requests: in fact we should store multiple requests, but first fix the status quo of rejecting multiple requests. Change-Id: I39209ee6662694aa054a2fc0d21eae76fb33e2f1
2019-01-12add LOG_RAN_CONN() to use the conn->fi->id for contextNeels Hofmeyr4-35/+50
For each conn, set a default logging category, to distinguish categories for BSSMAP and RANAP based conns. LOG_RAN_CONN(): log with the conn's default category, LOG_RAN_CONN_CAT(): log with a manually set category (mostly for keeping previous DMM logging on the same category). In some places, replace LOGP() using manual context with LOG_RAN_CONN(), and remove the manual context info, now provided by the conn->fi->id. This is loosely related to inter-BSC and inter-MSC handover: to speed up refactoring, I want to avoid the need for manual logging context and just use this LOG_RAN_CONN(). Change-Id: I0a7809840428b1e028df6eb683bc5ffcc8df474a
2019-01-12use osmo_lu_type_name() from libosmocoreNeels Hofmeyr1-12/+3
Change-Id: Ib562bb5fb272c0c3ae0849f32b28faa2c26f9bb7
2019-01-11libmsc/gsm_04_11.c: accept MT SMS messages over GSUPVadim Yanitskiy3-4/+154
Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2019-01-10Use explicit protocol discriminator for NC SS/USSD sessionMax1-6/+5
In gsm0911_rcv_nc_ss() we sometimes use pdisc parsed from msgb and sometimes constant. This function is only called when protocol discriminator is GSM48_PDISC_NC_SS so there's no point in parsing it again from msgb. Let's make it consistent and always use constant. Change-Id: Iae40bf9906fe676ff817c709120015fca4c9e042
2019-01-09msc_vty.c: make check-imei-rqd configurableOliver Smith1-0/+16
Related: OS#3189 Change-Id: Iee516b9cd7877b21207ce9a6d954109f19558163
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-30 10:10:26 +0000