aboutsummaryrefslogtreecommitdiffstats
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2019-04-12enable osmo_fsm_term_safely(), apply logging changesNeels Hofmeyr1-0/+2
Start using osmo_fsm_term_safely(true), the recently added feature of libosmocore's fsm.c. Deallocates in slightly changed order and with slightly modified logging. Adjust test expectations. Depends: I8eda67540a1cd444491beb7856b9fcd0a3143b18 (libosmocore) Change-Id: I195a719d9ec1f6764ee5a361244f59f0144dc253
2019-04-11sgs_iface: fix nullpointer dereferencePhilipp Maier1-2/+2
The function sgs_tx() is using the sgs connection pointer as context, even though it has done a check for a nullpointer in the line before. This is very prone to lead into a segfault when the SGs connection dies. Change-Id: I88b95e3f8cd35241ad68f08d94c6ad7067b842e6 Related: OS#3859
2019-04-10smpp_smsc: Call destroy_tlv() when using build_tlv()Harald Welte1-2/+7
The libsmpp34 build_tlv() function is allocating dynamic memory which we need to release again by calling destroy_tlv(). Change-Id: Iacc74c9948fb10fa79c0dd7b0cb72d4adbefdeed Closes: OS#3912
2019-04-09sms_queue: Print dest msisdn instead of unknown subscriberPau Espin Pedrol1-2/+4
If subscriber is NULL, vlr_subscr_msisdn_or_name() returns string "unknown", which is less informative than printing destination msisdn expected for the queued sms. This happens for instance if an sms was queued with Store&Forward and destination subscriber is not currently registered Change-Id: I4b8b54c9c41b17d4e1fa7ece63aa91a98036ef11
2019-04-07vlr_sgs: start lu expiration timer on sgs eps detachPhilipp Maier1-0/+14
When the subscriber is detached from SGs services (but not from 2g services). Then the subscriber essentially becomes a regular 2g subscriber, which means thet the lu expiration timer needs to be started. Change-Id: If95c63706dc1c5a537f7cd1b6481252427cbf234 Related: OS#3614
2019-04-07vlr_sgs: fix SGs IMSI detech from non EPS servicesPhilipp Maier1-0/+12
When the subscriber is detached from non EPS services while the SGs-association is not SGs-NULL, it needs to be removed from the VLR database. Change-Id: I575cf6036ad39468f590b2d57a06cd3512a4c31c Related: OS#3614
2019-04-01libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()Vadim Yanitskiy1-1/+6
A memleak has been noticed after executing some of TTCN-3 test cases. For example, the following ones: - MSC_Tests.TC_lu_and_mo_sms, - MSC_Tests.TC_lu_and_mt_sms. The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends a MO SMS to a non-attached subscriber with MSISDN 12345, so this message is getting stored in the SMSC's database. As soon as the SMSC's queue is triggered, sms_submit_pending() would retrieve pending messages from the database by calling function smsq_take_next_sms() in loop and attempt to deliver them. This function in it's turn checks whether the subscriber is attached or not. If not, the allocated 'gsm_sms' structure would not be free()ed! Therefore, every time smsq_take_next_sms() is called, one 'gsm_sms' structure for an unattached subscriber is leaked. Furthermore, there is a unit test called 'sms_queue_test', that actually does cover smsq_take_next_sms() and was designed to catch some potential memory leaks, but... In order to avoid emulating the low-level SQLite API, the unit test by design overwrites some functions of libmsc, including db_sms_get_next_unsent_rr_msisdn(), that is being called by smsq_take_next_sms(). The problem is that the original function in libmsc does allocate a 'gsm_sms' structure on heap (using talloc), while the overwriting function did this statically, returning a pointer to stack. This critical difference made it impossible to spot the memleak in smsq_take_next_sms() during the unit test execution. Let's refactor 'sms_queue_test' to use dynamic memory allocation, and finally fix the evil memleak in smsq_take_next_sms(). Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a Closes: OS#3860
2019-03-29Write configuration correctly from vty (alert notifications)Keith1-2/+2
The default is [yes] alert-notifications, therefore write "no alert-notifications" in the case that this has been set, in order to preserve configuration after write is called from vty. Change-Id: I079aea96ee83fbf04f782dcab344d41a4ef04657
2019-03-28libmsc: fix: properly initialize the SGs serverVadim Yanitskiy3-8/+16
It was observed that the SGs server is started before the actual VTY configuration is parsed. For example: sgs local-port 9999 local-ip 127.0.0.1 vlr-name vlr.example.net produces the following debug output: <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=0.0.0.0:29118 DLSS7 NOTICE <001e> osmo_ss7.c:1284 0: ASP Restart for server not implemented yet! DSGS NOTICE <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=0.0.0.0:9999 DSGS NOTICE <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=127.0.0.1:9999 DMNCC DEBUG <0004> msc_main.c:604 Using internal MNCC handler. The first startup is triggered by sgs_iface_init(), before reading the VTY configuration, so the logging style is different. The next two calls to sgs_server_open() are triggered during reading of the VTY configuration by cfg_sgs_local_port() and cfg_sgs_local_ip(). Let's avoid starting the SGs server three times, and do it once, after the VTY configuration is parsed. Also, keep the possibility to change the binding parameters at run-time. Change-Id: Ie0c31205ac48be7e50d0380a89833771b2708da4
2019-03-28libmsc/sgs_vty.c: don't print SGs socket error twiceVadim Yanitskiy1-6/+2
Because sgs_server_open() already does this. Change-Id: Ifea308645c7829691dbcf53e4f59841090119006
2019-03-28libmsc/sgs_iface.c: register sgs_vlr_reset_fsm on DSO loadVadim Yanitskiy1-1/+5
Change-Id: I80cd2e5645d6e391080376250c0853a3f3f821ef
2019-03-28libmsc/sgs_iface.c: fix copy-paste errorVadim Yanitskiy1-1/+1
Change-Id: I57b773659302ad4c92b6e670c6156e90a50189ba
2019-03-24vlr_subscr_name(): use OSMO_STRBUFNeels Hofmeyr1-9/+5
We now have a nicer way to compose strings in a buffer than this. (Cosmetic preparation for inter-MSC handover patch.) Change-Id: I7813068032475deb3850af05f7ba5a6f652e7fa2
2019-03-19msc_vty: add missing header filePhilipp Maier1-0/+1
The symbol GSM0808_SPEECH_FULL_BM is used in msc_vty.c, but gsm_08_08.h, where the symbol is declared is not included. Change-Id: I31a8894031aa2321d7dbf2586d076bc303247278
2019-03-19libvlr: Allow 2G auth tuples to be re-used without going through AUTHSylvain Munaut5-2/+38
If the key_seq we get in the first messages matches the last_tuple, then both we and the MS already know the key to use and we don't need the AUTH REQUEST/RESPONSE cycle. Security wise ... not so good, and so IMHO the 'auth required' option in the MSC should always be set. But this allows to turn on ciphering on a channel without doing any MM transaction, and so the MS doesn't turn on the T3240 timer which allows to have a ciphered silent-call channel that won't timeout. Change-Id: Ief840a2ae7a0ffd2bf0bf726f209a79e3f787646 Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
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 Welte21-20/+2555
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-18 20:46:58 +0000