Previously it was intended that we are always parsing the
whole GSM 04.80 message, including the Invoke ID. But
there is no need to do that, since we are going to
forward the Facility IE payload to HLR in near future.
Moreover, there was a mistake (my bad) - transaction is
being established before parsing of the message, so the
req structure remains uninitialized until that.
Let's just send RELEASE COMPLETE message without any Cause or
Facility IEs. We could indicate a problem using the first one,
but according to GSM TS 04.80, the Cause IE only makes sense
when "its functional handling is specified in the service
description or GSM TS 09.11".
Change-Id: Iecba2dccada9bbcdeb3a9dfd868719aeedc07022
This function could be also used by other parts of code, e.g.
by gsm_04_11.c or by gsm_09_11.c, during initialization of
a new transaction. No need to hide it.
Change-Id: I9a9d17fca4901163dae10d76455aa4cf54497156
During a long time, we had both file and symbol names, actually
related to Supplementary Services, with the 'ussd' abbreviation.
This is not absolutely wrong, but isn't correct at the same time.
USSD is a kind of Supplementary Services, this is only a part
of them. There are also 'structured' Supplementary Services,
which can be call related or call independent.
The "Signalling interworking for supplementary services" is
defined by GSM TS 09.11, and this is exactly what MSC should
implement. Let's use the specification number for naming, as
we do e.g. in the GSM 04.11 (SMS) implementation.
Change-Id: Ic1eaceddb58132318e4e941be542da34b8ebefe1
A subscriber may have a few active transactions at the same time.
For example, one can receive SMS messages during a call, or during
an active SS/USSD session.
We already have connection ref-counting and transactions for CC
and SMS, so let's also use both for SS/USSD.
Change-Id: I21c6777cb88f1f4f80f75dcd39734e952bd4e8b0
Previously the MSC_CONN_USE token for Supplementary Services was
called 'MSC_CONN_USE_TRANS_USSD'. Non-call related Supplementary
Services is not only about USSD, so let's rename it.
Change-Id: I5b3517c87a32fa64dea6b0c912f2b76c5c25a112
There are error and problem codes defined by GSM TS 04.80:
- Error codes are used when a message is structured correctly,
but something is wrong in context of the current operation.
Usually they are carried by 'Return Error' component.
- Problem codes are used when something is wrong with the
message structure, or with carried values. They are
carried by 'Reject' component.
There are three groups of them (see table 3.13):
- General Problem Codes (table 3.14),
- Invoke Problem Codes (table 3.15),
- Return Result Problem Codes (table 3.16),
- Return Error Problem Codes (table 3.17).
The first group is general purpose, and can be sent in
response to any kind of message, excluding 'Reject' itself.
Other ones are bound to specific component types, such as
'Invoke', 'Return Result' and 'Return Error'.
For some reason, a 'Reject' component with the general problem
code 'GSM_0480_GEN_PROB_CODE_UNRECOGNISED' was always used in
OsmoMSC. Even when the message structure is correct.
Let's properly indicate errors in the following way:
- 'Reject' with GSM_0480_GEN_PROB_CODE_UNRECOGNISED
when the gsm0480_decode_ss_request() fails to decode
a message. It can only return 0 or 1, so it's hard to
guess which exact part of message caused the error.
- 'Return Error' with GSM0480_ERR_CODE_ILLEGAL_SS_OPERATION
when the operation code is not related to USSD.
- 'Return Error' with GSM0480_ERR_CODE_UNEXPECTED_DATA_VALUE
when the requested USSD code is unhandled (not supported).
There is a TTCN-3 testcase for this:
https://gerrit.osmocom.org/9470/
Change-Id: I800e7ec98dc9d0bca2d45a8b8255d60253d63e14
Since change If9a81d057f73150e483286472e73c45e7a453a6d removes the
RTP loopback at the beginning. This also means that the Hack we
do to run the IuUP negotiation via looping back the first few
RTP packets will not work anymore. However, we should keep that
hack as long as we do not have IuUP support in the MGW.
- Start RTP connection in loopback mode for IuUP
Change-Id: I4c7d90de4dc87e8baf7cf4a0c69d0e9e8c92e27b
Remove subscribers which fail to send periodic Location Updates from the
list of subscribers known to the VLR. This complements the IMSI detach
procedure: periodic LU expiry triggers an implicit IMSI detach.
Expired subscribers are purged from a periodic timer which iterates
over all subscribers once per minute.
Subscribers with an active connection do not expire. This is controlled
by the subscriber conn FSM which sets a subscriber's the LU expiry timeout
value to GSM_SUBSCRIBER_NO_EXPIRATION while a connection is active.
Add support for fake time with osmo_clock_gettime() to msc_vlr tests.
This functionality existed in OpenBSC but was lost during the nitb split.
This code took some inspiration from the OpenBSC implementation.
Related: OS#1976
Change-Id: Iebdee8b12d22acfcfb265ee41e71cfc8d9eb3ba9
The configure script should only check for libsmpp with --enable-smpp.
Also, disable the build of smpp_mirror with --disable-smpp.
Change-Id: Ic4a8a5c970c04a6257ee4c8e3977e98c4ddfda13
Fixes: a55dda703f
Related: If7e1af11cdac8587bb4d66fb4eacee4b79945359
Related: OS#3232
a_reset.c/h was originally developed to be used in both, bsc and
msc without changes. Unfortunately no suitable library has been
found for a_reset.c/h so the file ended up as duplicated code in
both split brances. Eventually we decided to specialize the
generalized code again, which means some of the functions needed
only by osmo-bsc are removed.
- Remove dead code
- Fix timer identification number (T16)
- use fi->priv to hold context info
- Minor cosmetic fixes
Change-Id: I8e489eb494d358d130e51cb2167929edeaa12e92
Depends: libosmocore I36d221c973d3890721ef1d376fb9be82c4311378
Related: OS#3103
The FSM that controls the VLR ACCESS uses cause code 9
(GSM48_REJECT_MS_IDENTITY_NOT_DERVIVABLE) to signal that the
identity of the MS is currently not known in VLR (MSC-Reboot)
However, this cause code is from the GMM domain and is interpreted
as GSM48_REJECT_SRV_OPT_TMP_OUT_OF_ORDER by the MS, which cauese
the MS not to make a new LOCATION UPDATE on CM SERVICE REQUEST
- use GSM48_REJECT_IMSI_UNKNOWN_IN_VLR and
GSM48_REJECT_IMSI_UNKNOWN_IN_VLR instead of
GSM48_REJECT_IMSI_UNKNOWN_IN_VLR
Change-Id: Ic058c93387f9be9af4940f8961839c02b93ee370
Closes: OS#3266
Catched by osmo-gsm-tester running test voice:octphy.
Fixes following AddressSanitizer report:
==18864==ERROR: AddressSanitizer: heap-use-after-free on address 0x61a000016f18 at pc 0x55f1b29eee5c bp 0x7ffdaa2ac000 sp 0x7ffdaa2abff8
WRITE of size 8 at 0x61a000016f18 thread T0
#0 0x55f1b29eee5b in setup_trig_pag_evt osmo-msc/src/libmsc/gsm_04_08.c:1490
#1 0x55f1b2a086c1 in subscr_paging_dispatch osmo-msc/src/libmsc/gsm_subscriber.c:101
#2 0x7fb88e07c1c9 in osmo_timers_update libosmocore/src/timer.c:257
#3 0x7fb88e07f1b1 in osmo_select_main libosmocore/src/select.c:253
#4 0x55f1b29b600b in main osmo-msc/msc_main.c:694
#5 0x7fb88bebe2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#6 0x55f1b29b69f9 in _start (osmo-msc/bin/osmo-msc+0xf09f9)
Related: OS#3198
Change-Id: Ie7fdca4d48e247c77a53e81aec2b6bacd8fef678
Take the chance to pass a var of type enum instead, so the compiler
warns us if a new enum value is added. For instance, if we remove
GSM_PAGING_EXPIRED from the switch statement:
src/libmsc/gsm_04_08.c:1463:2: warning: enumeration value ‘GSM_PAGING_EXPIRED’ not handled in switch [-Wswitch]
switch (paging_event) {
^~~~~~
Change-Id: I65d871704b9636c594dc982200fbe7f7ce6784f5
Fixes following error catched by enabling address sanitizer:
==20792==ERROR: AddressSanitizer: heap-use-after-free on address 0x60b000122610 at pc 0x7f9c9c3fe063 bp 0x7ffd2e68f600 sp 0x7ffd2e68edb0
READ of size 11 at 0x60b000122610 thread T0
#0 0x7f9c9c3fe062 (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3c062)
#1 0x7f9c9beb8ee4 in talloc_strdup (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x6ee4)
#2 0x56096a7cf75b in smpp_smsc_conf src/libmsc/smpp_smsc.c:983
#3 0x56096a7cf9df in smpp_smsc_start src/libmsc/smpp_smsc.c:1015
#4 0x56096a7d4935 in smpp_openbsc_start src/libmsc/smpp_openbsc.c:785
#5 0x56096a755ad0 in main src/osmo-msc/msc_main.c:598
#6 0x7f9c9927b2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#7 0x56096a756979 in _start (/home/jenkins/workspace/osmo-gsm-tester_run-prod/trial-805/inst/osmo-msc/bin/osmo-msc+0xf0979)
Related: OS#3181
Change-Id: Iaf0d251c8d2912266a087ada4d20905146e08592
Since the I697639d8469e5dda617b27995c4a92e1f0c0bead, call
independent SS messages are also supported by
gsm48_pdisc_msgtype_name().
So, instead of 'NCSS:0x3b' it will return 'GSM0480_MTYPE_REGISTER'.
Let's correct the expected message names.
Change-Id: If9e854ee84882d104cf2ffaceb3862fda6862f19
The only reason to use int instead of the enum was the lack of header
iu_client.h when not building with Iu support. Rather use the configure result
properly, include the header when Iu support is built and use the proper enum.
Omit the entire iu sub-struct when building without Iu.
Add LIBOSMORANAP_CFLAGS to libvlr, in order to find the iu_client.h header (now
also included from gsm_data.h).
Rationale: Instead of using a questionable typecast from int* to enum*, we can
now use the enum member directly without needing to silence compiler warnings.
Change-Id: Ic9f8bf53f4b605c166e84cd7edd90c10fe7d7a1f
This bug is super obvious: We cannot first call
sms_pending_free(pending) and then in the next line still dereference
the pending->sms_id member.
This bug was introduced in January with Change-Id: I3749855fe25d9d4e37ec96b0c2bffbc692b66a78
and apparently nobody has tested any MT-SMS with asan enabled since?
Change-Id: Ibf17f270cdeb8153036eda3de274dd163bbff7e6
Closes: OS#3152
We set acl->esme during _process_bind(), but we don't clear it
in case the TCP connection for the ESME is dead. This leads to
a stale acl->esme pointer, which we will attempt to dereference
the next time a SMS is delivered to a route pointing to this acl,
where it will be a heap use-after-free.
This was discovered using AddressSanitizer and MSC_Tests.ttcn
Closes: OS#3168
Change-Id: I1f140d7f9c7d89f200ddbcd81a8df66de69fb3e4
Instead of keeping separate enums for FSM results and translating between those
and the actual 04.08 reject causes that will ultimately reach the MS, just pass
enum gsm48_reject_value cause codes around everywhere.
Collapse some VLR *_timeout() and *_cancel() api to just *_cancel() with a
gsm48 cause arg.
(Hopefully) improve a few reject causes, but otherwise just aim for more
transparent decisions on which cause value is used, for future fixes of
returned causes.
Depends: I6661f139e68a498fb1bef10c266c2f064b72774a (libosmocore)
Change-Id: I27bf8d68737ff1f8dc6d11fb1eac3d391aab0cb1
In the subscr_conn_fsm instance's ID, include the Complete Layer 3 type, so
that we can see on the first glance whether a state transition belongs to MO or
MT.
The huge patch is due to the cosmetic change affecting nearly every single log
line in the msc_vlr_tests, by nature of changing the FSM's ID.
Related: OS#3122
Change-Id: I2a7e27e0f16df1872dcda64cb928c3b8528ea3f7
On receiving a Clear Request, don't send a Clear Command "out of band", let the
FSM do the release handling by invoking msc_subscr_conn_mo_close().
Fixes: ttcn3 MSC_Tests.TC_lu_clear_request
Change-Id: I168b889ac7989641cc679b781dcffb87ff13a710
When sending a BSSMAP Clear or Iu Release, do not immediately discard the conn,
but wait until a BSSMAP Clear Complete / Iu Release Complete has been received.
Hence we will no longer show in the log that an incoming Release/Clear Complete
belongs to an unknown subscriber, but will still be around to properly log the
release.
Related: OS#3122
Change-Id: Ie4c6aaba3866d6e5b98004e8870a215e8cf8ffc1
Refactor:
1. Glue the gsm_subscriber_connection alloc to the subscr_conn_fsm.
2. Add separate AUTH_CIPH state to the FSM.
3. Use conn->use_count to trigger conn release.
4. Add separate RELEASING state to the FSM.
5. Add rate counters for each of the three Complete Layer 3 types.
Details:
1. Glue the gsm_subscriber_connection alloc to the subscr_conn_fsm.
Historically, a gsm_subscriber_connection was allocated in libbsc land, and
only upon Complete Layer 3 did libmsc add the fsm instance. After splitting
openbsc.git into a separate osmo-msc, this is no longer necessary, hence:
Closely tie gsm_subscriber_connection allocation to the subscr_conn_fsm
instance: talloc the conn as a child of the FSM instance, and discard the conn
as soon as the FSM terminates.
2. Add separate AUTH_CIPH state to the FSM.
Decoding the Complete Layer 3 message is distinctly separate from waiting for
the VLR FSMs to conclude. Use the NEW state as "we don't know if this is a
valid message yet", and the AUTH_CIPH state as "evaluating, don't release".
A profound effect of this: should we for any odd reason fail to leave the FSM's
NEW state, the conn will be released right at the end of msc_compl_l3(),
without needing to trigger release in each code path.
3. Use conn->use_count to trigger conn release.
Before, the FSM itself would hold a use count on the conn, and hence we would
need to ask it whether it is ready to release the conn yet by dispatching
events, to achieve a use_count decrement.
Instead, unite the FSM instance and conn, and do not hold a use count by the
FSM. Hence, trigger an FSM "UNUSED" event only when the use_count reaches zero.
As long as use counts are done correctly, the FSM will terminate correctly.
These exceptions:
- The new AUTH_CIPH state explicitly ignores UNUSED events, since we expect the
use count to reach zero while evaluating Authentication and Ciphering. (I
experimented with holding a use count by AUTH_CIPH onenter() and releasing by
onleave(), but the use count and thus the conn are released before the next
state can initiate transactions that would increment the use count again.
Same thing for the VLR FSMs holding a use count, they should be done before
we advance to the next state. The easiest is to simply expect zero use count
during the AUTH_CIPH state.)
- A CM Service Request means that even though the MSC would be through with all
it wants to do, we shall still wait for a request to follow from the MS.
Hence the FSM holds a use count on itself while a CM Service is pending.
- While waiting for a Release/Clear Complete, the FSM holds a use count on
itself.
4. Add separate RELEASING state to the FSM.
If we decide to release for other reasons than a use count reaching zero, we
still need to be able to wait for the msc_dtap() use count on the conn to
release.
(An upcoming patch will further use the RELEASING state to properly wait for
Clear Complete / Release Complete messages.)
5. Add rate counters for each of the three Complete Layer 3 types.
Besides LU, also count CM Service Request and Paging Response
acceptance/rejections. Without these counters, only very few of the auth+ciph
outcomes actually show in the counters.
Related: OS#3122
Change-Id: I55feb379e176a96a831e105b86202b17a0ffe889
So far we hit a running T308 during CC release when caused by a BSSMAP Clear
Request, and we loudly log that as error.
However, now I understand that T308 is a direct cause of the dispatch of a REL
IND towards MNCC, which is used to indicate teardown to MNCC. So during
_gsm48_cc_trans_free(), we first clear all timers, then invoke
mncc_release_ind() which starts another timer (useful for graceful CC Release,
but in this code path the intention is immediate release). Simply immediately
cancel the timer again and release the conn.
A separate question is whether a BSSMAP Clear Request should be less aggressive
in releasing the connections; i.e. instead of calling trans_free() all around,
to rather ask each transaction to "please stop soon", somehow.
Related: OS#3062
Change-Id: I231fdb574a086a206321148474cbdc7ca9cf39f0
If an error on the MGW side occurs, the MSC may send out
a DLCX command that contains a wildcarded endpoint name.
Wildcarded DLCX commands are legal in principle but not
in the context of an error on a single endpoint. Apart
from that osmo-mgw is (not yet) capable to handle
wildcarded DLCX command.
The problem is caused by a wrong error handling. When the
first (RAN) CRCX fails the error handling logic tries to
perform a DLCX, but since we did not receive a specific
endpoint name yet, the buffer containing the endpoint name
is still initalized with the wildcarded enpoint name, but
the error handler and the code that generates the DLCX is
not aware of that.
- Perform a check in the error handler function that
checks if a DLCX can be made (a specific endpoint
name is set
- Correct the flags in the code that handles the first
CRCX so that no DLCX is requested in the case of error
Related OS#2882
Change-Id: I64c2a82016d854ad446fd49a5d76a28324e8bd4b
The logtext currently logs the pointer (address) of the string
variable that holds the endpoint name, rather then the endpoint
name itself.
- Use %s instead of %p in format string
Change-Id: I01b3d07aeedd72be60361249a5bf80fbb68b7bb8
I assumed that trans_free() would always be called before freeing the FSM. But
the actual conn free dance that tries to make sure a release is triggered from
all directions actually may run into a situation where conn->fi is NULL.
The situation is described in OS#3125.
For now simply drop the assert.
The subscr conn and FSM dealloc will soon be glued firmly together; but I want
to add a test against OS#3062 before that, and that would also hit above assertion.
Related: OS#3125 OS#3062
Change-Id: I5c30e0f9545fb76615776ff6cc16b56aeb5b043a
We usually put comments for functions in *.c files, while header
files are usually plain listings of the API without comments.
Change-Id: I6b0d1d9e1a1b1ffb71cb9905e74f6fad2333bb65
In the old days, OsmoNITB couldn't process any SMS that wasn't between
two subscribers on the same NITB.
We've long re-worked the internals in order to process SMS with
arbitrary sender MSISDN (e.g. from SMPP). However, the VTY command
"subscriber ... sms" was never updated, it seems.
Change-Id: I62b17e0a67989484415f0df2c8cb4ff1f94dbf2b
Closes: OS#3151
The DLCI field of the DTAP header indicates the SAPI as well as the
data link (main DCCH or SACCH). We must make sure to use the correct
DLCI when sending DTAP to the BSC.
We achieve this by
* storing the DLCI in the msgb->cb while parsing the DTAP header
* storing the received DLCI (from msgb->cb) in the transaction for
mobile-originated transactions
* using the trans->dlci to sent msgb->cb when transmitting L3
* filling the DTAP DLCI value from msgb->cb when transmitting DTAP
For MSC-originated transactions, we choose a DLCI value corresponding
to the service (SAPI=0 for CC, SAPI=3 for SMS) and store that in
trans->dlci.
Closes: OS#3150
Change-Id: If511b20f52575054cab1346d99a8cb68d827fdbf
The current msc_subscr_con_allocate() was in fact only used by msc_vlr_tests,
while both a_iface_bssap.c and iucs.c did their own duplicate code of
allocating the gsm_subscriber_connection struct. Unify.
Drop the old msc_subscr_con_allocate(), instead add msc_subscr_conn_alloc().
The new function also takes via_ran and lac arguments directly.
The conn allocation will soon be closely tied to the subscr_conn_fsm instance
allocation, so place the new function definition alongside the other
subscr_conn_fsm API, and match its naming ("conn").
Related: OS#3122
Change-Id: Ia57b42a149a43f9c370b1310e2e1f512183993ea
Instead of jumping through hoops to pass the Complete Layer 3 operation that
created this conn via FSM event dispatch parameters, put it right in the
gsm_subscriber_connection struct, where it always belonged.
Move definition of the enum complete_layer3_type to gsm_data.h, where
gsm_subscriber_connection is defined.
Introduce msc_subscr_conn_update_id() to set the complete_layer3_type of the
conn as soon as a Complete Layer 3 message is received.
In msc_subscr_conn_update_id(), already include an mi_string argument to
prepare for an upcoming patch where the FSM will be allocated much earlier when
the Mobile Identity is not known yet, and we'll also update the fi->id here.
The odd logging change in the msc_vlr_tests output uncovers a wrong use of the
osmo_fsm_inst_dispatch() data argument for SUBSCR_CONN_E_CN_CLOSE events: if a
child FSM signals unsuccessful result, instead of the failure cause, it passed
the complete_layer3_type, as requested upon FSM allocation, which was then
misinterpreted as a failure cause. Now a child FSM failure will pass NULL
instead, while other SUBSCR_CONN_E_CN_CLOSE events may still pass a valid cause
value.
Related: OS#3122
Change-Id: Iae30dd57a8861c4eaaf56999f872d4e635ba97fb
'subscr_conn_from' could mean anything: from what, RAN type? BSS identifier? MM
action? Clearly name it as the Complete Layer 3 kind it represents.
Related: OS#3122
Change-Id: I6263a80e6db01c2ca48df6c58b05e2fd19347057
Match osmo-bsc's naming of the subscriber connection's FSM instance; 'conn->fi'
makes more sense anyway than 'conn->conn_fsm'.
BTW, an upcoming commit will do away with the legacy from libbsc/libmsc duality
and firmly glue the conn allocation to the fi.
Related: OS#3122
Change-Id: If442f2ba78d9722b1065ec30c9a13f372b6a8caa
I broke this test during dev and saw the failure being noticed only in the next
test when DTAP is expected again. Verify success right there, instead.
Change-Id: Ifdde3a6fa5835203c34c40db77761f2e90c0d5ff
Since the logging allocations now also show up in the root context report, some
tests need adjusted talloc checks.
In msc_vlr_tests, also output the number of talloc blocks before tests are
started to show that the number didn't change after the tests.
Change-Id: Iae07ae60230c7bab28e52b5df97fa3844778158e
Vadim Yanitskiy
Philipp Maier
Pau Espin
Harald Welte