aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2019-05-06doc/interMSC_HO_GSUP_msgs.txtneels/hoNeels Hofmeyr1-0/+89
Change-Id: I8f830354cb25a2966211805d9448c454e509ae27
2019-05-06mncc: send payload type matching chosen codecNeels Hofmeyr2-8/+29
Change-Id: Id32f32d77d24b753adb96b5393c0363439e312c2
2019-05-06gsm_04_11: use gsm48_decode_bcd_number2(), evaluate rcNeels Hofmeyr1-2/+6
Avoid deprecation warning: use gsm48_decode_bcd_number2() instead of gsm48_decode_bcd_number(). Validate the return value and add error handling. Change-Id: Ibef71c46d72d2d43123e68f73e5ed554a69243d8
2019-05-06rename bscconfig.h to config.h, cleanupNeels Hofmeyr10-13/+9
Get rid of the legacy name bscconfig.h from osmo-nitb times. Remove the #include from some of the files that aren't actually using it. Instead of '#include "../../config.h"', use plain '#include "config.h"' because we're anyway passing $top_srcdir as -I during compilation. Change-Id: Id4f683be1f36f0630c83da54e02868aae847aeec
2019-05-06large refactoring: support inter-BSC and inter-MSC HandoverNeels Hofmeyr151-22975/+35637
3GPP TS 49.008 '4.3 Roles of MSC-A, MSC-I and MSC-T' defines distinct roles: - MSC-A is responsible for managing subscribers, - MSC-I is the gateway to the RAN. - MSC-T is a second transitory gateway to another RAN during Handover. After inter-MSC Handover, the MSC-I is handled by a remote MSC instance, while the original MSC-A retains the responsibility of subscriber management. MSC-T exists in this patch but is not yet used, since Handover is only prepared for, not yet implemented. Facilitate Inter-MSC and inter-BSC Handover by the same internal split of MSC roles. Compared to inter-MSC Handover, mere inter-BSC has the obvious simplifications: - all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc instance, - messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface (GSUP), - no call routing between MSC-A and -I via MNCC necessary. This is the largest code bomb I have submitted, ever. Out of principle, I apologize to everyone trying to read this as a whole. Unfortunately, I see no sense in trying to split this patch into smaller bits. It would be a huge amount of work to introduce these changes in separate chunks, especially if each should in turn be useful and pass all test suites. So, unfortunately, we are stuck with this code bomb. The following are some details and rationale for this rather huge refactoring: * separate MSC subscriber management from ran_conn struct ran_conn is reduced from the pivotal subscriber management entity it has been so far to a mere storage for an SCCP connection ID and an MSC subscriber reference. The new pivotal subscriber management entity is struct msc_a -- struct msub lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however use msc_a, since MSC-A is where all the interesting stuff happens. Before handover, msc_i is an FSM implementation that encodes to the local ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM implementation that instead forwards via/from GSUP. Same goes for the msc_a struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the msc_a->fi is an FSM implementation that merely forwards via/from GSUP. * New SCCP implementation for RAN access To be able to forward BSSAP and RANAP messages via the GSUP interface, the individual message layers need to be cleanly separated. The IuCS implementation used until now (iu_client from libosmo-ranap) did not provide this level of separation, and needed a complete rewrite. It was trivial to implement this in such a way that both BSSAP and RANAP can be handled by the same SCCP code, hence the new SCCP-RAN layer also replaces BSSAP handling. sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN connections. A set of callback functions provides implementation specific details. * RAN Abstraction (BSSAP vs. RANAP) The common SCCP implementation did set the theme for the remaining refactoring: make all other MSC code paths entirely RAN-implementation-agnostic. ran_infra.c provides data structures that list RAN implementation specifics, from logging to RAN de-/encoding to SCCP callbacks and timers. A ran_infra pointer hence allows complete abstraction of RAN implementations: - managing connected RAN peers (BSC, RNC) in ran_peer.c, - classifying and de-/encoding RAN PDUs, - recording connected LACs and cell IDs and sending out Paging requests to matching RAN peers. * RAN RESET now also for RANAP ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide proper RESET handling, which it so far duly ignores. (TODO) * RAN de-/encoding abstraction The RAN abstraction mentioned above serves not only to separate RANAP and BSSAP implementations transparently, but also to be able to optionally handle RAN on distinct levels. Before Handover, all RAN messages are handled by the MSC-A role. However, after an inter-MSC Handover, a standalone MSC-I will need to decode RAN PDUs, at least in order to manage Assignment of RTP streams between BSS/RNC and MNCC call forwarding. ran_msg.h provides a common API with abstraction for: - receiving events from RAN, i.e. passing RAN decode from the BSC/RNC and MS/UE: struct ran_dec_msg represents RAN messages decoded from either BSSMAP or RANAP; - sending RAN events: ran_enc_msg is the counterpart to compose RAN messages that should be encoded to either BSSMAP or RANAP and passed down to the BSC/RNC and MS/UE. The RAN-specific implementations are completely contained by ran_msg_a.c and ran_msg_iu.c. In particular, Assignment and Ciphering have so far been distinct code paths for BSSAP and RANAP, with switch(via_ran){...} statements all over the place. Using RAN_DEC_* and RAN_ENC_* abstractions, these are now completely unified. Note that SGs does not qualify for RAN abstraction: the SGs interface always remains with the MSC-A role, and SGs messages follow quite distinct semantics from the fairly similar GERAN and UTRAN. * MGW and RTP stream management So far, managing MGW endpoints via MGCP was tightly glued in-between GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP streams between different RAN peers by moving to object-oriented implementations: implement struct call_leg and struct rtp_stream with distinct FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose. Instead of implementing a sequence of events with code duplication for the RAN and CN sides, the idea is to manage each RTP stream separately by firing and receiving events as soon as codecs and RTP ports are negotiated, and letting the individual FSMs take care of the MGW management "asynchronously". The caller provides event IDs and an FSM instance that should be notified of RTP stream setup progress. Hence it becomes possible to reconnect RTP streams from one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP peers (inter-MSC Handover) without duplicating the MGCP code for each transition. The number of FSM implementations used for MGCP handling may seem a bit of an overkill. But in fact, the number of perspectives on RTP forwarding are far from trivial: - an MGW endpoint is an entity with N connections, and MGCP "sessions" for configuring them by talking to the MGW; - an RTP stream is a remote peer connected to one of the endpoint's connections, which is asynchronously notified of codec and RTP port choices; - a call leg is the higher level view on either an MT or MO side of a voice call, a combination of two RTP streams to forward between two remote peers. BSC MGW PBX CI CI [MGW-endpoint] [--rtp_stream--] [--rtp_stream--] [----------------call_leg----------------] * Use counts Introduce using the new osmo_use_count API added to libosmocore for this purpose. Each use token has a distinct name in the logging, which can be a globally constant name or ad-hoc, like the local __func__ string constant. Use in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count API. * FSM Timeouts Introduce using the new osmo_tdef API, which provides a common VTY implementation for all timer numbers, and FSM state transitions with the correct timeout. Originated in osmo-bsc, recently moved to libosmocore. Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore) Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore) Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore) Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp) I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw) Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw) I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw) Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
2019-05-06fix various missing line endings in loggingNeels Hofmeyr3-4/+4
Change-Id: I013eb0eeb5673c06034465020e5dc5230f45ddf5
2019-04-26vlr subscr get/put: also check against NULLNeels Hofmeyr1-2/+2
Change-Id: I36929a4ba4abb46909181068d1d0af967b1f5a94
2019-04-25libmsc/gsm_04_11.c: clarify implicit CP-ACK handlingVadim Yanitskiy1-4/+6
Change-Id: I3c5327a5019590c65d0ccb33a52f07b3988ea952
2019-04-25libmsc/db.c: print info about database name and libdbi versionVadim Yanitskiy1-0/+3
Change-Id: Iaed452548eb2d847738b78d3489bf6f507a2e3c1
2019-04-25configure.ac: drop useless SQLite3 dependencyVadim Yanitskiy2-6/+0
We don't use SQLite3 directly, we use libdbi and libdbdsqlite3. Change-Id: Ibf4eb53e60a2957eca99a2c8e613f75a8c43ac89
2019-04-17vlr_sgs_fsm: make sure vsub is marked used when LA is presentPhilipp Maier1-1/+7
When the LU is accepted and the subscriber (vsub) is not claimed as "in use" in the ref counting system. - Make sure vlr_subscr_get() is called when the LU is accepted. Change-Id: Iba90be095569cc5212c61ab8e8a9bfd4ae51fd44 Related OS#3934
2019-04-15configure.ac: drop rudimentary check for -fvisibility=hiddenVadim Yanitskiy1-12/+0
This looks like a rudiment from OpenBSC, where we have: #define BSC_API __attribute__((visibility("default"))) However, we don't use this attribute in OsmoMSC. Change-Id: Ie2f18e9b47eca478f6e4702606068814546e34ce
2019-04-15smpp: fix vlr_subscr use count bugsNeels Hofmeyr1-1/+8
In smpp_openbsc.c submit_to_sms(), "get" the appropriate use count upon assigning sms->receiver, fixing a -1 use count upon sms_free(). Also, avoid a "put" of a NULL subscriber in the same function. Related: OS#3930 Change-Id: Idaf01cd3cfa08088ce0d543d0576db957dc94262
2019-04-13Allow MME name preformatted as FQDN in SGsAPOmar Ramadan1-0/+6
Change-Id: I2d55f9524b9fc15d661e5cb6b5df6d715c52ccf9
2019-04-12gsm_04_08_cc: improve logging for CC transNeels Hofmeyr1-9/+12
Pass trans around more functions as log context. Add missing "rx" logging for two cases. Change-Id: If79f724a2faca70023271398c618cfe490fb294e
2019-04-12add LOG_TRANS, proper context for all transactionsNeels Hofmeyr14-628/+620
Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-04-12vlr_subscr: use osmo_use_countNeels Hofmeyr45-2287/+2350
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore) Change-Id: Ib06d030e8464abe415ff597d462ed40eeddef475
2019-04-12sms queue: avoid repeated Paging for a failed SMSNeels Hofmeyr1-1/+0
So far, sms_pending_failed() starts a new sms_queue_trigger() run. The intention behind that might have been to fill up the queue when sending SMS has failed, but the practical effect is actually bad: As current ttcn3-msc-test runs show, a failed MT SMS gets triggered multiple times in short succession, i.e. osmo-msc repeatedly sends Paging Requests for the same subscriber. This special case happens actually only when there are few SMS still in the DB to be delivered. In the TTCN3 test, there is exactly one MT SMS for one subscriber, and retriggering the queue brings up the same SMS every time. See f_tc_lu_and_mt_sms_paging_and_nothing() and f_tc_sgsap_mt_sms_and_nothing() which say: "/* Expect the MSC to page exactly 10 times before giving up */" This is bad because an MSC should send a Paging Request exactly once. Retrying failed Paging is clearly the task of the BSC, not the MSC. The remaining code around Paging correctly follows this paradigm, but this retrigger doesn't. Do not immediately trigger the SMS queue on a failed MT SMS. Instead, leave it up to the periodical SMS queue trigger to decide. This patch will cause the MT SMS tests in ttcn3-msc-tests to fail, because the test expectations are bogus. The patch fixing the test run is listed 'Related' below. Related: I7dce12942a65eaaf97f78ca69401c7f93faacb9e (osmo-ttcn3-hacks) Change-Id: I24bf9f1c1167efe1080ae4cf47ed2ef0bd981e49
2019-04-12enable osmo_fsm_term_safely(), apply logging changesNeels Hofmeyr14-1140/+627
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-08msc/gsm_data.h: drop unused SMS_HDR_SIZE macroVadim Yanitskiy1-1/+0
Change-Id: Iea32a26673ebb57b18dc7e86ad321d9ed48e0948
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-01tests/sms_queue: track the use of NULL talloc memory contextsVadim Yanitskiy2-0/+7
As we don't initialize all talloc contects of libmsc, let's make sure that there is nothing left in the NULL context after the unit test execution is finished. Change-Id: I99fd82750aff376e4d90eaa2402ec41f4d59ef86
2019-04-01libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()Vadim Yanitskiy2-9/+37
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-27debian/control: Fix typoPau Espin Pedrol1-1/+1
Change-Id: I3392d8e184413203d27fc3d75371de4d66f205b9
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 Munaut6-2/+40
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 Munaut3-21/+158
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 Yanitskiy2-6/+4
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-25debian: depend on libdbd-sqlite3Oliver Smith1-1/+1
Make sure that we don't fail at startup with: <0009> db.c:621 Failed to create database connection to sqlite3 db 'sms.db'; Is the sqlite3 database driver for libdbi installed on this system? Tested by building the Debian package and looking at its depends. Related: OS#3771 Change-Id: I7c099212a6ad7d87978c3dce63ce7385d8076bd1
2019-02-20libmsc/gsm_09_11.c: implement guard timer for NCSS sessionsVadim Yanitskiy6-0/+90
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-24 16:22:59 +0000