For all CC type transaction logging, log the current trans->cc.state string for
all LOG_TRANS*() logging.
Change-Id: I67be12c74c679ce684f8c0b9b4e0d96299849dc6
The HLR might respond with a specific GMM cause code. E.g. roaming not
allowed which needs to be passed down the layers.
Change-Id: I9af515dc52834b7c57c42fc3a76ee2c682734e2a
When a vlr_subscr receives an Send Auth Info result, properly check whether the
subscriber has an auth_fsm.
Before, a missing auth_fsm would crash osmo-msc with:
vlr.c:762 Trying to dispatch event 1 to non-existent FSM instance!
Related: OS#4191
Change-Id: I1995d8f68cfde1140968fb9a97bd054de950de2e
When pagig for a CS-Call via SGs times out, the MME expects to be
informed about this via an SGsAP-SERVICE-ABORT-REQUEST, make sure this
message is sent, but only for CS-Fallback calls.
Change-Id: I3f8f153afe24cf2efa245713509bdc8488902877
Depends: osmo-ttcn3-hacks I99950a17ccf26aaa0eebded5480f33be4c57586a
Related: OS#3614
3GPP TS 29.118, chapter 7.5 states that unknown TLV elements should be
ignored rather than that the whole message is discarded a STATUS message
is sent. Lets turn the returncode check of the tlv_parse() call into a
log message and continue normally.
Change-Id: Ic6714451ad970043d4765f8420d753daf5294a44
Related: OS#4214
When an MS returns the IMEISV in the BSSMAP Cipher Mode Complete message in
the Layer 3 Message Contents IE, do not re-invoke the decode_cb() a second
time, but instead point to it from the ran_msg.cipher_mode_complete struct.
When the MSC-A decodes the Ciphering Mode Complete message, it always wants to
also decode the enclosed DTAP from the Layer 3 Message Contents IE. However,
when the MSC-I preliminarily decodes messages, it often just wants to identify
specific messages without fully acting on them, let alone dispatching RAN_UP_L2
events more than once. So leave it up to the supplied decode_cb passed to
ran_dec_l2() implementations to decide whether to decode the DTAP.
In msc_a.c hence evaluate the DTAP by passing a msgb to msc_a_up_l3(), which
will evaluate the RR Ciphering Mode Complete message found in the BSSMAP Cipher
Mode Complete's Layer 3 Message Contents IE.
Particularly, the previous choice of calling the decode_cb a second time for
the enclosed DTAP caused a header/length parsing error: the second decode_cb
call tried to mimick DTAP by overwriting the l3h pointer and truncating the
length of the msgb, but subsequently ran_a_decode_l2() would again derive the
l3h from the l2h, obliterating the intended re-interpretation as DTAP, and
hence the previous truncation caused error messages on each and every Cipher
Mode Complete message, like:
DBSSAP ERROR libmsc/ran_msg_a.c:764 msc_a(IMSI-26242340300XXXX:MSISDN-XXXX:TMSI-0xA73E055A:GERAN-A-77923:LU)[0x5563947521e0]{MSC_A_ST_AUTH_CIPH}: RAN decode: BSSMAP: BSSMAP data truncated, discarding message
This error was seen a lot at CCCamp2019.
Modifying the msgb was a bad idea to begin with, the approach taken in this
patch is much cleaner.
Note that apparently many phones include the IMEISV in the Cipher Mode Complete
message even though the BSSMAP Cipher Mode Command did not include the Cipher
Response Mode IE. So, even though we did not specifically ask for the Cipher
Mode Complete to include any identity, many MS default to including the IMEISV
of their own accord. Reproduce: attach to osmo-msc with ciphering enabled using
a Samsung Galaxy S4mini.
Related: OS#4168
Change-Id: Icd8dad18d6dda24d075dd8da72c3d6db1302090d
It's always set to OSMO_TERM_ERROR. Move the assignment to the caller.
In prepartion to use gmm_cause_to_fsm_and_mm_cause() in vlr_auth_fsm.
Change-Id: Ie4720ad40ef7bcfc528d8d63bfc606c9c0545fb2
We sometimes see errors like
libmsc/msc_a.c:361 msc_a(...){MSC_A_ST_RELEASING}: transition to state MSC_A_ST_RELEASING not permitted!
i.e. changing state to the state msc_a is already in.
Ignore re-entering the same state for most state changes. However, there is one
state change in msc_a where re-entering the MSC_A_ST_VALIDATE_L3 is necessary
to start the timeout.
Hence add msc_a_state_chg_always() and use that for re-entering
MSC_A_ST_VALIDATE_L3. Change msc_a_state_chg() to skip no-op state changes.
This should silence all no-op state change error messages for msc_a.
Related: OS#4169
Change-Id: I0c74c10b5fa7bbdd6ae3674926cc0393edf15a35
If an ID Response comes in during a non-LU L3 Complete (Paging or CM Service
Request), no event needs to be dispatched. So far vlr_subscr_rx_id_resp()
logged a NOTICE "gratuitous ID RESPONSE?!?" if no lu_fsm is present.
An ID Response can come in particularly as payload with a BSSMAP Cipher Mode
Complete message, even though osmo-msc didn't explicitly ask for it.
It is not an error to get a Cipher Mode Complete containing an ID Response
during Paging or CM Service Request, so remove the confusing log message.
Related: OS#4168 (only loosely related)
Change-Id: I8a5b8735eb41cd0976c7ab32cdd55440d3ef70ac
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
Distinguish the enclosed DTAP RR Ciphering Mode Complete message from the outer
BSSMAP Cipher Mode Complete message in the DEBUG log.
Change-Id: I80c69b491e2ddb932bc4295a01caaf6a903b1fe4
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
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
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
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
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
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
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
Event VLR_ULA_E_ID_IMEISV is listed as permitted in VLR_ULA_S_WAIT_LU_COMPL,
but is missing from the switch() on the incoming event. So, sending an IMEISV
identity during the WAIT_LU_COMPL state would crash osmo-msc.
When receiving an IMEISV, vlr_subscr_set_imeisv() in turn calls
vlr_subscr_set_imei(), so as far as the lu_fsm is concerned, receiving an
IMEISV is identical to receiving an IMEI, and it can continue to send a Check
IMEI request to the HLR. Thus simply add VLR_ULA_E_ID_IMEISV to the
VLR_ULA_E_ID_IMEI switch case.
Change-Id: I11106cb108a4b1406ff9a8b8ff5761440a274dad
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
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
Change-Id: Ia2b24ffd7f9cbb271fcdb979b851f3a07b9d6d3e
Related: OS#4138
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
Don't call tx_lu_rej() in the "vlr_lu_compl" FSM. It is always getting
called in the parent "lu" FSM and is therefore redundant:
_vlr_lu_compl_fsm_done(fi, VLR_FSM_RESULT_FAILURE, cause)
-> osmo_fsm_inst_state_chg(fi, LU_COMPL_VLR_S_DONE, 0, 0)
-> vlr_lu_compl_fsm_dispatch_result()
-> lu_fsm_wait_lu_compl()/lu_fsm_wait_lu_compl_standalone()
-> lu_fsm_failure()
-> lfp->vlr->ops.tx_lu_rej()
I have noticed the bug with the TTCN3 tests. This patch fixes
TC_lu_imsi_auth_tmsi_check_imei_{nack,err} after stricter checking
in [1] and also TC_iu_mo_crcx_ran_reject.
[1] I836f76242463789c4c003feec757714827f2a31b (osmo-ttcn3-hacks)
Change-Id: I127b27937613ea0ff29d67991c0414fca6d441d9
osmo_counter will be soon deprecated. Use the newer and more flexible
osmo_stat_item instead.
Depends on: Id2462c4866bd22bc2338c9c8f69b775f88ae7511 (libosmocore)
Change-Id: I6a20123b263f4f808153794ee8a735092deb399e
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
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
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
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
When periodic Location Update is disabled (T3212 = 0), it was noticed
that OsmoMSC does expire subscribers quite soon - after 60 seconds
(VLR_SUBSCRIBER_LU_EXPIRATION_INTERVAL) since the last LU.
In order to avoid that, we need to check T3212 timer value in
vlr_subscr_expire_lu(), and if it's equal to 0, do not expire
anybody until the explicit IMSI Detach.
Change-Id: I2ead2241a3394dbdd5417f4554190df3fd698af2
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
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
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
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
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
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
reported by _dev_zero in #osmocom
Change-Id: Ib5679ab5d06b6ef735725b4a68eeb1e9cbcc11ba
Depends-On: libosmocore I52b9f6b5f3e96d85a390ba2af21d7814df8aaeec
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
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
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
Found using the new TC_mt_ussd_for_unknown_subscr test case.
Change-Id: Id00a99b713a6b97c455b8e6ae49abea163e8281f
Related: (TTCN-3) Id35cd3ec15d1bab15260312d7bbb41e2d10349fe
Related: OS#2931
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
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
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
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
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
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
Catched by ASan on db_sms_test unit test:
DDB NOTICE test_db_sms_get('Empty TP-UD'): osmo-msc/src/libmsc/db.c:796:2: runtime error: null pointer passed as argument 2, which is declared to never be null
That happens on empty PDU because dbi_result_get_binary returns NULL,
and sms->user_data_len is 0, so it's harmless but we can avoid calling
mempcy and make ASan happy.
Change-Id: I545967464c406348b8505d1729213cfb4afcd3e2
Thanks to db_sms_test, it was discovered that storing an SMS with
empty TP-User-Data (TP-UDL=1) causes buffer overruns in libdbi
and it's SQLite3 driver (libdbdsqlite3):
DDB NOTICE test_db_sms_store('Empty TP-UD'): ==7791== Invalid write of size 2
==7791== at 0x857DC60: dbd_quote_binary (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==7791== by 0x5B2B321: dbi_conn_quote_binary_copy (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==7791== by 0x4073B1: db_sms_store (db.c:701)
==7791== by 0x405BB5: test_db_sms_store (db_sms_test.c:310)
==7791== by 0x405BB5: main (db_sms_test.c:546)
==7791== Address 0x7ed1cf0 is 0 bytes after a block of size 0 alloc'd
==7791== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7791== by 0x857DC4B: dbd_quote_binary (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==7791== by 0x5B2B321: dbi_conn_quote_binary_copy (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==7791== by 0x4073B1: db_sms_store (db.c:701)
==7791== by 0x405BB5: test_db_sms_store (db_sms_test.c:310)
==7791== by 0x405BB5: main (db_sms_test.c:546)
...
DDB NOTICE test_db_sms_get('Empty TP-UD'): ==8051== Invalid read of size 1
==8051== at 0x5B30510: _dbd_decode_binary (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==8051== by 0x857D957: dbd_fetch_row (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==8051== by 0x5B2C86E: dbi_result_seek_row (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==8051== by 0x40828F: next_row (db.c:188)
==8051== by 0x40828F: db_sms_get (db.c:805)
==8051== by 0x406C29: test_db_sms_get (db_sms_test.c:390)
==8051== by 0x405C14: main (db_sms_test.c:547)
==8051== Address 0x8f74641 is 0 bytes after a block of size 1 alloc'd
==8051== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8051== by 0x5DBEB49: strdup (strdup.c:42)
==8051== by 0x857D93C: dbd_fetch_row (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==8051== by 0x5B2C86E: dbi_result_seek_row (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==8051== by 0x40828F: next_row (db.c:188)
==8051== by 0x40828F: db_sms_get (db.c:805)
==8051== by 0x406C29: test_db_sms_get (db_sms_test.c:390)
==8051== by 0x405C14: main (db_sms_test.c:547)
==8051==
success, as expected
DDB NOTICE verify_sms('Empty TP-UD'): user_data_len mismatch: E0 vs A3
Apparently, dbi_conn_quote_binary_copy() doesn't properly handle
zero-length input. Let's guard against this.
Observed with:
- libdbi-dev 0.9.0-1
- libdbd-sqlite3:amd64 0.9.0-2ubuntu2
Change-Id: If0b2bb557118c5f0e520a2e6c2816336f6028661
Since OsmoMSC has built-in SMSC, it needs to store the messages
somewhere. Currently we use libdbi and SQLite3 back-end for that.
For a long time, the db_sms_* API remained uncovered by unit tests.
This change aims to fix that, and does cover the following calls:
- db_sms_store(),
- db_sms_get(),
- db_sms_get_next_unsent(),
- db_sms_mark_delivered(),
- db_sms_delete_sent_message_by_id(),
- db_sms_delete_by_msisdn(),
- db_sms_delete_oldest_expired_message().
Due to performance reasons, the test database is initialized in
RAM using the magic filename ':memory:'. This is a feature of
SQLite3 (and not libdbi), see:
https://www.sqlite.org/inmemorydb.html
Of course, this unit test helped to discover some problems:
1) Storing an SMS with empty TP-User-Data (TP-UDL=0) causes
buffer overruns in both db_sms_store() and db_sms_get().
2) TP-User-Data-Length is always being interpreted in octets,
regardless of DCS (Data Coding Scheme). This results in
storing garbage in the database if the default 7-bit
encoding is used. Fortunately, the 'user_data' buffer
in structure 'gsm_sms' is large emough, so we don't
experience buffer overruns.
3) db_sms_delete_oldest_expired_message() doesn't work
as expected. Instead of removing the *oldest* expired
message, it tries to remove the *newest* one.
The current test expectations do reflect these problems.
All of them will be fixed in the follow-up patches.
Change-Id: Id94ad35b6f78f839137db2e17010fbf9b40111a3
In the most cases we need to check whether particular char buffer
is empty or not. Using strlen() for that involves more CPU power,
so let's just check the first character against '\0'.
Change-Id: I8728876b80c870e82247e6e56f719e10ed322a95
The current way of printing subscriber, connection, and transaction
info is ugly (sorry) and has several problems:
- the terminal width should be large enough to fit quite long lines,
otherwise the output is unreadable and looks misaligned;
- some fields (such as subscriber name) can be larger than it's
expected, so either they're getting truncated, or again, the
output is misaligned and unreadable;
- adding new info fields would require one to think about the
alignment and would make the output even more cumbersome.
Here is an example output of 'show connection' command:
_Subscriber_______________________________________ _LAC_ _RAN___________________ _MSC-A_state_________ _MSC-A_use_
IMSI-123456789012345:MSISDN-12345:TMSI-0x12345678 1 GERAN-A-4294967295:A5-3 WAIT_CLASSMARK_UPDATE 2=cm_service,trans_cc
IMSI-123456789012356:MSISDN-234567:TMSI-0x123ABC78 65535 UTRAN-Iu-4294967295 COMMUNICATING 2=cm_service,trans_sms
IMSI-262073993158656:MSISDN-123456:TMSI-0x493026BA 1 GERAN-A-1 MSC_A_ST_COMMUNICATING 1=1 (silent_call)
Another 'show subscriber' command mixes the information about
subscriber, its connections and transactions without any alignment,
what also decreases the readability.
This change introduces a hierarchical approach, based on the old
'field per line' formatting. First of all, the VTY commands were
extended with optional flags:
show connection [trans]
show subscriber cache [(conn|trans|conn+trans)]
show subscriber TYPE ID [(conn|trans|conn+trans)]
so it can be decided, whether to print child connections and/or
transaction, or not. For example:
show connection trans
would print all connections and their child transactions with
hierarchical alignment:
Connection #00:
Subscriber: IMSI-262073993158656:MSISDN-123456:TMSI-0x76760B75
RAN connection: GERAN-A-1
RAN connection state: MSC_A_ST_COMMUNICATING
LAC / cell ID: 1 / 0
Use count total: 1
Use count: 1 (silent_call)
Transaction #00:
Unique (global) identifier: 0x00000000
GSM 04.07 identifier (MT): 0
Type: silent-call
another example is:
show subscriber cache conn+trans
which would print all known subscribers,
their active connections and transactions:
Subscriber #00:
MSISDN: 123456
LAC / cell ID: 1 / 0
RAN type: GERAN-A
IMSI: 262073993158656
TMSI: 76760B75
...
Connection:
RAN connection: GERAN-A-1
RAN connection state: MSC_A_ST_COMMUNICATING
...
Transaction #00:
Unique (global) identifier: 0x00000000
GSM 04.07 identifier (MT): 0
Type: silent-call
Transaction #01:
Unique (global) identifier: 0x00000001
GSM 04.07 identifier (MO): 0
Type: SMS
Transaction #02:
Unique (global) identifier: 0x00000002
GSM 04.07 identifier (MT): 0
Type: SMS
Please note that we don't print redundant info in child nodes
(i.e. connection and transaction info), such as subscriber name
in connection info, nor connection name in transaction info - it
is clear from the hierarchical formatting.
Change-Id: I5e58b56204c3f3d019e8d4c3c96cefdbb4af4d47
The HLR (which is connected via the GSUP interface) may fail and
disconnect. On the next location update the VLR will try to talk to the
HLR and fail. This failure event is not communicated towards the SGs
related code and the SGs-association will remain in the LA-PRESENT state
forever. Lets add code to report the problem to the SGs code and trigger
a RESET an the SGs interface.
- Add a flag to report an HLR problem back to the SGs code
- Fix the FSM that controls the reset
- Make sure the all SGs associations are reset when the failure occurs.
Change-Id: Icc7df92879728bc98c85fc1d5d8b4c6246501b12
Related: OS#3859
According to 3GPP TS 29.002, section 7.6.8.7, MMS (More Messages to Send)
is an optional IE of MT-ForwardSM-Req message which is used by SMSC to
indicate that there are more (multi-part) MT SMS messages to be sent.
The MSC needs to use this indication in order to decide whether to
keep the RAN connection with a given subscriber open.
Related Change-Id: (TTCN) I6308586a70c4fb3254c519330a61a9667372149f
Change-Id: Ic46b04913b2e8cc5d11a39426dcc1bfe11f1d31e
Related: OS#3587
in osmo-msc/Makefile.am, osmo-msc was actually missing the LIBASN1C_LIBS even
though it included LIBASN1C_CFLAGS. Probably libasn1c is implicitly linked from
libranap.so, but doesn't hurt to name it.
When building without Iu support, the LIBOSMORANAP* and LIBASN1C* vars are
empty, so no need to explicitly switch on BUILD_IU, just name them.
Change-Id: I39ae5e3f0f7661ca9ee5c17a500be28c461d7ec7
DB counters has been used to save osmo_counters & osmo_rate_ctr to a local
sqlite databases every 60 seconds.
This is quite slow e.g. 1000 subscriber might slow the msc down.
Change-Id: Id64f1839a55b5326f74ec04b7a5dbed9d269b89c
Later on we want to do extra steps upon receiving a Rx Reset Ack
(checking for Osmux support from peer). Let's move handling of this
message into its own function to have handling implementation in one
place.
Change-Id: I516c4baf6071d26f6c530726d93677bed968efd1
When 'check-imei-rqd 1 early' is set in the config, send the IMEI to
the HLR before doing the location update with the HLR.
The OsmoHLR documentation referenced in the code will be added in
osmo-hlr.git's Change-Id I2dd4a56f7b8be8b5d0e6fc32e04459e5e278d0a9.
Related: OS#2542
Change-Id: I88283cad23793b475445d814ff49db534cb41244
Copy IMEISV to IMEI when IMEISV changes. The additional SV digits will
get cut off then. This is needed for the subscriber on demand use case,
since we can get the IMEISV early (see [1]), but need to send the IMEI
to the Check IMEI procedure.
While adjusting the tests, I have noticed that there are code paths
where we ask the MS for the IMEISV first, and later ask the MS for the
IMEI, although we already have the IMEISV. This could be improved in a
future patch.
[1] Change-Id I256224194c3b8caf2b58a88d11dccd32c569201f
Related: OS#2542
Change-Id: I02e7b66848bf7dddb31b105e2ae981432817ae1e
Prepare for Rhizomatica's subscriber on demand use case, in which the
network access is disabled by default for new subscribers, but the IMEI
is required in the HLR to find out which user has which IMSI. Due to the
network access being disabled, the location update request towards the
HLR fails and the MS gets rejected, so we need to get the IMEI early.
Related: OS#2542, OS#3755
Change-Id: I256224194c3b8caf2b58a88d11dccd32c569201f
In state machine callback functions, instead of logging an error when
an invalid event arrives, do OSMO_ASSERT(0).
Change-Id: If5363ae37b414a0ac195e5f89664c75cbad0bb21
In ran_a_make_handover_request() we do prevent destination buffer
(r.encryption_information.key) overflow, but not source buffer
(n->geran.chosen_encryption->key) overrun if an incorrect key
length is received. Let's fix this.
Change-Id: I278bb72660634c2d535e1bd3d7fce5696da23575
Fixes: CID#198450 Out-of-bounds access
We basically need to make sure that one of two possible IEs
is not NULL, while another is NULL (eXclusive OR). This can
be done using at least two conditional branches.
Change-Id: Ie0f9b5c1bbbfb744e0615da07d76037d91b0abc8
Fixes: CID#198444 Logically dead code
For some reason, having ternary operator there makes Coverity think
that 'n->geran.chosen_encryption' is dereferenced before checking
against NULL. Let's make it happy, and move the assignment.
Change-Id: I95051d0f02e2fdd3ec8da3a506109e7b23e99b4b
Fixes: CID#198454 Dereference before null check
In gsm48_rx_mm_serv_req() we need to make sure that a given message
buffer is large enough to contain both 'gsm48_hdr' and
'gsm48_service_request' structures.
Comparing msg->data_len with size of pointer if wrong because:
- we actually need to compare with size of struct(s),
- we need msgb_l3len(), not length of the whole buffer.
Moreover, since we have to use the pointer arithmetics in order
to keep backwards compatibility with Phase1 phones, we also
need to check the length of both Classmark2 and MI IEs.
Change-Id: I6e7454d7a6f63fd5a0e12fb90d8c58688da0951e
Since in parse_umts_auth_resp() we are checking the length of
GSM48_IE_AUTH_RES_EXT TLV, we need to print its length, but
not the length of the whole L3.
Change-Id: I2bfebce6d017be834bfe7628ffa2b341eb82c11c
The MSC_A_EV_HANDOVER_END exists as parent term event for the msc_ho_fsm, but
it is not actually required as functional event, since all cleanup is handled
in msc_ho_fsm_cleanup().
That's why I never bothered to add the event to msc_a_fsm, but of course that
means we get an error message after each (successful and unsuccessful)
handover, that the MSC_A_EV_HANDOVER_END is not permitted.
Allow the event and ignore it to silence the error message.
Explain in a comment.
Change-Id: Ie8dc0c0a631b7da43111f329562007766a21b134
After neels/ho was merged, SMS over IuCS/RANAP was failing in both
MO and MT direction. The reason was that all mobile-terminated SMS-CP
layer messages were sent in RANAP with SAPI-0 instaed of SAPI-1.
Change-Id: I98e6eddb52d5c61c4e2d34bdfcd43cf460296ad7
Closes: OS#3993
The event is actually never dispatched and useless, because when an RTP stream
releases, the call_leg terminates directly anyway (which wasn't apparent when
starting to design the call_leg FSM yet).
Change-Id: I6b2fc1225c960fa2f7c46adf241520217a07821c
The SMPP 3.4 specification defines the password field as a
"Variable-length octet string with maximum length of 9", and according
to table 3-1 this means including the terminating NUL-byte.
However, OsmoMSC allows to configure longer passwords in the ESME
configuration. Those passwords will then never match, as libsmpp34
performs length validation and generates a parser error for anyone
trying to send a longer password via SMPP.
The same applies for system-id, where we have to permit only 15
characters with zero termination, but not 16 characters.
Change-Id: I81ef593e84bf1e15f6746386fc145495fae29354
Closes: OS#3166
Instead of calling trans_log_subsys() for each LOG_TRANS() log line, rather
store in trans->log_subsys once on trans_alloc() and use that.
Do not fall back to the RAN's own subsystem (DBSSAP / DIUCS), it makes little
sense and may cause logging to switch subsystems depending on the RAN state.
In trans_log_subsys(), add missing switch cases:
- Log silent call transactions also on CC.
- Log USSD on DMM.
About USSD: we currently have no dedicated USSD logging category. As a result,
after LOG_TRANS() was introduced [1], USSD logged on DBSSAP/DIUCS or DMSC,
depending on whether a RAN was associated with the trans or not. Before that
change, USSD always logged on DMM, so, until we have a separate logging
category for USSD, consistenly use DMM again.
[1] in I2e60964d7a3c06d051debd1c707051a0eb3101ba / ff7074a0c7
Related: coverity CID 198453
Change-Id: I6dfe5b98fb9e884c2dde61d603832dafceb12123
As per 3GPP TS 03.40, section 9.2.3.16 "TP-User-Data-Length (TP-UDL)",
if the TP-User-Data is coded using the GSM 7-bit default alphabet,
the TP-User-Data-Length field indicates the *number of septets*
within the TP-User-Data field to follow. Otherwise, i.e. in case
of 8-bit or UCS-2 encoded data, the *number of octets* is indicated.
Since we store the original TP-UDL value (as received), we might
need to convert septets to octets before passing it to memcpy().
Otherwise this would lead to a buffer overrun.
Also, as we receive TPDU from untrusted source (i.e. subscriber),
the TP-UDL value needs to be checked against the corresponding
maximum (160 septets or 140 octets) and truncated if needed.
Please note that buffer overrun is still possible, e.g. when an
indicated TP-UDL value is grather than the remaining TPDU length.
Preventing this would require adding an additional check.
Change-Id: I4b08db7665e854a045129e7695e2bdf296df1688
Depends-on: (core) I54f88d2908ac47228813fb8c049f4264e5145241
It was noticed that SCCP_RAN_MSG_RESET_ACK message is not freed after
sending. Since ran_peer_rx_reset() calls sccp_ran_down_l2_cl(), which
then calls osmo_sccp_user_sap_down_nofree(), which doesn't free the
message buffer (what's clear from its name).
OsmoMSC# show talloc-context application full filter msgb
full talloc report on 'osmo_msc' (total 20155 bytes in 88 blocks)
msgb contains 4640 bytes in 5 blocks (ref 0)
bssmap: reset ack contains 1160 bytes in 1 blocks (ref 0)
bssmap: reset ack contains 1160 bytes in 1 blocks (ref 0)
bssmap: reset ack contains 1160 bytes in 1 blocks (ref 0)
Let's free it after sending (or in case of error).
Change-Id: Ic174f6eecd6254af597dfbdc1c9e3d65716f0a76
This fixes the following compiler error:
msub.c: In function ‘msub_fsm_active’:
msub.c:85:35: error: ‘msc_role_a_c’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
|| (msc_role_a_c && msc_role_a_c->ran->type == OSMO_RAT_EUTRAN_SGS)))
~~~~~~~~~~~~^~~~~
msub.c:59:26: note: ‘msc_role_a_c’ was declared here
struct msc_role_common *msc_role_a_c;
^~~~~~~~~~~~
Change-Id: Id518dea77d01ed0518ca7cba6b1b363f1c8e6543
While developing the inter-MSC handover refactoring, I was annoyed by the fact
that mncc_tx_to_cc() receives an MNCC message struct containing a msg_type, as
well as a separate msg_type argument, which may deviate from each other. So, as
a first step I wanted to make sure that all callers send identical values for
both by inserting an OSMO_ASSERT(msg_type == msg->msg_type). Later I was going
to remove the separate msg_type argument.
I then forgot to
- carry on to remove the argument and
- to actually test with internal MNCC (it so happens that all of our ttcn3
tests also use external MNCC).
As a result, the "large refactoring" patch for inter-MSC Handover breaks
internal MNCC operation.
Fix that: remove the separate msg_type argument and make sure that all callers
of mncc_tx_to_cc() indeed pass the desired msg_type in msg->msg_type, and hence
also remove the odd duality of arguments.
Various functions in mncc_builtin.c also exhibit this separate msg_type
argument, which are all unused and make absolutely no sense. Remove those as
well.
Related: OS#3989
Change-Id: I966ce764796982709ea3312e76988a95257acb8d
We are just introducing smpp34_set_memory_functions() in libsmpp34
to allow applications like OsmoMSC to provide their own heap allocator
callback functions. Let's used this to integrate with talloc and
hence allow talloc tracking/debugging for libsmpp34 internal
allocations.
Depends: libsmpp34 Change-Id I3656117115e89638c093bfbcbc4369ce302f7a94
Change-Id: Ie2725ffab6a225813e65768735f01678e2022128
Related: OS#3913
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
Before, I was testing with osmo-hlr patch
I01a45900e14d41bcd338f50ad85d9fabf2c61405 applied, but that patch is currently
in an abandoned state.
This is the counterpart implemented in osmo-msc: always include the terminating
nul char in the "blob" that is the MSC IPA name.
The dualities in the formats of routing between MSCs is whether to handle it as
a char*, or as a uint8_t* with explicit len (a blob).
In the VTY config to indicate target MSCs for inter-MSC handover, we have
strings. We currently even completely lack a way of configuring any blob-like
data as a VTY config item.
In osmo-hlr, the IPA names used for routing are currently received as a char*
which *includes* the terminating nul char. So in osmo-msc, if we also always
include the nul char, it works.
Instead, we could just send the char* part without the nul char, and apply
above mentioned osmo-hlr patch. That patch would magically match a name that
lacks a nul with a name that includes one. I think it is better to agree on one
format on the GSUP wire now, instead of making assumptions in osmo-hlr on the
format of the source/target names for routing. This format, from the way GSUP
so far transmits the IPA SERNO tag when a client attaches to osmo-hlr, happens
to include the terminating nul char.
Change-Id: I9ca8c9eef104519ed1ea46e2fef46dcdc0d554eb
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
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
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
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
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
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
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
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
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
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 36c44b2100,
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)
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
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
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
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
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
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
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
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
Log transaction allocation errors as such. While at it, use proper
subsystem to log missing VLR subscriber.
Change-Id: I617be8793b9416ccd49022c72f7d93df7f4fb4d9
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
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
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
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
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
When check-imei-req is enabled in the VTY config, do not accept IMEIs
sent by the ME directly anymore. Send the IMEI to the EIR/HLR and wait
for its ACK or NACK.
OsmoHLR also accepts all IMEIs at this point, but this allows to
optionally store the IMEI in the HLR DB.
Depends: Ib240474b0c3c603ba840cf26babb38a44dfc9364 (osmo-hlr)
Related: OS#3733
Change-Id: Ife868ed71c36cdd02638072abebf61fc949080a7
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
Neels Hofmeyr
Philipp Maier
Pau Espin
Keith Whyte
Oliver Smith
Eric Wild
Harald Welte
Sylvain Munaut