Age | Commit message (Collapse) | Author | Files | Lines |
|
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
|
|
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
|
|
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
|
|
Change-Id: I2d55f9524b9fc15d661e5cb6b5df6d715c52ccf9
|
|
Pass trans around more functions as log context.
Add missing "rx" logging for two cases.
Change-Id: If79f724a2faca70023271398c618cfe490fb294e
|
|
Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
|
|
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
Change-Id: Ib06d030e8464abe415ff597d462ed40eeddef475
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Change-Id: Iea32a26673ebb57b18dc7e86ad321d9ed48e0948
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
Because sgs_server_open() already does this.
Change-Id: Ifea308645c7829691dbcf53e4f59841090119006
|
|
Change-Id: I80cd2e5645d6e391080376250c0853a3f3f821ef
|
|
Change-Id: I57b773659302ad4c92b6e670c6156e90a50189ba
|
|
Change-Id: I3392d8e184413203d27fc3d75371de4d66f205b9
|
|
We now have a nicer way to compose strings in a buffer than this.
(Cosmetic preparation for inter-MSC handover patch.)
Change-Id: I7813068032475deb3850af05f7ba5a6f652e7fa2
|
|
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
|
|
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>
|
|
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
|
|
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
|
|
Change-Id: I82645708dd27864cf33ea9cc993ead0983415602
|
|
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
|
|
Change-Id: I16f2d29855eb715eccbdc5def225f43c110fab8e
|
|
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
|
|
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
|
|
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
|
|
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)
|
|
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)
|
|
The SGS_STATE_TS11 is not for counters, it's for timers!
Change-Id: Ifbb1a37e644ae8bf8e7959f6f6cd6403ac1f2f1b
Fixes: CID#190872 Out-of-bounds read (OVERRUN)
|
|
Change-Id: I18dfd08ea0857f2751164a295dd9de20a2024ac3
Fixes: CID#190874
|
|
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
|
|
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
|
|
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
|
|
Change-Id: I8a15c9baae2071569e2ecc4635ddaf5a0001f959
|
|
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
|
|
Change-Id: I52787120d5ec59897329d28eab28e0fda3d0f44f
|
|
Change-Id: I80238d89e95b6fd791961c48de80aac69ff5b0e9
|
|
Change-Id: I2d3a6334f49989bedbb1430d26ffad8b61dfd873
|
|
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
|
|
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
|
|
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
|
|
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
|