RANAP Security Command can include an encryption IE. If it includes
it the RNC can still ignore it (e.g. unsupported encryption) and
return the Security Command Complete with an choosen encryption IE:
"no encryption".
Validate the encryption element and ensure the encryption is included in
the encryption mask.
Closes: OS#4144
Change-Id: Icfc135c8b8ae862defe7114db492af600c26407f
Allow the user fine-grained control over which UMTS encryption
algorithms are permitted, rather than always permitting UEA1 and UEA2
or neither.
This brings the handling of UEA in line with the handling of A5 for
GERAN.
Change-Id: I91f9e50f9c1439aa19528f887b83ae9de628fcfd
Closes: OS#4144
Depends: osmo-iuh.git I6d2d033b0427bdc84fee61e0f3cb7b29935214bf
The existing code allowed the user to configure UMTS encryption in the
vty, but we never actually passed this information down to RANAP. As a
result, the RAN had no chance of ever enabling encryption on the air
interface.
Change-Id: Ieaaa6b23b7337b7edb902fad8031e195e0c5e9d2
Related: OS#4144
Using *unpacked* 'struct osmo_gcr_parsed' in the MNCC PDUs makes
the protocol even more complicated than it currently is, and
moreover complicates implementing MNCCv8 in the ttcn3-sip-test.
Replace 'struct osmo_gcr_parsed' in 'struct gsm_mncc' with a
fixed-length buffer, which is supposed to hold the Global Call
Reference encoded as per 3GPP TS 29.205.
Indicate presence of GCR using the MNCC_F_GCR flag.
Change-Id: I259b6d7e4cbe26159b9b496356fc7c1c27d54521
Fixes: I705c860e51637b4537cad65a330ecbaaca96dd5b
Related: OS#5164, OS#5282
This commit is largely based on work by
Max <msuraev@sysmocom.de>
Adds LCLS parameters for A-interface transactions
This commit also adds a vty option to facilitate globally
disabling LCLS for all calls on this MSC.
Add a global call reference (GCR) to MNCC and therefore
bump the MNCC version to version 8. (This commit has to be
merged at the same time as the corresponing commit in the
osmo-sip-connector for mncc-external use.)
Depends: osmo-sip-connector Id40d7e0fed9356f801b3627c118150055e7232b1
Change-Id: I705c860e51637b4537cad65a330ecbaaca96dd5b
As seen in a running osmo-msc:
"vlr_access_req_fsm.c:153
msc_a(IMSI-....:MSISDN-...:TMSI-0x...:GERAN-A-8:CM_SERVICE_REQ){MSC_A_ST_RELEASING}:
Event MSC_A_EV_CN_CLOSE not permitted"
Also seen in several unit tests, which need update.
The action event handler for that state is actually already
expecting/handling the event by ignoring it, so we should allow it.
Change-Id: I4d30cffab693529aab3ba736419dec116a4dd7ef
Forward the Kc128 key to the new BSS in BSSMAP Handover Request.
Depends: Ieb6e43eef9e57281d54d4b7c63664668df5aef3e (libosmocore)
Change-Id: Id5ce995a741c8e469a50a0c46e53c06a2378bb7e
Add A5/4 to the internal mask of allowed algorithms.
(Not actually working yet, A5/4 implementation follows in other
patches.)
Related: SYS#5324
Change-Id: I5b46aaa8579f8d069ca39caf996a8795ffe63dd7
Use new API in Cipher Mode Command to prepare for A5/4 support.
Depends: Ib3906085e0c6e5a496a9f755f0f786238a86ca34 (libosmocore)
Related: SYS#5324
Change-Id: Ib238d367b8d5d07b6ab4cb2e48fbf4ce22ca4476
Since recently, osmo-bsc behaves strictly as per specs, meaning it will
only send the "Cell selection indicator after release of all TCH and SDCCH IE"
in RR Channel Release iff:
* "Last Used E-UTRAN PLMN Id" was received in the CommonID sent MSC->BSC
* "Last Used E-UTRAN PLMN Id" was received insider "old BSS to new BSS Information"
in the HandoverRequest sent MSC->BSC.
On the other hand, CSFB_Indicator from ClearCommand MSC->BSC is nw
ignored and not taken into account.
Hence, let's update osmo-msc to also behave correctly by sending the
Last Used E-UTRAN PLMN ID at CommonID tx time to avoid regressions in
CSFB support when running against newer osmo-bsc.
Let's keep sending the CSFB Indicator in ClearCommand as we used too, in
order to keep compatibility with older BSCs (as per spec).
Related: SYS#5337
Change-Id: Ic5f175b179973d0a50d94f00e15f5a3e332605fc
Calling gsm48_cc_tx_release() before mncc_release_ind() has a side
effect: the former may change CC state to GSM_CSTATE_RELEASE_REQ.
This makes the later send MNCC_REL_CNF instead of MNCC_REL_IND, so
if one of the call leg disconnects due to RF failure, the other one
will not be terminated correctly.
Makes both TC_{mo,mt}_call_clear_request TTCN-3 test cases pass.
Change-Id: I3ad4a99757878de3796027325627c87d9a4e93f1
Related: Id16969fe0de04445d1320a96d35cf1d48cc8cf09
Related: SYS#5340
The function gsm48_rx_cm_reest_req() is the only one where the return
code of osmo_mobile_identity_decode_from_l3() is not checked, lets check
it here too.
Change-Id: I37981205870b094b3a40a20197461208daa62698
Fixes: CID#211037
We may never be able to deliver this SMS if it depends on the ESME, as we will
not resubmit the SMS to the ESME. Better to reject it at this time and have the MS
try again later.
Change-Id: I2c50904349dd4ed229b60b8468d776b817c0bd44
Related: OS#4740
The struct gsm_mncc which is created and populated in mncc_call_tx_setup_ind
casted to a union mncc_msg* pointer. This leads to a memory overrun
in mncc_call_tx because the union mncc_msg is larger then the gsm_mncc struct.
To fix this, lets just declare a union mncc_msg and populate the signal
member inside it. This can be handed over to mncc_call_tx. The data in
it will look the same, except that the memory will have the proper
lenght (longer).
Change-Id: Ifff28b3375d6bd5e4f837f25c46736952f7bfa9b
Fixes: CID 214330
Timer X1 is not defined in libosmo-mgcp-client, so this tdef had no effect.
Change this to X2427.
(libosmo-mgcp-client recently moved T2427001 to X2427.)
(X2 is still used in call_leg.c itself)
Related: OS#4539
Related: If097f52701fd81f29bcca1d252f4fb4fca8a04f7 (osmo-mgw)
Change-Id: I9804fdb2c24f49910f2386e3788bd1107b8ebc40
So far, the cmdline argument was the only way to set a database file.
Add a similar config to VTY as 'msc' / 'sms-database'. The cmdline arg is stronger
than the 'database' cfg item. DB is not reloaded from VTY command.
Change-Id: I18d954c30fcceb0b36a620b927fd3a93dcc79f49
We're already sending the RANAP CommonID message to the RNC,
let's do the same using BSSMAP CommonId towards the BSC. This
way the BSC knows about the IMSI of the served subscriber, which
is very useful for logging/debugging.
Change-Id: I2552736477663adb250c55728093500e8ae83ebb
Closes: OS#2969
Depends: libosmocore.git I353adc1aa72377f7d4b3336d2ff47791fb73d62c
Otherwise, each time the 3GPP TS 44.014 MS test commands (TCH loop)
are invoked, both subscriber_mstest_{close,open} functions add +1
to the subscriber's reference count, but never revoke it.
Change-Id: I0cefa5b5a0cb712080ba2afd322db329f19608e3
This byte is redundant, and must not be allocated in this function.
A consequence of this error is that the MS alwats interprets the
"Sub-channel" IE as test loop A regardless of the specified type.
Here is an example of malformed Close TCH loop (type C) message:
0f 00 00 04
x. .. .. .. - Skip indicator (see 3GPP TS 24.007)
.x .. .. .. - Protocol discriminator (see 3GPP TS 24.007)
.. xx .. .. - Message type (CLOSE_TCH_LOOP_CMD)
.. .. !! .. - (!) Redundant byte from create_gsm0414_msg()
.. .. .. xx - (!) The actual "Sub-channel" IE (loop C, X=0)
Change-Id: Ia47225b884439dcd43be307e7351994e55fcd50d
So far, by failing to initialize the cause value, we always send a Clear
Command cause == 0, which actually means "Radio Interface Message Failure".
This is seen in all my logged network traces of osmo-msc lab testing.
"Call Control" seems to be the only cause value that remotely fits a normal
release procedure, even if it was not voice call related, see 3GPP TS 48.008
3.2.1.21.
Related: OS#4664
Change-Id: I1347ed72ae7d7ea73a557b866e764819c5ef8c42
new_id_ptr should be passed as NULL if encoding the TMSI failed, so initialize
it accordingly.
Also add some bloat to better handle the case of an encoding error, even though
from code analysis that should not be possible here: there is enough buffer,
the MI is a TMSI encoded from a uint32_t...
The problem was introduced by Idfc8e576e10756aeaacf5569f6178068313eb7ea, before
which new_id_len was always 0 when no TMSI was present.
Related: CID#210894
Change-Id: I800c5dca3fdbdedf70a64d9fd5a1bdfd1397f431
ran_peer.c is not the proper place to parse messages, because it should be RAN
agnostic. All parsing and encoding belongs in ran_msg_a.c and ran_msg_iu.c.
Move the Osmux TLV parsing into the is_reset_msg op: add supports_osmux
out-parameter (and add a logging fi pointer). To be able to modify msg->l3h,
also make the msgb arg non-const.
In ranap_is_reset_msg(), always return non-support for Osmux.
In bssmap_is_reset_msg(), return 0 if no TLVs were parsed, 1/-1 if an Osmux TLV
was present/not present.
Update the osmux support flag directly where the ConnectionLess message is
received, so that there is only one place responsible for that.
Related: OS#4595
Change-Id: I1ad4a3f9356216dd4bf8c48fba29fd23438810a7
As soon as the subscriber is authenticated, update the VLR entry with the
MSC-A's full CGI, including the Cell Id received from the Complete Layer 3
Information.
Thus the Cell Id will be shown by vty 'show subscriber cache' and 'show
connection'.
This is tested by osmo-ttcn3-hacks Ie410714a96353f74a52a104c56fa0a08683e0004.
Related: OS#4627
Change-Id: Iee1781985fb25b21ce27526c6a3768bf70d4dc9a