At the moment osmo-msc populates the member ip in struct gsm_mncc_rtp
with the wrong byte ordering. This causes LCR or
osmo-sip-connector to receive the IP address in the wrong order, which
eventually leads into a reversed IP address in the SDP part of the SIP
messages.
Change-Id: I86148179b549b511528e4c65213eb6c204cc609e
Related: OS#3431
This recent patch moves Classmark storage to the VLR subscriber, and introduced
a segfault when a Classmark Update is received during IMSI detach:
commit 986fe7ed18
change-id I27081bf6e9e017923b2d02607f7ea06beddad82a
Mon Sep 17 01:12:13 2018 +0200
"store classmark in vlr_subscr, not conn"
It assumed that we would never accept any Classmark Update messages unless we
also have a valid subscriber for it. Well, that is proven wrong by the
ttcn3-msc-test TC_imsi_detach_by_imsi(), which brings osmo-msc to its knees.
Fix: in case of no valid vlr_subscr being present, store Classmark in the conn
temporarily, and copy any received Classmark to VLR subscriber as soon as it
gets associated with the conn (if at all).
Change-Id: Ib2a2ae6bf86e8f29fc6751a8b5cdb7187cd70290
When the VLR requests a Ciphering Mode with vlr_ops.set_ciph_mode(), and if we
need a ciph algo flag from a Classmark information that is not yet known
(usually CM 2 during LU), send a BSSMAP Classmark Request to get it.
To manage the intermission of the Classmark Request, add
- msc_classmark_request_then_cipher_mode_cmd(),
- state SUBSCR_CONN_S_WAIT_CLASSMARK_UPDATE,
- event SUBSCR_CONN_E_CLASSMARK_UPDATE.
From state AUTH_CIPH, switch to state WAIT_CLASSMARK_UPDATE. Once the BSSMAP
Classmark Response, is received, switch back to SUBSCR_CONN_S_AUTH_CIPH and
re-initiate Ciphering Mode.
To be able to re-enter the Ciphering Mode algo decision, factor it out into
msc_geran_set_cipher_mode().
Rationale:
In the following commit, essentially we stopped supporting A5/3 ciphering:
commit 71330720b6
"MSC: Intersect configured A5 algorithms with MS-supported ones"
Change-Id: Id124923ee52a357cb7d3e04d33f585214774f3a3
A5/3 was no longer supported because from that commit on, we strictly checked
the MS-supported ciphers, but we did not have Classmark 2 available during
Location Updating.
This patch changes that: when Classmark 2 is missing, actively request it by a
BSSMAP Classmark Request; continue Ciphering only after the Response. Always
request missing Classmark, even if a lesser cipher were configured available.
If the Classmark Update response fails to come in, cause an attach failure.
Instead, we could attempt to use a lesser cipher that is also enabled. That is
left as a future feature, should that become relevant. I think it's unlikely.
Technically, we could now end up requesting a Classmark Updating both during LU
(vlr_lu_fsm) and CM Service/Paging Response (proc_arq_fsm), but in practice the
only time we lack a Classmark is: during Location Updating with A5/3 enabled.
A5/1 support is indicated in CM1 which is always available, and A5/3 support is
indicated in CM2, which is always available during CM Service Request as well
as Paging Response. So this patch has practical relevance only for Location
Updating. For networks that permit only A5/3, this patch fixes Location
Updating. For networks that support A5/3 and A5/1, so far we always used A5/1
during LU, and after this patch we request CM2 and likely use A5/3 instead.
In msc_vlr_test_gsm_ciph, verify that requesting Classmark 2 for A5/3 works
during LU. Also verify that the lack of a Classmark Response results in attach
failure.
In msc_vlr_test_gsm_ciph, a hacky unit test fakes a situation where a CM2 is
missing during proc_arq_fsm and proves that that code path works, even though
the practical relevance is currently zero. It would only become interesting if
ciphering algorithms A5/4 and higher became relevant, because support of those
would be indicated in Classmark 3, which would always require a Classmark
Request.
Related: OS#3043
Depends: I4a2e1d3923e33912579c4180aa1ff8e8f5abb7e7 (libosmocore)
Change-Id: I73c7cb6a86624695bd9c0f59abb72e2fdc655131
Store all Classmark information in the VLR.
So, we now always know the Classmark 1 (mandatory IE for LU). This is visible
in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported"
because classmark 1 is missing, because we now know the Classmark 1.
Rationale:
During Location Updating, we receive Classmark 1; during CM Service Request and
Paging Response, we receive Classmark 2. So far we stored these only for the
duration of the conn, so as soon as a LU is complete, we would forget CM1.
In other words, for anything else than a LU Request, we had no Classmark 1
available at all.
During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1
is supported. That is moot if we don't even have a Classmark 1 for any CM
Service Request or Paging Response initiated connections.
The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1
is missing. To add to the confusion, if a phone indicated that it did *not*
support A5/1 in the Classmark 1, according to spec we're supposed to not
service it at all. A code comment however says that we instead want to heed the
flag -- which so far was only present in a Location Updating initiated
connection. Now we can make this decision without assuming things.
This got my attention while hacking on sending a BSSMAP Classmark Request from
the MSC if it finds missing Classmark information, and was surprised to see it
it lacking CM1 to decide about A5/1.
Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a
For networks without Authentication, the conn is already accepted when
SUBSCR_CONN_E_COMPLETE_LAYER_3 is emitted. Mute that misleading error message.
All is actually fine.
Adjust expected test logs.
Change-Id: I2d19d0a7cf3226ee1456f75a68e007ba98232402
lchan_type was removed from gsm_mncc and the hello message
on initial import from legacy OpenBSC in
Change-Id: Id3705236350d5f69e447046b0a764bbabc3d493c
This patch follows on from Change-Id: Ia02373a36df7605507ee3de49173a9fd6547b726
which reintroduced lchan_type to the gsm_mncc struct.
This patch restores the lchan_type_offset to the hello protocol message
Without this patch, LCR will issue an error and disconnect from the MNCC socket.
Change-Id: I65312082fa5dc0721170f923840e992ef9481a63
Closes: OS#3461
When the assignment completes a choosen codec is returned. At the
moment we do not use this information.
- add struct members for codec info (both, RAN and CN)
- parse codec info in BSSMAP ASSIGNMENT COMPLETE
- use codec info on mgcp
Since the MNCC API is not complete yet, we currently only use the
codec info only on the internal MNCC yet.
Change-Id: I9d5b1cd016d9a058b22a367d0e5e9f2ef447931a
Related: OS#2728
osmo-hlr has recently (as of Change-Id
Iad227bb477d64da30dd6bfbbe1bd0c0a55be9474) a working shared library
implementation of libosmo-gsup-client.
We can remove the local implementation in osmo-msc and use the
system-installed shared library instead.
Change-Id: I6f542945403cf2e3ddac419186b09ec0e2d43b69
Since we don't process SS/USSD requests in OsmoMSC anymore, there
are some useless GSM 04.80 functions remained from the past.
In particular, this change does the following:
- removes both gsm0480_send_{ussd_response|return_error}
functions because they are not used anymore;
- changes symbol prefix from 'gsm0480_' to 'msc_', in order to
avoid possible conflicts with the libosmogsm's GSM 04.80 API;
- cleans up useless includes;
Change-Id: I2990d8627bce0ce6afb1dcf6b11bb194292380d3
This change introduces some new rate counters for call-independent
SS/USSD connections. As OsmoMSC doesn't handle the messages itself,
and only responsible for dispatching messages between both
A and GSUP interfaces, the following is taken into account:
- MS-initiated and network-initiated requests to establish
a NC SS/USSD session (transaction) - "nc_ss:m{o|t}_requests";
- successfully established MS-initiated and network-initiated
SS/USSD sessions (transactions) - "nc_ss:m{o|t}_established".
Change-Id: I23c9475abc9951d82f3342fdc5aaa367836f7741
According to GSM TS 02.90, section 4.3, release of the connection
used for SS/USSD is normally the responsibility of the network.
But the user may also initiate connection release, e.g. by
pressing the 'red button'.
TTCN-3 test case: I7936ed5072ed2ae02f039dc90a1fece1e7f70a70
Change-Id: I76fc277bf9db614a97824b1541cd5bb75aa3e29d
This change introduces a possibility to establish network-initiated
SS/USSD transactions with a subscriber in either IDLE, or DEDICATED
state. In the first case, a new transaction is established using
Paging procedure. If a subscriber already has an active connection,
a separate new transaction is established.
TTCN-3 test case: I073893c6e11be27e9e36f98f11c1491d0c173985
Change-Id: Ief14f8914ef013bd6efd7be842f81fbf053f02e2
In order to be able to support external SS/USSD gateway, we should
not terminate the GSM 04.80 messages at OsmoMSC. Instead, we need
to follow the GSM TS 09.11 specification, and forward all messages
unhandled by OsmoMSC to OsmoHLR over GSUP protocol.
This change implements forwarding of MO SS/USSD messages. The
forwarding assumes transcoding between GSM 04.80 messages and
GSUP messages. The payload of Facility IE is carried 'as is'.
As a side-effect, this will disable the osmo-msc internal handler
implementing the "*#100#" for obtaining the subscribers own phone
number. In order to re-gain this functionality, you will need a
modern osmo-hlr (Change-Id I1d09fab810a6bb9ab02904de72dbc9e8a414f9f9)
and the following line in your osmo-hlr.cfg:
hlr
ussd route prefix *#100# internal own-msisdn
TTCN-3 test case: I01de73aced6057328a121577a5a83bc2615fb2d4
Change-Id: Ide5f7e350b537db80cd8326fc59c8bf2e01cb68c
Some internal sub-systems, such as SS/USSD or SMS implementation,
may also need to use GSUP connection with HLR. Previously, it was
only available within the libvlr code, and nowhere else.
Let's introduce the generic GSUP message router, which will
receive messages unhandled by VLR itself, and route them to
a handler depending on the message type.
Change-Id: Ib8146ce5788c8f249dcaa39d61bd0388574bf892
The CC sub-layer is fairly self-contained, so let's move it to
a separate C source file. The old gsm_04_08.c file now only
contains the 04.07 / DTAP core and MM sub-layer handling.
I did this initially as an experiment to see how self-contained
our CC implementation really is. Given this rather straight-forward
patch builds fine, CC really is self-contained (yay!).
Change-Id: Idb8dd7a8d9d8b4a28c492f12da3cc3305b695cca
There is no need to pass a pointer to a ss_request struct when
calling the gsm0480_send_ussd_* functions, because they only
use both transaction ID and InvokeID from there, which may
be passed directly.
This change allows one to use this API without parsing the
whole GSM 04.80 message, or when parsing is failed. Moreover,
if InvokeID is not available, one can pass any incorrect,
(e.g. negative) value, so the universal NULL tag will be used.
Finally, setting a TI flag is also up to the caller.
Change-Id: I13d5abbfdcf8238ebaf0566c420f09cd9255b648
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
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
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
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
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
Move gsm48_* functions from common_cs.c to libmsc/gsm_04_08.c.
Drop sms_next_rp_msg_ref(), it is just a bunch of bloat around "next_rp_ref++".
Apply the "++" instead, in gsm_04_11.c.
libcommon-cs is now empty, to be removed in subsequent commit.
Change-Id: Ibc410803ce8e273b626124ab9fc934f04df3ae50
Move to libmsc/osmo_msc.c (for lack of a better place and reluctance to create
an own file just for gsm_network_init()).
Change-Id: I2279eee4db6f6687726bfd55841b3748d4930f15
classmark_is_r99() is only used in gsm_04_08.c, move there as static.
rrlp_mode_* is only used in msc_vty.c, move there as static.
Move ran_type_names[] to msc_ifaces.c.
Change-Id: I5381c72af6841829fbc65940fd7d6f4d5cf583df
Drop tall_bsc_ctx; in mncc_sock_init(), talloc the mncc_sock_state from
gsm_network.
In tests or utils, move from using an extern tall_bsc_ctx to a local root
context pointer.
Change-Id: I92c252be1d1e7634f1653de47d37c99d77d9501c
Apply more concise logging categories in each main scope. The bulk goes to
msc_main.c, obviously, while tests and utils get a slimmed down bunch of
logging categories.
Change-Id: I969a0662ba273f3721b6820d02151b7a5b8014b8
Now that all VTY definitions are in the same file, we no longer need
gsmnet_from_vty(). Just have one static struct gsm_network *gsmnet populated by
msc_vty_init() and use it in all VTY functions.
Change-Id: I5cb3712a4f4245feb62d42f1b041fe94de5fac1b
From openbsc.git, we still have osmo-msc's VTY definitions spread across
various places. Combine:
- Move the go_parent_cb() and is_config_node() to msc_main.c, drop
common_vty.c.
- Move all of vty_interface_layer3.c into msc_vty.c.
- Move all of common_cs_vty.c into msc_vty.c.
- Move bsc_vty_init_extra() into msc_vty_init().
- Drop some unused definitions
No functional nor cosmetic changes have been made in the moved code, plain
copy-paste moving (even though the unidiff might look like edits in some
places). I might have adjusted some blank lines though.
Change-Id: Ia818c00ab613a19a34080b160d763b55c19f76b1
In trans_free(), call subscr_conn_release_when_unused(), so that we are sure to
clean up after the last transaction is done.
This fixes an error where a conn lingered after a CC failure, because that code
path forgot to trigger cleanup.
Rationale: so far we were triggering the release check after each DTAP dispatch
(compl_l3 and "normal" DTAP), which is sufficient for properly closed
transactions. We also need a check for when a timeout clears an erratic trans.
Adjust test expectation of test_call_mo_to_unknown_timeout to show that the
error is now fixed.
msc_vlr_test_reject_concurrency now sees an additional release checking event
when the SMS transaction is done, which is expected and does not affect the
test otherwise.
Related: OS#2779
Change-Id: I46ff2e9b09b67e4e0d79cccf8c04936f17281fcb
It's pretty amazing that we print error messages anrd return error
codes, but nobody ever looks at the error code and/or closes the
connection. Let's change that.
Change-Id: Iec693d8012a7816d1ded8206c2d979ac0546fb6e
If both sides are sending RESET at the same time, they are not aware
of each other. This leads to synchronization problems in wich
the remote side is transmitting e.g. a COMPL L3 INFO after receiving
a RESET ACK, but before even receiving or processing the RESET in
the inverse direction. So let's treat receiving a RESET as an implicit
RESET ACK to any RESET we may have sent.
Change-Id: I0ae34fbb3735592bb7cffa5aaf421b14a8acc90e
Fixes several of these type of warnings:
include/osmocom/core/fsm.h:123:38: warning: format ‘%x’ expects argument of type ‘unsigned int’, but argument 9 has type ‘char *’ [-Wformat=]
LOGP((fi)->fsm->log_subsys, level, "%s{%s}: " fmt, \
^
src/libmsc/msc_mgcp.c:277:71: note: format string is defined here
"CRCX/RAN: creating connection for the RAN side on MGW endpoint:0x%x...\n", mgcp_ctx->rtp_endpoint);
~^
Change-Id: I17b7bed8fc39612286ba66f250b6b26da01d38c0
The higher layers (gsm_04_08.c) are informed errors occur. But it
is not checked if the call was already released. If an error occurs
after the call control stack calls msc_mgcp_call_release() then
the higher layers might already have cleaned up and the code
accesses memory that is already freed (trans)
- fix use after free by guarding the call to mncc_tx_to_cc()
Change-Id: I78f1b6a9149488a4ad3f120c1e190a83c07d4b89
Related OS#2881
Related OS#2882
The naming of "bump" was short and made sense to me at the time of writing, but
it is keeping pretty much everyone else at a distance, no-one intuitively gets
what it is supposed to mean.
Clarify by renaming to "release_when_unused".
Adjust test expectations.
Change-Id: I4dcc55f536f63b13a3da29fff1df5fe16751f83a
gsm_04_08.c seems to contain some lines of old debug code that
is commented out. Presumably the commented lines are a leftover
from a debug session.
- remove those commented code lines
Change-Id: Ifb84e4b0696fef1326c3f9ebc8427581057db44f
Use the new gsm0808_dec_cell_id_list2() API to decode the cell
identifier in the bssap COMPLETE LAYER 3 information message.
Also, actually compare the MCC-MNC in WHOLE_GLOBAL and LAI_AND_LAC
cell identifiers to the network configuration, and drop messages
with mismatching MCC-MNC (addresses OS#2980).
Related: OS#2847
Related: OS#2980
Change-Id: I855477507e4d65fb9890da0ceea26dd2c4dfaf82
osmo-msc still uses endpoints that are allocated locally by the
MGCP-Client. Since osmo-mgw now supports the more comfortable,
dynamic variant we should make use of it.
- Replace the endpoint numer allocation by the client with a
wildcarded CRCX. Use the endpoint that is assigned by the
MGW.
Related: OS#2710
Change-Id: Iee3e446b6689626516f01c521abe3d4603cd3e13
When a truncation check (osmo_strlcpy()) fails handle_error()
is called with MGCP_ERR_NOMEM as cause code. Which finally
results in an "out of memory" message. MGCP_ERR_NOMEM is only
used for failed truncation checks, so it makes sense to choose
a message that describes the cause of the problem better.
- rename MGCP_ERR_NOMEM to MGCP_ERR_TOOLONG
- replace error message string
Change-Id: Ifedb85c1933a30b2aa491b495119919f45782e2c
Make sure to deactivate trans.cc.timer when freeing a CC transaction.
Log an error if should be necessary.
This prevents a segfault when we receive a BSSMAP Clear Request from BSC during
an ongoing CC operation. The BSSMAP Clear Request currently triggers immediate
freeing of the conn, while we should still do a graceful release first. While
this patch does not fix the underlying error, it does prevent the MSC from
crashing due to a stale timer, whatever the cause might be.
Related: OS#3062
Change-Id: I86b666f23402a6d94af2d903e514770d1fd5157f
When the FSM reaches ST_HALT it frees itsself and all context
information but it is not ensured that there are still pending
MGW transactions that might hit late and eventually cause a use after
free situation.
- if an MGW transaction is still pending, cancel it.
Change-Id: I8ff55e48a95cc4c556a97ad2593bad1cc1aa69bd
When the MGW does not respond to an MGCP message then the mgcp FSM
terminates, but the CC handler (gsm_04_08.c) is not informed. This
lets the CC handler think that the MGCP connection would be successful,
so it also does not take any action to release the non functional
connection.
- make sure the CC handler is always informed on any kind of
error, especially on MGW timeouts
Change-Id: I3fcd0d71fad53274e82f6d87c80042d06283bc5d
Related OS#2881
Related OS#2882
Since commit 2483f1b050 the function
gsm48_tx_mm_info() was not called anymore. No MM info messages were
transmitted to phones even if MM info messages were enabled via VTY.
With this commit, we call gsm48_tx_mm_info() after successfully
processing an IMSI ATTACH location update.
Change-Id: Ice5963d84253eb8c803cd2dfa8b25a4db5382827
Related: OS#2850
struct gsm0808_cell_id_list in libosmocore is deprecated by
https://gerrit.osmocom.org/#/c/6509/
This updates the only API user I am aware of.
Change-Id: I67377270cf3b081ac5dc9cd7b4dc28f74143753a
Depends: Ib7e754f538df0c83298a3c958b4e15a32fcb8abb
Define the struct vlr_ciph_result member .imeisv not as a char* but a char[] of
appropriate length, to avoid the need to point to external memory.
Thus fix a use-after-free in msc_cipher_mode_compl(), which defined the
imeisv[] buffer in a sub-scope within that function, so that the .imeisv
pointer was already invalid when fed to vlr_subscr_rx_ciph_res().
Did you notice that the commit summary rhymes?
Closes: OS#3053
Change-Id: I90cfb952a7dec6d104200872164ebadb25d0260d
Do not interpret the SRES/RES length returned in the auth response as the R99
capability bit, instead determine it from the actual Classmark information
associated with the conn.
This fixes the is_r99 flag passed in to vlr_subscr_rx_auth_resp(), which ends
up in the struct vlr_auth_resp_par dispatched to the auth_fi and influences the
authentication acceptance.
Though the effect of a wrongly-set-to-false R99 flag is not harmful in this
code path, let's not get this confused.
Change-Id: Ib7f7d89a8b9455d2c022d53d74328fa7488577f4
Instead of just closing down the conn hard, actually feed invalid auth response
data to vlr_subscr_rc_auth_resp() in order to trigger all the actions we want
to see with a failed authentication:
- a GSUP signal that the auth failed,
- a LU reject.
Verify this in new test_wrong_sres_length() in msc_vlr_test_gsm_authen.c.
Note that in gsm48_rx_mm_auth_resp(), the is_r99 flag is falsely derived from
the RES length, which upcoming commit Ib7f7d89a8b9455d2c022d53d74328fa7488577f4
will fix.
Change-Id: I4179a290069ac61d0662de4ec7ca3edb76988899
In gsm_silent_call_{start,stop}(), return meaningful error codes and interpret
them on the VTY to clearly indicate the result.
Change-Id: Id5abb8f2ba901689e03040af8e51483b6c618e7f
Rationale: in the HLR, it is called 'msisdn' after the database column, so a
user going back and forth between osmo-hlr and osmo-msc would appreciate being
able to type 'msisdn' in the MSC's vty as well.
Change-Id: I7b46f9736421e8edd8a95ae89e025ebe486fde4c
Before this, it was for example possible to crash the MSC by the vty 'show
subscriber' command, which would dereference a potentially stale
vsub->msc_conn_ref pointer.
Related: OS#3050
Change-Id: Ia4105d9f135ba3216ad3c86157be7658b1d568fb
When osmo-msc restarts it looses all information about the BSC. The
BSC will not be aware of the reboot and on the next communication
attemt it will notice that something is wrong and start the reset
procedure on his side. osmo-msc will receive the reset messages
and send a reset.
The reset is received. Osmo-msc detects that no context information
is created yet. The context is created. Then it is checked if the
UNITTDATA message that came in is a reset. If it is one. Nothing
happens. The UNITTDATA is passed on and triggers the RESET-ACK
some layers above. Unfortunately by the current code this also
means that no reset FSM is created and therefore a_reset_conn_ready()
can never be true. Which means it will also drop any legitimate
reset from the BSC in the future.
- Ensure that the reset FSM is always created when a new BSC
context is created
- Make sure that reset related traffic always passes so that
the higher layers can handle the procedure properly
Change-Id: I3fdcec5dbeaa0e21fd6a92568a623faa368239be
The vlr_subscr_get() can return NULL if its argument is NULL
(which isn't checked for) so before dereferencing it's result
we should check for it.
Change-Id: I13632908d0b67323202effa9dd6f29732a12cc91
Actually call msc_vlr_set_ciph_mode() and wrap away a_iface_tx_cipher_mode()
and ranap_iu_tx_sec_mode_cmd(). Hence we'll see decisions and errors in
msc_vlr_set_ciph_mode() as well.
Change-Id: Id23bc245d4b5707edcd27c44db272fbb211bf9bd
Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout
the code base to be able to handle an MNC < 100 that has three digits (leading
zeros).
Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore),
Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore)
Change-Id: I82f0016d9512ee8722a3489a3cb4b6c704a271fc
The FSM (fsm_msc_mgcp) lacks a proper definition of the FSM event
names. This causes problems when inspecting the FSM using the VTY.
- Add proper FSM Event names
Closes: OS#2924
Change-Id: I6823756a63b08a71e5518130e49751aa073dbcd2
Call osmo_fsm_vty_add_cmds() to make osmo_fsm VTY commands available
in osmo-msc's VTY interface.
Change-Id: Iaf970f6039c3f668f275dd8c21fb9071774a5d9e
Related: OS#2967
Change I0d57ac214e574e267fa9752daf76566197b9aa64 forgot to remove this
file along with meas_feed.c.
Note also the weirdness: that patch removes the proper
include/osmocom/msc/meas_feed.h, but there's also this other one.
This libmsc/meas_feed.h always existed from the start as an unused
orphan, see:
https://git.osmocom.org/osmo-bsc/diff/openbsc/src/libmsc/Makefile.am?id=b4771a6871efb3cf12b371aedc575912984ca528
No need to drop from Makefile.am, since it is already gone from there.
(meas_feed from the old osmo-nitb (openbsc.git) has / should have moved to
osmo-bsc. There are no measurement reports in the MSC. Refer to osmo-bsc.git
instead from now on.)
Change-Id: Ib2566013dd30b21ce2774cd4cc7dcba2408f938f
The ID will include the type of connection (GERAN_A, UTRAN_IU) followed
by the SCCP conn_id.
This can be used for the fsm instance ID before we know the IMSI.
Change-Id: I4b875772e3994ad3458ee60dbf880604486d9afd
OsmoMSC is using whatever reject cause is apropriate in the given
situation. This user-configurable reject cause only had relevance
in OsmoNITB, and hence it is an unused parameter that can be removed
in OsmoMSC.
Related: OS#2528
Change-Id: Ie1f39e706477aaf42051877b52d4b3ae1c5f138e
When we receive bearer capabilities from MNCC and encode thme into
a CC message, we have to also update our "cache" inside 'struct
gsm_trans'. Only that way, the BSSMAP ASSIGNMENT code is aware of
the actual current/present bearer capabilities such as permitted speech
codecs.
This will in practise only work if the related CC/MNCC message with
berer_cap IE will happen before the MSC performs the BSSMAP ASSIGNMENT
procedure. Our logic still needs to change in a way that the CC/MNCC
code in gsm_04_08.c detects if trans->bearer_cap != new bearer_cap, and
in that case triggers a new follow-up BSSMAP ASSIGNMENT.
Change-Id: I6838dc0c8c4c2c6bba385da548c92f3fc91060c1
Closes: OS#2854
When we receive a MNCC_SETUP_REQ primitive from the external MNCC
handler, we must not only encode it into the TS 04.08 CC SETUP, but
also keep it around in the "trans" structure representing this voice
call, as it is needed e.g. at BSSMAP ASSIGNMENT time.
Change-Id: Ib6919d148ff6687112e8166dbde947be19e70a76
Related: OS#2322
Closes: OS#2929
There is no encoding of speech version / preference on Abis, only
on L3. L3 is carried on Um, Abis and A. Hence, referrin to Abis
in function names and comments is irritating.
Change-Id: Id226cd1414ca2a92356801bc71f43102d03ba37e
We cannot use conn->a.conn_id after conn has been free'd inside
msc_clear_request(). Let's store conn_id before that call to
ensure we avoid an use-after-free situation.
A more elegant (but more intrusive) solution would be to
move the SCCP connection clearing into the FSM itself.
Change-Id: Ibe41aa503e9f7cbeb05dce4b1a20b3eac85e619f
Closes: OS#2922
As in GSM/3GPP networks emergency calls carry no explicit destination
number/address, add a VTY commadn to patch in some destination handler
in the EMERGENCY SETUP before delivering to [internal or external] MNCC.
Change-Id: I7c9f43ba312fadda2b9a9483b3cf50e4abca9599
When we receive a msgb-wrapped primitive from the SCCP provider (stack),
it transfers msgb ownership to us (the SCCP user). The existing code
passed the msgb ownership down into all the various downstream
functions, which each then had to take care of msgb free'ing.
Not all of the paths did eventually free the msgb. And at least one
path used data from the primitive *after* the free
Let's restructure this in a way that no msgb ownership is transferred
down the call chain. Instead, there's one common msgb_free() in
sccp_sap_up(). We can do this as nobody is queueing or otherwise
keeping the msgb.
Change-Id: Ie65616ccb55ec58a0224bbe3c8e004e6029ef3e6
SUMMARY: AddressSanitizer: heap-use-after-free /home/laforge/projects/git/osmo-msc/src/libmsc/a_iface.c:538 in sccp_sap_up
Having all BSSAP related logs in the "DMSC" category is overly
generic, and dosn't provide useful granularity.
Change-Id: Id1e52dad03840dfd026fb23f3845a8771c8cc308
There's little point in resolving the gsm_subscriber_connection in each
and every function handling connection-oriented messages. We can
resolve it once and dispatch the already-resolved conn into the
function, instead of passing the raw sccp_user and a_conn_info.
Change-Id: Iea85527ea4d4cde7b36cc28a8027362c1570518f
Clean up the log statements in a_iface*.c, which was very inconsistent.
For example "BSC sending" is very confusing. We are receiving from the BSC,
and it did already send the message, it is no longer in the process of
sending it if we have already received it in the MSC.
Change-Id: Id50e964d86713ae506d4e7657159797e09501d99
During normal operation, regular messages occurring during processing
of a call / transaction should not be higher than LOGL_INFO.
Change-Id: Ibd04ade47b249406696c7d0b660474afc4f4adee
If the BSC is contacting us for the first time and sending a BSSMAP
RESET, then we should simply ACK that and transition into the
"connected" state, where connection-oriented and connectionless
procedures are permitted.
This patch is a bit large for such a seemingly simple behavioural
change, but the existing data model didn't permit a more
straight-forward implementation.
Change-Id: Ie67e7ed20a6c42afe99bafef96d85a4e083dd057
Closes: OS#2914
Using this argument we can create the state machine in the
"already connected" state, i.e. without starting an outbound
RESET procedure.
Change-Id: Ibf569d57300965cd47084fa0bff54aa67679e2a1
It is quite important to have some way of runtime state introspection
about the major objects inside osmo-msc. This patch adds some basic
capabilities to dump the most important information about
subscriber_connections and transactions (like calls/sms).
OsmoMSC> show connection
--ConnId ------------Subscriber RAN --LAC Use --Tokens CSA A5 State
00000001 IMSI:26242000000006 A 23 1 00000004 --- /0 SUBSCR_CONN_S_COMMUNICATING
Change-Id: I1c457c1eac20188f67b8379a36cfda3a085fcef4
The MGCP FSM implements a timeout when waiting for the RAN to complete
the call (assignment complete, alerting, connect...). This timeout
is currently set to 10sec. This means if the other end did not pick
up after 10sec, the MGCP connection will be lost while the phone keeps
ringing. When the other end finally picks up, the call gets
disconnected.
This behavior is odd and requires a proper fix. For now increasing the
timeout to 120sec. will decrese the probability that he problem occurs.
- Increas RAN timeout to 120sec (2 min).
Change-Id: I5a11d53f9701d9b11b18d7026ff2241c7c0b57f5
We don't usually put space before in-place increment or decrement. Let's
make code look similar to other Osmocom projects.
Change-Id: I5962431ad16c97e412939dc1b8949f6361a5c26e
in the current implementation we still use osmo-bsc_mgcp, which
has many problems and is also obsoleted by osmo-mgw.
integrate osmo-mgw and re-implement the current switching using
an osmo fsm.
Depends: osmo-mgw Iab6a6038e7610c62f34e642cd49c93d11151252c
Depends: osmo-iuh I3c1a0455c5f25cae41ee19229d6daf299e023062
Closes: OS#2605
Change-Id: Ieea9630358b3963261fa1993cf1f3b563ff23538
Using following semantic patch:
@@ expression A, B, C; @@
- osmo_strlcpy(A, B, sizeof(A));
+ OSMO_STRLCPY_ARRAY(A, B);
Which was applied using following command:
spatch --dir src -I src --sp-file strlcpy.spatch --in-place --recursive-includes
All the calls to osmo_strlcpy() which use destination buffer obtained
via sizeof() were replaced with the corresponding wrapper macro.
Change-Id: I67b482dedfa11237ac21894fc5930039e12434ab
Related: OS#2864
According to TS 24.007 Section 11.2.3.2.3, it is possible that uplink L3
messages are duplicated in some scenarios, particularly during
assignment/handover procedure.
To avoid L3 entities from seeing duplicated messages, there's a modulo-2
or modulo-4 message sequence counter, based on which the MSC can detect
and suppress such duplicate messages.
It appears that even our unit tests were wrong in that regard so far.
Rather than manually adjusting each and every message, let's make sure
that the sequence number generation always increments as expected, and
that during matching of incoming messages, sequence numbers are masked
out.
Note: the tests will only pass from libosmocore Change-Id
Iec875a77f5458322dfbef174f5abfc0e8c09d464 onwards, due to
gsm48_hdr_msg_type() being broken in earlier versions.
Change-Id: Id15e399ab7e1b05dcd426b292886fa19d36082b1
Closes: #2908
Make the submit_to_sms() funcion aware of the message mode. If the
message does not require real-time "transactional/forward mode" we
can store it in the SMS database even if subscriber B cannot be
found in the VLR at this point in time.
This should should make the esme_ms_sms_storeforward test in
osmo-gsm-tester pass (a tweak to this test's expectations will
be needed as well, because the test currently assumes that an
invalid phone number for subscriber B will fail immediately,
rather than cause the message to eventually expire).
Change-Id: Ic3d78919568ad9252b4d19c3ddab5068d1c52db2
Related: OS#2354
There's no point of ever asking a MS to perform ciphering using an
algorithm it advertises no support for. Let's hence use CLASSMARK
information to figure out the intersection between MSC policy (VTY
command) and MS-reported CLASSMARK.
Change-Id: Id124923ee52a357cb7d3e04d33f585214774f3a3
So far, the administrator had to pick one particular cipher which
would then be used throughout all subscribers/phones. This is a bit
impractical, as e.g. not all phones support A5/3. Extend the VTY
command syntax in a backwards-compatible way to permit for multiple
ciphers.
NOTE: Like the previous code, OsmoMSC does *not yet check* whether
the configured cipher is compatible with the MS capabilities as
reported in CLASSMARK! The network hence might choose an algorithm
not supported by the phone. Fixing this is subject to another patch.
Closes: OS#2460
Change-Id: I79a4e2892eb5fbecc3d84e11dceffb7149db264b
The VLR code seems to have the assumption that there is one particular
algorithm to be used, as opposed to one of a set of algorithms.
What's missing is basically to decide when/where to pick the best
algorithm within the capabilities of the phone (classmark) and the
network configuration (net->a5_encryption_mask). So far, libvlr has no
notion of classmark. Rather, libmsc has.
Why does the VLR care about the particular algorithm at all? The VLR
should probably simply decide if it should use encryption or not, and if
so, the MSC will figure which algorithm to use.
Change-Id: I5ed80ca2086560a5975a758ec568a034a9a8ab89
Delete expired SMS whenever we are done processing an SMS-related signal.
In order to minimize additional latency only one SMS is removed at a time.
Change-Id: I56cbe716e52b679c4b94f6cbb4a171306975be2e
Related: OS#2354
Accept any SMS and store it in the database, even if the receiver of
the message cannot be determined when the message arrives at the MSC.
This fixes https://osmocom.org/issues/2354 ("SMSC: Store&Forward not
working for subscribed but unregistered MS").
Change-Id: I833c3abd290d2bc5fceec7457e3933c9600e6c24
Depends: Icd6093b7b5d8db84b19a0aa47c68182566113ee2
Depends: I56cbe716e52b679c4b94f6cbb4a171306975be2e
Depends: Icf786f9b1efabfe7407fb6414ec0d326d8f7244a
Related: OS#2354
We already delete SMS which have been sent successfully. However, there
are plans to accept SMS for any subscriber in order to fix the problem
described in https://osmocom.org/issues/2354 ("SMSC: Store&Forward not
working for subscribed but unregistered MS").
This means we may end up storing SMS which never get sent, e.g. because
the B subscriber doesn't actually exist. This could lead to a higher
degree of SMS database growth over time, and therefore we need a way
to keep database size under control.
As a first step, introduce a DB function which removes an expired SMS,
and add a VTY command which removes all expired SMS from the DB.
Later commits will build upon this to remove expired SMS automatically.
The SMS expiry time period is currently hard-coded to 2 weeks.
We could make this configurable in the future if desired.
Change-Id: Icd6093b7b5d8db84b19a0aa47c68182566113ee2
Related: OS#2354
osmo-msc still had large amounts of dead code that came along from
openbsc.git. This commit removes a lot of it, mostly stuff relevant
only to the BSC side of things (or even GPRS).
Change-Id: I247def85da2dc3ec461389fb74414a0d964e7e3c
Related: OS#2528
According to TS 44.008 Section 3.2.1.31, the "Layer 3 Message Contents"
IE of the BSSMAP Cipher Mode Complete is optional. The BSC may hence
inlcude that IE or not include it.
Without this patch, OsmoMSC is crashing if that IE was missing:
<000a> a_iface_bssap.c:699 Rx BSC DT: 00 03 55 2c 02
<000a> a_iface_bssap.c:629 Rx MSC DT1 BSSMAP CIPHER MODE COMPLETE
<001f> a_iface_bssap.c:91 Found A subscriber for conn_id 1
<000a> a_iface_bssap.c:415 BSC sends cipher mode complete (conn_id=1)
==5611== Invalid read of size 8
==5611== at 0x128D0F: msc_cipher_mode_compl (osmo_msc.c:159)
==5611== by 0x114F62: bssmap_rx_ciph_compl.isra.8 (a_iface_bssap.c:432)
==5611== by 0x113267: sccp_sap_up (a_iface.c:520)
Change-Id: I722f9b468b157b3736918f090daaa9489a6028ee
Closes: OS#2871
Even if we're not implementing CM re-establishment, we should give
the MS a clear indication that we don't do and follow the related
procedures of TS 24.008 by sending CM SERVICE REJECT.
Closes: OS#2869
Change-Id: I1c0473647295456fd635b8df6079ee48695dcf2e
Measurement reporting (and the relate feed) are functions of the BSC,
not the MSC. This code should never have been inherited from OsmoNITB
to OsmoMSC in the first place, let's remove it.
Change-Id: I0d57ac214e574e267fa9752daf76566197b9aa64
When we receive a CM Service Request, OsmoMSC should eventually verify
what kind of service it is the phone requests, and whether we support
that service.
Change-Id: I499730d760dc9ac7f599e09959c6eac4452f2eab
Closes: OS#2668
OsmoMSC rejects an Emergency Call with IMEI as mobile identity with
"semantically incorrect message" which is clearly wrong. According to TS
24.008 4.5.1.5 we should reject with cause 5 "IMEI not accepted"
Found with TTCN-3 test case MSC_Tests.TC_emerg_call_imei
Change-Id: I2f7ab0e32b914a112c0b17c523d149ccd0299099
Closes: #2866
MNCC has a MNCC_F_EMERGENCY flag to indicate that the mncc.emergency
field is present. However, OsmoMSC never sets this flag.
Change-Id: I0ebd8f88e483172988f4a0cb0636b4160688d8ad
Closes: OS#2865
An emergency call should be logged different from a normal call,
and we also increase the log level from INFO to NOTICE in such a
situation.
Change-Id: I83f3b8bd0aeda70f03aa7b8d264a9008d10d5687
There appears to have been no input validation whatsoever on MNCC
messages. Hence it was very easy for an external MNCC handler to
crash OsmoMSC, such as in OS#2853
Change-Id: Idaf3b8e409c84564b1eb26d01a19c605f89b14f4
Closes: OS#2853
Quote the argument to sqlite's datetime(). Otherwise, the timestamp
stored in the database reads back as a negative value for some reason.
Before:
1032 validity_timestamp = dbi_result_get_datetime(result, "valid_until");
(gdb) p validity_timestamp
$2 = -1516814654
After:
1032 validity_timestamp = dbi_result_get_datetime(result, "valid_until");
(gdb) p validity_timestamp
$2 = 1516814654
Change-Id: Icf786f9b1efabfe7407fb6414ec0d326d8f7244a
As the include file gsm_data.h is generic (does not depend on osmo-iuh0s
iu_client.h), rab_assign_addr_enc is declared as "int" instead of "enum ranap_nsap_addr_enc".
osmo-msc/src/libmsc/msc_vty.c: In function ‘msc_vty_init’:
osmo-msc/src/libmsc/msc_vty.c:212:30: warning: passing argument 2 of ‘ranap_iu_vty_init’ from incompatible pointer type [-Wincompatible-pointer-types]
ranap_iu_vty_init(MSC_NODE, &msc_network->iu.rab_assign_addr_enc);
^
Change-Id: I1b63ee350911bdf772a2324fff55035275a455c4
Compute a validity timestamp based on SMS validity time.
Store the computed value in the database and recompute the validity
time when an SMS is read from the database.
Change-Id: Id27c250d3a64cd109416450e8ca155b18a8b9568
Currently the SMS database keeps accumulating entries for each SMS.
These entries are never deleted automatically. With this change, we
start deleting SMS which have successfully been sent to subscriber B.
Change-Id: I3749855fe25d9d4e37ec96b0c2bffbc692b66a78
If we cannot open a connection to the sqlite3 database, show the name of the
database we failed to access, and also hint at the fact that a likely reason
for the problem is a missing sqlite3 driver for libdbi.
Change-Id: If1c0026e882984b4358ce116ec4a7ad40340517c
There is no any significant reason to define static function
'send_own_number' after the code that calls it.
Change-Id: I7f76f278c09489dccd96921610e8d06efa679ff2
* move log helpers to generic header
* log subscriber update
It's handy for troubleshooting issues with subscriber update via GSUP
from HLR.
Change-Id: I1958aeeb3ea99831c7e2c5ee9a6b59834baf4520
The expire_lu is never used but is printed for every subscriber. Let's
remove it to avoid confusion.
Change-Id: I6f7ad1670836384d1e6a58f47a13464fdbbf8509
This avoids potential licensing incompatibility and makes integration of
Debian packaging patches easier.
Related: OS#1694
Change-Id: I71cd631704a4dc155c6c752fee2a42cd6e2fa336
It's not clear cut which code is responsible for canceling pending requests,
since the requests list is kept in vlr_subscr, but sending out Paging does
certainly not belong in the VLR. Place the requests cleanup in gsm_04_08.c.
Add to test_ms_timeout_paging() in msc_vlr_test_ms_timeout.c to verify that a
pending paging is canceled on IMSI Detach.
Change-Id: Ib8874a9d92f02b0826525b55518332f6899688fd
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
These rx functions are only used for the A interface, hence the names should
not suggest general SCCP rx (which Iu also has).
Change-Id: I6815c3d4dea4c2abfdff1cf0239ada6a9254f351
Add LOGPBSCCONN for struct bsc_conn.
Use LOGPCONN or LOGPBSCCONN whereever possible.
Tweak a few log messages and remove one redundant log.
Change-Id: If9cb0e7a5cef2ec37a1a7c548aecf11a11c22eec
The target buffer in libsmpp is 16 bytes long, and snprintf() may omit the
terminating zero. There seems to be no handling for unterminated strings, so
osmo_strlcpy() is the safer (and presumably more optimal) choice.
Change-Id: I5845666201f945ea9f83da62f2dd4bec52eb74cf
In case of UMTS AKA, the Kc for ciphering must be derived from the 3G auth
tokens. tuple->vec.kc was calculated from the GSM algorithm and is not
necessarily a match for the UMTS AKA tokens.
So far we were always sending the Kc retrieved from osmo-hlr. If the 2G auth
algo is set to milenage, the 2G Kc coincides with the one derived from 3G
tokens, but if 2G is set to a different algorithm, the Kc received from the
osmo-hlr is not usable for ciphering when UMTS AKA was used for authentication
(on R99 capable GERAN and MS).
Implementation: To decide whether to use UMTS AKA derived Kc or the Kc from the
auth vector, use the umts_aka flag added to set_ciph_mode() in a previous
patch. Use osmo_auth_c3() to derive the GSM AKA Kc from the UMTS AKA CK and KI.
Related: OS#2745
Requires: I85a1d6ae95ad9e5ce9524ef7fc06414848afc2aa (libosmocore)
Change-Id: If04e405426c55a81341747a9b450a69188525d5c
In case of UMTS AKA, the Kc for ciphering must be derived from the 3G auth
tokens. tuple->vec.kc was calculated from the GSM algorithm and is not
necessarily a match for the UMTS AKA tokens.
To decide (in an upcoming patch) whether to use UMTS AKA derived Kc or the Kc
from the auth vector, the set_ciph_mode() from vlr_ops needs to know whether
UMTS AKA is being used. This could possibly derived from the msc_conn_ref, but
all flags are already available in the vlr_lu_fsm and vlr_access_req_fsm. Hence
add a umts_aka flag to the set_ciph_mode() callback invocation. The VLR FSMs
thus decide whether UMTS AKA or GSM AKA is to be used during Ciphering Mode
Command, which makes more sense than re-implementing the same decision process
in the MSC.
I considered placing the Kc derivation in vlr_set_ciph_mode() and only tell the
MSC's set_ciph_mode() implementation the precise keys it should use, but the
RAN particulars, and whether a Kc is used at all, rather belong with the MSC.
Related: OS#2745
Prepares: If04e405426c55a81341747a9b450a69188525d5c
Change-Id: I983c48347faf4ee1b405d8174b4e006c904157cf
a_iface_tx_cipher_mode() is a bit too far away from the VLR to be handling its
ciphering enums. Instead, construct the gsm0808_encrypt_info in the
msc_vlr_set_ciph_mode() callback.
Greatly simplify the sanity checking code: a_iface_tx_cipher_mode() no longer
needs to re-verify the presence of the gsm0808_encrypt_info contents.
Change-Id: Id46f9a513b555d0a481f7124c9984c2b5b196b3e
The bit shifting is performed in gsm0808_enc_encrypt_info(), and must not be
done when populating the gsm0808_encrypt_info struct.
Provide vlr_ciph_to_gsm0808_alg_id() to translate the enum vlr_ciph to the
GSM0808_* constants we need to put in the gsm0808_encrypt_info struct instead.
Related: OS#2745
Change-Id: If75f95e8a5cc8b9979610ce6d746c1f0073ee39a
When the subscriber has no MSISDN, we might construct an invalid SQL statement
such as
... AND dest_addr= AND ...
Instead, don't even query for empty MSISDNs.
Related: OS#2706
Change-Id: I7d6169d774b2da04b3051957e364fe620feed51e
Adjust test expectations accordingly.
The error was:
==16084==ERROR: AddressSanitizer: heap-use-after-free on address 0x61500000f5f4 at pc 0x561be639ac2b bp 0x7ffc0aabbe40 sp 0x7ffc0aabbe38
READ of size 4 at 0x61500000f5f4 thread T0
#0 0x561be639ac2a in _msc_subscr_conn_put ../../../../src/osmo-msc/src/libmsc/osmo_msc.c:384
#1 0x561be636070b in rx_from_ms ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_tests.c:204
#2 0x561be6360b21 in ms_sends_msg ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_tests.c:217
#3 0x561be635b40a in test_call_mt ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_test_call.c:328
#4 0x561be6363bb7 in run_tests ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_tests.c:802
#5 0x561be63524ea in main ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_tests.c:849
#6 0x7f6eebb3e2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#7 0x561be6352fb9 in _start (/n/s/osmo/make-3G/osmo-msc/tests/msc_vlr/msc_vlr_test_call+0xdafb9)
Related: OS#2672
Change-Id: If0659a878deb383ed0300217e2c41c8c79b2b6a5
If a conn is attempted to be used when in release, log an error, but don't skip
tracking.
No current code path apparently hits this, according to msc_vlr_tests. Just
making sure that we will prominently see such errors when we introduce any.
Change-Id: I8dd20ee56ce5ad7a90fcd03a06604c383e5eed54
When hunting a conn use count bug, it was very hard to figure out who's (not)
using the conn. To ease tracking down this bug and future bugs, explicitly name
what a conn is being reserved for, and track in a bit mask.
Show in the DREF logs what uses and un-uses a conn. See the test expectation
updates, which nicely show how that clarifies the state of the conn in the
logs.
On errors, log them, but don't fail hard: if one conn use/un-use fails, we
don't want to crash the entire MSC before we have to.
Change-Id: I259aa0eec41efebb4c8221275219433eafaa549b
Philipp Maier
Neels Hofmeyr
Keith Whyte
Harald Welte
Pau Espin
Daniel Willmann
Alexander Huemer