When 'check-imei-rqd 1 early' is set in the config, send the IMEI to
the HLR before doing the location update with the HLR.
The OsmoHLR documentation referenced in the code will be added in
osmo-hlr.git's Change-Id I2dd4a56f7b8be8b5d0e6fc32e04459e5e278d0a9.
Related: OS#2542
Change-Id: I88283cad23793b475445d814ff49db534cb41244
Copy IMEISV to IMEI when IMEISV changes. The additional SV digits will
get cut off then. This is needed for the subscriber on demand use case,
since we can get the IMEISV early (see [1]), but need to send the IMEI
to the Check IMEI procedure.
While adjusting the tests, I have noticed that there are code paths
where we ask the MS for the IMEISV first, and later ask the MS for the
IMEI, although we already have the IMEISV. This could be improved in a
future patch.
[1] Change-Id I256224194c3b8caf2b58a88d11dccd32c569201f
Related: OS#2542
Change-Id: I02e7b66848bf7dddb31b105e2ae981432817ae1e
Set the length of vlr_subscr->imei to
GSM23003_IMEI_NUM_DIGITS_NO_CHK (14)
instead of
GSM23003_IMEISV_NUM_DIGITS (16).
Note that there is also GSM23003_IMEI_NUM_DIGITS (15), which includes
an additional checksum digit. This digit is not intended for digital
transmission, so we don't need to store it. Also by not storing it, we
can simply copy the IMEI-part from the IMEISV to the IMEI without
worrying about the checksum (will be done in a follow up patch).
A good overview of the IMEI/IMEISV structure is here:
https://en.wikipedia.org/wiki/International_Mobile_Equipment_Identity#Structure_of_the_IMEI_and_IMEISV_(IMEI_software_version)
Related: OS#2542
Change-Id: Iaf2569c099874b55acbd748b776394726cc5ce54
The librt is required for old glibc < 2.17 to get clock_gettime().
Since we do check the availability of this function libosmocore
and conditionally link it against librt, there is no need to do
such unconditional and redundant linkage here.
Change-Id: If587d16d2db677b97e3a0641027eb735af9c9c30
Instead of calling trans_log_subsys() for each LOG_TRANS() log line, rather
store in trans->log_subsys once on trans_alloc() and use that.
Do not fall back to the RAN's own subsystem (DBSSAP / DIUCS), it makes little
sense and may cause logging to switch subsystems depending on the RAN state.
In trans_log_subsys(), add missing switch cases:
- Log silent call transactions also on CC.
- Log USSD on DMM.
About USSD: we currently have no dedicated USSD logging category. As a result,
after LOG_TRANS() was introduced [1], USSD logged on DBSSAP/DIUCS or DMSC,
depending on whether a RAN was associated with the trans or not. Before that
change, USSD always logged on DMM, so, until we have a separate logging
category for USSD, consistenly use DMM again.
[1] in I2e60964d7a3c06d051debd1c707051a0eb3101ba / ff7074a0c7
Related: coverity CID 198453
Change-Id: I6dfe5b98fb9e884c2dde61d603832dafceb12123
While developing the inter-MSC handover refactoring, I was annoyed by the fact
that mncc_tx_to_cc() receives an MNCC message struct containing a msg_type, as
well as a separate msg_type argument, which may deviate from each other. So, as
a first step I wanted to make sure that all callers send identical values for
both by inserting an OSMO_ASSERT(msg_type == msg->msg_type). Later I was going
to remove the separate msg_type argument.
I then forgot to
- carry on to remove the argument and
- to actually test with internal MNCC (it so happens that all of our ttcn3
tests also use external MNCC).
As a result, the "large refactoring" patch for inter-MSC Handover breaks
internal MNCC operation.
Fix that: remove the separate msg_type argument and make sure that all callers
of mncc_tx_to_cc() indeed pass the desired msg_type in msg->msg_type, and hence
also remove the odd duality of arguments.
Various functions in mncc_builtin.c also exhibit this separate msg_type
argument, which are all unused and make absolutely no sense. Remove those as
well.
Related: OS#3989
Change-Id: I966ce764796982709ea3312e76988a95257acb8d
3GPP TS 49.008 '4.3 Roles of MSC-A, MSC-I and MSC-T' defines distinct roles:
- MSC-A is responsible for managing subscribers,
- MSC-I is the gateway to the RAN.
- MSC-T is a second transitory gateway to another RAN during Handover.
After inter-MSC Handover, the MSC-I is handled by a remote MSC instance, while
the original MSC-A retains the responsibility of subscriber management.
MSC-T exists in this patch but is not yet used, since Handover is only prepared
for, not yet implemented.
Facilitate Inter-MSC and inter-BSC Handover by the same internal split of MSC
roles.
Compared to inter-MSC Handover, mere inter-BSC has the obvious simplifications:
- all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc
instance,
- messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface
(GSUP),
- no call routing between MSC-A and -I via MNCC necessary.
This is the largest code bomb I have submitted, ever. Out of principle, I
apologize to everyone trying to read this as a whole. Unfortunately, I see no
sense in trying to split this patch into smaller bits. It would be a huge
amount of work to introduce these changes in separate chunks, especially if
each should in turn be useful and pass all test suites. So, unfortunately, we
are stuck with this code bomb.
The following are some details and rationale for this rather huge refactoring:
* separate MSC subscriber management from ran_conn
struct ran_conn is reduced from the pivotal subscriber management entity it has
been so far to a mere storage for an SCCP connection ID and an MSC subscriber
reference.
The new pivotal subscriber management entity is struct msc_a -- struct msub
lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however
use msc_a, since MSC-A is where all the interesting stuff happens.
Before handover, msc_i is an FSM implementation that encodes to the local
ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM
implementation that instead forwards via/from GSUP. Same goes for the msc_a
struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the
msc_a->fi is an FSM implementation that merely forwards via/from GSUP.
* New SCCP implementation for RAN access
To be able to forward BSSAP and RANAP messages via the GSUP interface, the
individual message layers need to be cleanly separated. The IuCS implementation
used until now (iu_client from libosmo-ranap) did not provide this level of
separation, and needed a complete rewrite. It was trivial to implement this in
such a way that both BSSAP and RANAP can be handled by the same SCCP code,
hence the new SCCP-RAN layer also replaces BSSAP handling.
sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN
connections. A set of callback functions provides implementation specific
details.
* RAN Abstraction (BSSAP vs. RANAP)
The common SCCP implementation did set the theme for the remaining refactoring:
make all other MSC code paths entirely RAN-implementation-agnostic.
ran_infra.c provides data structures that list RAN implementation specifics,
from logging to RAN de-/encoding to SCCP callbacks and timers. A ran_infra
pointer hence allows complete abstraction of RAN implementations:
- managing connected RAN peers (BSC, RNC) in ran_peer.c,
- classifying and de-/encoding RAN PDUs,
- recording connected LACs and cell IDs and sending out Paging requests to
matching RAN peers.
* RAN RESET now also for RANAP
ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also
supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide
proper RESET handling, which it so far duly ignores. (TODO)
* RAN de-/encoding abstraction
The RAN abstraction mentioned above serves not only to separate RANAP and BSSAP
implementations transparently, but also to be able to optionally handle RAN on
distinct levels. Before Handover, all RAN messages are handled by the MSC-A
role. However, after an inter-MSC Handover, a standalone MSC-I will need to
decode RAN PDUs, at least in order to manage Assignment of RTP streams between
BSS/RNC and MNCC call forwarding.
ran_msg.h provides a common API with abstraction for:
- receiving events from RAN, i.e. passing RAN decode from the BSC/RNC and
MS/UE: struct ran_dec_msg represents RAN messages decoded from either BSSMAP
or RANAP;
- sending RAN events: ran_enc_msg is the counterpart to compose RAN messages
that should be encoded to either BSSMAP or RANAP and passed down to the
BSC/RNC and MS/UE.
The RAN-specific implementations are completely contained by ran_msg_a.c and
ran_msg_iu.c.
In particular, Assignment and Ciphering have so far been distinct code paths
for BSSAP and RANAP, with switch(via_ran){...} statements all over the place.
Using RAN_DEC_* and RAN_ENC_* abstractions, these are now completely unified.
Note that SGs does not qualify for RAN abstraction: the SGs interface always
remains with the MSC-A role, and SGs messages follow quite distinct semantics
from the fairly similar GERAN and UTRAN.
* MGW and RTP stream management
So far, managing MGW endpoints via MGCP was tightly glued in-between
GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP
streams between different RAN peers by moving to object-oriented
implementations: implement struct call_leg and struct rtp_stream with distinct
FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated
from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose.
Instead of implementing a sequence of events with code duplication for the RAN
and CN sides, the idea is to manage each RTP stream separately by firing and
receiving events as soon as codecs and RTP ports are negotiated, and letting
the individual FSMs take care of the MGW management "asynchronously". The
caller provides event IDs and an FSM instance that should be notified of RTP
stream setup progress. Hence it becomes possible to reconnect RTP streams from
one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP
peers (inter-MSC Handover) without duplicating the MGCP code for each
transition.
The number of FSM implementations used for MGCP handling may seem a bit of an
overkill. But in fact, the number of perspectives on RTP forwarding are far
from trivial:
- an MGW endpoint is an entity with N connections, and MGCP "sessions" for
configuring them by talking to the MGW;
- an RTP stream is a remote peer connected to one of the endpoint's
connections, which is asynchronously notified of codec and RTP port choices;
- a call leg is the higher level view on either an MT or MO side of a voice
call, a combination of two RTP streams to forward between two remote peers.
BSC MGW PBX
CI CI
[MGW-endpoint]
[--rtp_stream--] [--rtp_stream--]
[----------------call_leg----------------]
* Use counts
Introduce using the new osmo_use_count API added to libosmocore for this
purpose. Each use token has a distinct name in the logging, which can be a
globally constant name or ad-hoc, like the local __func__ string constant. Use
in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count
API.
* FSM Timeouts
Introduce using the new osmo_tdef API, which provides a common VTY
implementation for all timer numbers, and FSM state transitions with the
correct timeout. Originated in osmo-bsc, recently moved to libosmocore.
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore)
Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore)
Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp)
I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw)
Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw)
I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)
Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
Start using osmo_fsm_term_safely(true), the recently added feature of
libosmocore's fsm.c. Deallocates in slightly changed order and with slightly
modified logging. Adjust test expectations.
Depends: I8eda67540a1cd444491beb7856b9fcd0a3143b18 (libosmocore)
Change-Id: I195a719d9ec1f6764ee5a361244f59f0144dc253
For some reason the existing code was using msgb_hexdump_l2() while the
L2 header is not used by the BSSAP transmit code. Let's fix this.
Change-Id: I52a1eb3a867ece63fcfa4c2a720d035ebfb90a7b
We don't want multiple callers to osmo_sccp_tx_data_msg() each having
to hex-dump a log message about the to-be-transmitted message, with
half of the caller sitest missing that printing. Let's centralize
all calls of osmo_sccp_tx_data_msg() in a wrapper function which
takes care of the related OSMO_ASSERT() and the related printing.
Change-Id: I6159ea72cc8e0650eda6c49544acd65e9c15e817
This simplifies tests refactoring by showing exact byte where mismatch
happened. It also makes code more readable.
No changes in expected test output are necessary because the additional
logging will be triggered iff the test fails so the result will be
visible only during debugging of unit test issues.
Change-Id: If9771c973f2bc55580f4c146bdbeeb1609d56786
Add an SGs interface (3GPP TS 29.118) to osmo-msc in order to support
SMS tunneling and Circuit Switched Fallback (CSFB)
Change-Id: I73359925fc1ca72b33a1466e6ac41307f2f0b11d
Related: OS#3615
The likely reason why it was disabled is due to
paging_cb_mmsms_est_req() logging pointers which results in unstable log
output. Fixing this allows us to track SMS-related regressions properly.
Change-Id: I44ae817d9edb73d182ff33ff5a2fd942e224e344
When check-imei-req is enabled in the VTY config, do not accept IMEIs
sent by the ME directly anymore. Send the IMEI to the EIR/HLR and wait
for its ACK or NACK.
OsmoHLR also accepts all IMEIs at this point, but this allows to
optionally store the IMEI in the HLR DB.
Depends: Ib240474b0c3c603ba840cf26babb38a44dfc9364 (osmo-hlr)
Related: OS#3733
Change-Id: Ife868ed71c36cdd02638072abebf61fc949080a7
ran_conn_get_conn_id(): instead of a talloc allocated string, return a static
buffer in ran_conn_get_conn_id(). So far this function had no callers.
Refactor ran_conn_update_id() API: during early L3-Complete, when no subscriber
is associated yet, update the FSM Id by the MI type seen in the L3 Complete
message: ran_conn_update_id_from_mi(). Later on set the vsub and re-update.
Call vlr.ops->subscr_update when the TMSI is updated, so that log context
includes the TMSI from then on.
Enrich context for vlr_subscr_name and ran_conn fi name.
Include all available information in vlr_subscr_name(); instead of either IMSI
or MSISDN or TMSI, print all of them when present. Instead of a short log,
rather have more valuable context.
A context info would now look like:
Process_Access_Request_VLR(IMSI-901700000014706:MSISDN-2023:TMSI-0x08BDE4EC:GERAN-A-3:PAGING_RESP)
It does get quite long, but ensures easy correlation of any BSSAP / IuCS
messages with log output, especially if multiple subscribers are busy at the
same time.
Print TMSI and TMSInew in uppercase hexadecimal, which is the typical
representation in the telecom world.
When showing the RAN conn id
GERAN_A-00000017
becomes
GERAN-A-23
- We usually write the conn_id in decimal.
- Leading zeros are clutter and might suggest hexadecimal format.
- 'GERAN-A' and 'UTRAN-Iu' are the strings defined by osmo_rat_type_name().
Depends: I7798c3ef983c2e333b2b9cbffef6f366f370bd81 (libosmocore)
Depends: Ica25919758ef6cba8348da199b0ae7e0ba628798 (libosmocore)
Change-Id: I66a68ce2eb8957a35855a3743d91a86299900834
When a CM Service Req is being rejected, we should do so before changing the
state of the current conn.
Concerning multiple CM Service Requests: in fact we should store multiple
requests, but first fix the status quo of rejecting multiple requests.
Change-Id: I39209ee6662694aa054a2fc0d21eae76fb33e2f1
For each conn, set a default logging category, to distinguish categories for
BSSMAP and RANAP based conns.
LOG_RAN_CONN(): log with the conn's default category,
LOG_RAN_CONN_CAT(): log with a manually set category (mostly for keeping
previous DMM logging on the same category).
In some places, replace LOGP() using manual context with LOG_RAN_CONN(), and
remove the manual context info, now provided by the conn->fi->id.
This is loosely related to inter-BSC and inter-MSC handover: to speed up
refactoring, I want to avoid the need for manual logging context and just use
this LOG_RAN_CONN().
Change-Id: I0a7809840428b1e028df6eb683bc5ffcc8df474a
Replace locally defined enum ran_type with libosmocore's new enum
osmo_rat_type, and value_string ran_type_names with osmo_rat_type_names.
The string representations change, which has cosmetic effects on the test suite
expectations.
Depends: I659687aef7a4d67ca372a39fef31dee07aed7631 (libosmocore)
Change-Id: I2c78c265dc99df581e1b00e563d6912c7ffdb36b
Various places in the code check a flag whether assignment was started and
launch it. To fix incoming-call-during-ongoing-call, I will tweak that logic.
To be able to do that only in one place, remove code dup.
Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and
I0ba216b737909e92080a722db26e3577726c63cb/
Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore: LOGPFSMSL)
Change-Id: I11c0b7dc3f1a747028629b48e522bb3b864884ba
Always use LAC which is part of Cell Global ID otherwise we might end up
in a situation where separately stored LAC differs.
Both are described in 3GPP TS 23.008 $2.4 as temporary subscriber data
to be stored in VLR. Both are defined in 3GPP TS 23.003. The LAC is part
of LAI which is part of CGI so there should be no case when those values
differ for a given subscriber.
Change-Id: I993ebc3e14f25e83124b6d3f8461a4b18f971f8e
Avoid leaking details on accessing data structure for LAC value into
test output: that's irrelevant clutter which forces unnecessary test
output modifications.
Change-Id: I4a1d7884cf47ad513d7d6fb27c5c6f1b829dff2e
To avoid leaking structure details into test we sometimes have to
separate value description from actual value. Introduce new macro which
makes that possible and convert old one into trivial wrapper around it.
Change-Id: Ic462297edac4c55689f93cc45771c8b5e2aed864
Add a 'ipa-name' VTY command which overrides the default IPA name
used by the MSC. This is a prerequisite for inter-MSC handover.
Related: OS#3355
Change-Id: I317d6c59f77e92fbb2b875a83dc0ec2fa5cb6006
sub_pres_vlr_fsm_start() starts the FSM, invokes the START event, and then this
FSM invariably always directly terminates when vsub->ms_not_reachable_flag ==
false.
So if it is false, there is not much use in instantiating a whole FSM instance
that just terminates again, we might as well directly issue the
parent-term-event and save some logging space.
The same condition is already in place in the vlr_proc_acc_fsm.c in
_proc_arq_vlr_node2_post_vlr() for CM Service Request and Paging Response. Now
also skip this for LU.
Change-Id: Id2303a795dfd381f76e94ff8ff2f495926ca8ba0
Along goes GSM_KEYSEQ_INVAL as VLR_*.
It's where it logically belongs, and is almost the only reason why vlr.h
includes gsm_data.h. The remaining reason, GSM_EXTENSION_LENGTH, will be moved
by upcoming patch.
Change-Id: I122feae7ee3cbc59e941daef35a954bce29fec76
For hysterical raisins, there are some header files that contain few
declarations, and where the name doesn't reflect the content. Combine them to
new msc_common.h:
- common.h
- common_cs.h
- osmo_msc.h
Change-Id: I9e3a587342f8d398fb27354a2f2475f8797cdb28
Following previous rename of gsm_subscriber_connection:
Some functions and #defines are still called like "msc_conn" or just "msc_",
while they are clearly about a RAN conn.
To avoid confusion with the future separate concepts of MSC roles and a RAN
connection, rename all those to match the common "ran_conn" prefix.
Change-Id: Ia17a0a35f11911e00e19cafb5d7828d729a69640
In preparation for inter-BSC and inter-MSC handover, we need to separate the
subscriber management logic from the actual RAN connections. What better time
to finally rename gsm_subscriber_connection.
* Name choice:
In 2G, this is a connection to the BSS, but even though 3GPP TS commonly talk
of "BSS-A" and "BSS-B" when explaining handover, it's not good to call it
"bss_conn": in 3G a BSS is called RNS, IIUC.
The overall term for 2G (GERAN) and 3G (UTRAN) is RAN: Radio Access Network.
* Rationale:
A subscriber in the MSC so far has only one RAN connection, but e.g. for
inter-BSC handover, a second one needs to be created to handover to. Most of
the items in the former gsm_subscriber_connection are actually related to the
RAN, with only a few MM and RTP related items. So, as a first step, just rename
it to ran_conn, to cosmetically prepare for moving the not strictly RAN related
items away later.
Also:
- Rename some functions from msc_subscr_conn_* to ran_conn_*
- Rename "Subscr_Conn" FSM instance name to "RAN_conn"
- Rename SUBSCR_CONN_* to RAN_CONN_*
Change-Id: Ic595f7a558d3553c067f77dc67543ab59659707a
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
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
Give the HLR a chance to send us updated subscriber data by indicating the CN
domain to be Circuit Switched, only during a LU Request GSUP message.
Adjust msc_vlr_tests to expect the added GSUP CN domain IE to indicate CS, i.e.
append '280102'.
Related: OS#3601
Change-Id: I0c2d33fbfdb4728e480679120d06b7f3a2ccfd76
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
In the msc_vlr_tests, instead of printing the algo IDs, rather print the
corresponding A5/n name, for clarity.
Change-Id: Ic00f1e54490650bcb40170647b8ffd52ede23fd3
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
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
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 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
Previously the '*#100#' USSD-request was abused in order to
conclude the current subscriber connection. This makes the unit
tests depend on each other, for example, if one break something
in the GSM 09.11 implementation, a half of tests would fail.
Moreover, the further changes in the GSM 09.11 implementation
will make the results less predictable (i.e. session ID, etc.).
So let's introduce a separate unit test with simple request-
response logic, while more complex tests will be in TTCN.
Change-Id: I40b4caac3113263f5a06c861dff5e10d43c319b5
Oliver Smith
Vadim Yanitskiy
Harald Welte
Philipp Maier