gsm_network contains an int handover.active which is always zero. Drop it.
There is real handover code coming up soon, one part of this is to avoid
confusion.
The internal MNCC code queried it to decide whether to MNCC_BRIDGE or proxy RTP
(MNCC_FRAME_RECV). Since RTP is being handled by osmo-mgw since forever, drop
that entire condition from mncc_builtin.
Change-Id: Ie16e718266882588b38297121364ca0b7fdfe948
According to GSM TS 04.11, the SMC (Short Message Control) state
machine is a part of CM-sublayer of L3, that is responsible for
connection management (establisment and releasing), and SM-RP
(Relay Protocol) message delivery.
For some reason, the connection establisment request from SMC
(GSM411_MMSMS_EST_REQ) was not handled properly - it was
always assumed that connection is already established.
This is why the code initiating a MT (Mobile Terminated) SMS
transfer had to establish a radio connection with subscriber
manually.
Let's benefit from having the SMC state machine, and offload
connection establishment to it. This change makes the local
implementation closer to GSM TS 04.11, and facilitates the
further integration of GSUP transport.
NOTE: the expected unit test output is changed, because now we
always allocate a transaction first, and then establish a
connection, not vice versa.
Change-Id: I4a07ece80d8dd40b23da6bb1ffc9d3d745b54092
According to GSM TS 04.11, section 8.2.3, the RP Message Reference
is a mandatory field for all messages on the SM-RL (SM Relay Layer),
that is used to link an RP-ACK or RP-ERROR message to the associated
(preceding) RP-DATA or RP-SMMA message transfer attempt.
This change extends the transaction state structure with SM-RP-MR,
and introduces a new function for matching transactions within a
given connection by this reference.
Change-Id: Ice47c37ecef4416e65ecee8931d946c915316791
Count COMPLETE and REJECT messages. Besides general troubleshooting
that's also useful for TTCN-3 tests to check that OsmoMSC processed
those messages as expected.
Change-Id: I5822b2b38b64f1a691b26c926a8e2bece21dc624
Related: OS#3187
The external MNCC handler may hang indefinitely in cases where the remote
end of the MNCC ceases to work properly. Add a global guard timer to
make sure the call reaches ACTIVE state.
Change-Id: I7375d1e17cd746aac4eadfe1e587e82cf1630d3d
Related: OS#3599
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
The intention was to use the file's basename, but __BASE_FILE__ means "the root
file that is being parsed and contains #include statements".
If we had a function using __BASE_FILE__ and that was defined in an #included
file, __BASE_FILE__ would indicate the first file where the #include is, and
not the file where the function is defined. __BASE_FILE__ works for us because
we don't ever include function definitions that log something, so __BASE_FILE__
always coincides with __FILE__ for our logging; but still __BASE_FILE__ is
semantically the wrong constant.
Related: OS#2740
Change-Id: I1c8122c909938daaf782468c1c5b0262d555c3ce
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
libosmogsm in libosmocore.git from Change-Id
Ie36729996abd30b84d1c30a09f62ebc6a9794950 onwards contains oap_client.c,
so we don't need our local copy here in this repo anymore.
Change-Id: Ib6496c35d0ce6eb531e97129dc45a9f68e503b34
Requires: libosmocore.git Change-Id Ie36729996abd30b84d1c30a09f62ebc6a9794950
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
All callers pass mcc=1, mnc=1, so just have it as default.
(Prepare for net->country_code etc to be replaced by net->plmn)
Change-Id: Ibcd1cc38f170895305ae176a5574384c74a33939
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
This is another left-over VTY command from the OsmoNITB days.
If such functionality is desired, it must be implemented in OsmoHLR,
but not here.
Related: OS#2528
Change-Id: Icf0897c47388e49ba7886b55acc728a6f7d213fe
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
This belongs into the BSC and has no relevance in the MSC, as the MSC
has no clue about dynamic timeslots.
Related: OS#2528
Change-Id: Iaa41d22db81120572d4cd2c0c4c75d258947a42f
The mncc_rtp_create_pending and mncc_rtp_connect_pending members
were unused, let's remove them.
Related: OS#2528
Change-Id: I417e23ec53323ddd8e1e5d18952566fe8fd6ac24
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
Having all BSSAP related logs in the "DMSC" category is overly
generic, and dosn't provide useful granularity.
Change-Id: Id1e52dad03840dfd026fb23f3845a8771c8cc308
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
Check and handle gracefully any error which might appear in
osmo_gsup_encode() - mark corresponding functions with
warn_unused_result attribute to make sure this failure is always checked
against.
Change-Id: I4551212011fb0bd898c020a183756ed7a9afb9e5
Related: OS#2864
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
conn_id is modeled as int, but should be uint32_t.
- change conn_id from int to uint32_t
Change-Id: Ibf14d7c9a547c4eeb873975e7dcddef223e7df46
Related: OS#2769
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
This leads to faster recovery in case of link loss.
It also makes the TTCN-3 test suite run much faster, as each test case
will inherently terminate the GSUP connection.
Change-Id: I16821a26f2c6ff4d0a76926c9212127ab6f6fedf
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
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
We don't have BSC or GPRS related logging filters here.
This is a leftover from the NITB->MSC split
Change-Id: I05f991d1f5b7f89545521a73d79619bee4111094
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
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
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
Neels Hofmeyr
Philipp Maier
Harald Welte
Pau Espin
Daniel Willmann