Looking at 'perf top' of osmo-msc under load shows that there's a
significant amount of time spent in terms of locking (mutex,...)
which is useless as osmo-msc is a single-threaded application.
Unfortunately libdbi doesn't provide a mechanism to perform
sqlite3_config(), so we have to do it directly here, introducing an
explicit build-time dependency (and linkage) to libsqlite3.
Related: OS#5559
Change-Id: I5bbea90d28b6d73b64b9e5124ff59304b90a8a75
The existing rate counters per-minute/hour/day values were never
computed as the related timer was never started...
Change-Id: I27282051a6da5d1e1a25981712fbe4c4a6378dea
With comments, clarify the code paths where a CM Service use count has
not yet been placed on the conn (just send CM Service Reject) and where
the use count is placed (decrement count on CM Service Reject).
Place the CM Service use count slightly earlier:
- it is then correctly present when checking the mobile identity in
cm_serv_reuse_conn(), avoiding the crash reported in OS#5532.
- there is only one place incrementing the use count instead of two.
Related: OS#5532
Change-Id: I6c735b79b67108bcaadada3f01c7046e262f939b
This happens if for instance an HNBGW drops the RAB-AssignmentRequest
and does nothing with it.
call_leg.c:348:15: runtime error: member access within null pointer of type 'struct rtp_stream'
Related: OS#5401
Change-Id: I67d2d5b2dd3b367c34f929d63c056306ec001431
We need to set the codec as present in order for
msc_a_up_call_assignment_complete() to configure properly the CN-side of
he leg with the IUFP codec, which should be the desired default in order
to avoid transcoding.
Change-Id: Ib8086462239e2df748cf47ea7b37a07f1f3b85a8
RAB Assignment Complete contains no codec info, hence
assignment_complete.codec is not set and
assignment_complete.codec_present is false.
As a result a wrong value is passed to rtp_stream_set_codec.
This fixes osmo-msc sending "a=rtpmap:112 AMR/8000/1" during MDCX in the
RAT-side connection of the call leg after having properly sent
VND.3GPP.IUFP/16000 in CRCX.
Change-Id: Ic028d35893d29f7d72f22f82ef89695229c9b01b
This way the MGW knows it has to handle IuUP in that connection (answer
IuUP Initialization, etc.).
Depends: osmo-mgw.git 1de5ed6f979bd4c1380789c9a82f8e396f05c5f8
Change-Id: I7aca671e00ed27ac03f0d106b5a6b665a9bed4c1
Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I1b68e0aa26d81fbfe26abaa287d2bd5eec2cfd0f
On the protocol level, it's impossible to indicate UEA0 together
with the other algorithms. The encryption is either a) disabled,
so the Encryption Information IE is not present, or b) enabled,
so the Encryption Information IE indicates UEA1 and/or UEA2.
Because of that, the ranap_new_msg_sec_mod_cmd2() would fail to
generate the RANAP PDU if the given bitmask has the UEA0 bit set.
Fixes: 505a94a610 ("Make UTRAN encryption algorithms configurable")
Change-Id: I3271d27c09fc8d70a912bce998ceffbce64dd95e
Function msc_i_ran_enc() calls msc_role_ran_encode(), but unlike the
other callers of this function it does not free() the encoded message.
A simple solution would be to call msgb_free(), like it's done in
the other places. But a more elegant solution is to modify function
msc_role_ran_encode(), so that it attaches the msgb to OTC_SELECT.
This way there is no need to call msgb_free() here and there.
This change fixes a memleak observed while running ttcn3-msc-test.
Change-Id: I741e082badc32ba9a97c1495c894e1d22e122e3a
Related: OS#5340
Ciphering is optional in both GERAN and UTRAN, however for the later
it's *required* to enable integrity protection for the signalling.
Thus we must always send Security Mode Command in UTRAN, even in
case if ciphering is disabled (UEA0) in the configuration.
The actual decision whether to send CMC/SMC or not is taken in:
* vlr_access_req_fsm.c / _proc_arq_vlr_node2(), and
* vlr_lu_fsm.c / vlr_loc_upd_post_auth().
depending on the value returned by is_ciph_required(). Let's
rename this function to is_cmc_smc_required() and ensure that
it always returns true in UTRAN.
This change fixes the Iu test cases in ttcn3-msc-test.
Change-Id: I6205f13453eff7afbf25e013d72ae98a78fcd31b
Fixes: OS#5333
This function is never called when ciph_required is false, so
there is no need for an additional check in this function.
Change-Id: I900ddd5f1882f8cee234ab1074adcf25830a092c
If a MO SMS gets successfully routed through SMPP, we return early
in gsm340_rx_tpdu() and leak a chunk of type 'struct gsm_sms'.
Change-Id: I8a745d747f06baa7109418ffe600b27b3c0a5228
Fixes: [1] Ic34d398e0a850856e20380ae35e5c2ae5e3c539b
Fixes: OS#5334
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
If the remote ESME would send us 0xffffffff as length field, don't try
to allocte 4GB of memory, but bail out.
Change-Id: I561f75210811826de06ea1673eca1df24faaa210
Fixes: CID#240738
During a recent pcap trace, it was spotted that subscriber coming from
SGs had a use count with 16 "SGs" items, and later it incremented to 17.
Further investigation shows that the related use_count item was never
decreased, meaning every time an SGs-LU was sent by the MME, the item
was incremented further and never decremented.
Let's rename the item to be referenced while in LU, and then decremented
when LU is done. At that time, either the LU was accepted and the
subscriber object has a use_count item "attached", or it was rejected
and we already sent the reject messages, so we are fine deleting it if
needed.
Related: SYS#5337
Change-Id: I22c386f02ffa57428f700b003cc2cf23133598d0
it was recently observed in a pcap trace with gsmtap_log that the
use_count contained a "vlr_sgs_imsi_detach" item despite no related
message was seen near by. Further investigation shows that there's an
unbalanced get+put code path, introduced by an early return added to fix
another issue.
related: SYS#5337
Fixes: 0803d88d9a
Change-Id: I91ae956e50fca2f4d0e1d145d60ccb0ebfb409e9
Will be used by I6fa37d6ca9fcb1637742b40e37b68d67664c9b60
"implement CM Re-Establish for voice calls"
Related: SYS#5130
Change-Id: I5291d098a02268bd1c2e30195ae61e4a13e8709c
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
Alexander Couzens
