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
Neels Hofmeyr
Philipp Maier
Pau Espin
Keith Whyte
Oliver Smith
Eric Wild
Harald Welte