It makes the code much more readable if there's at least a one-liner
documenting each function (and struct member).
Change-Id: I6d239369cabdf1703eba7f3606b46b95cbbb1ea7
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
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
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: Iff66eea9ee70850a4d038ece1d8473457023e1ee
Fixes: OS#4865
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
"127.0.0.1" is changed to "localhost" to let local NSS decide whether to
use IPv4 or IPv6. In newish systems, IPv6 ::1 will be selected since
IPv6 takes precedence over IPv4.
Similarly, the default source addr needs to be changed from NULL to "localhost"
since for some yet unknwon reason, getaddrinfo(AF_UNSPEC, NULL) returns
first IPv4 "0.0.0.0" and later "::", which is inconsistent with
getaddrinfo("localhost") result, resulting in src=IPv4(0.0.0.0) and
dst=IPv6(::1), which is incompatible and will fail. In any case, since
the default remote address is a local one and it's the client side,
there's no real logical change since the kernel would anyway should have
taken a local address anyway.
Change-Id: I05a5c792ab1d053c6f38ba36d4b9fa6db293fbd0
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
For 'show subscriber cache', we print vsub->cgi. For 'show connection', it
makes more sense to print msc_a->via_cell.
This is tested by osmo-ttcn3-hacks Ie410714a96353f74a52a104c56fa0a08683e0004.
Related: OS#4627
Change-Id: I194271af2acb37b4f8cc2d106ab2fd2b0d443589
Add only a long option to not clutter the cmdline namespace.
To add a long option without a short letter is slightly complex: use the 'flag'
and 'val' mechanism as in 'man 3 getopt' to write an option index to
long_option.
Make sure that all VTY commands have been added before parsing cmdline options:
move various VTY init further above. For msc_vty_init(), the global msc_network
already needs to be allocated, so also move that.
Depends: Ic74bbdb6dc5ea05f03c791cc70184861e39cd492 (libosmocore)
Change-Id: I9146d5a44427509265420f52ae6540ad93eb14fc
When msc_ho_send_handover_request() generates the HANDOVER REQUEST
message, it does not populate the call_id struct member.
In ran_msg_a.c the struct member call_id is used, but the
call_id_present flag is not set, which also prevents the call_id being
added to the message
Change-Id: I6b1b55b3f5a3092d9557dc2512020c766a9ff744
Related: OS#4582
The BSSMAP message ASSIGNMENT REQUEST may contain an optional CALL
IDENTIFIER IE. While this IE is optional some BSC implementions may
require it.
Change-Id: I4288f47e4a6d61ec672f431723f6e72c7c6b0799
Related: OS#4582
This patch served for a manual testing counterpart for osmo-bsc to implement
MSC pooling.
This enables a basic MSC pooling setup, but for a production setup, osmo-msc
would still lack various features related to unloading subscribers to another
MSC as explained in 3GPP TS 23.236.
Change-Id: Iafe0878a0a2c8669080d757b34a398ea75fced36
when the VTY write the config file ist prints the configuration line
for emergency-call in network and in msc, however the presence of the
configuration line in network leads to a parsing error on msc startup.
The vty command probably got moved to node msc and it was forgotten
to remove the printing from network.
Change-Id: I4f3dac27723e7852f8f049fcfca5cccdc027734d
Related: OS#4548
The Mobile Identity type is received on the wire, we asserting on its type
constitutes a DoS vector.
Change-Id: I2b2e25ef8e878e91a165018ba49f1609cfb5cbd0
From ASAn on gcc 10.1.0:
+=================================================================
+==269368==ERROR: AddressSanitizer: odr-violation (0x559114a5b880):
+ [1] size=4 'asn1_xer_print' /git/osmo-msc/src/libmsc/ran_msg_iu.c:50:5
+ [2] size=4 'asn1_xer_print' /git/osmo-iuh/src/iu_client.c:85:5
+These globals were registered at these points:
+ [1]:
+ #0 0x7f6208d3869a in __asan_register_globals /build/gcc/src/gcc/libsanitizer/asan/asan_globals.cpp:341
+ #1 0x55911456d221 in _sub_I_00099_1 (/build/new/tmpdir/osmo-msc/tests/msc_vlr/msc_vlr_test_hlr_timeout+0x48d221)
+ #2 0x5591145e8e9c in __libc_csu_init (/build/new/tmpdir/osmo-msc/tests/msc_vlr/msc_vlr_test_hlr_timeout+0x508e9c)
+
+ [2]:
+ #0 0x7f6208d3869a in __asan_register_globals /build/gcc/src/gcc/libsanitizer/asan/asan_globals.cpp:341
+ #1 0x7f6207d8db91 in _sub_I_00099_1 (/build/new/out/lib/libosmo-ranap.so.3+0x47db91)
+ #2 0x7f62096eb0f1 in call_init.part.0 (/lib64/ld-linux-x86-64.so.2+0x110f1)
+
+==269368==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0
+SUMMARY: AddressSanitizer: odr-violation: global 'asn1_xer_print' at /git/osmo-msc/src/libmsc/ran_msg_iu.c:50:5
+==269368==ABORTING
Related: OS#4556
Change-Id: I702e9748eaaf2279c3764ba67f80f00ae9f2526f
New define is available since libosmocore 1.1.0, and we already require
1.3.0, so no need to update dependenices.
Let's change it to avoid people re-using old BSC_FD_* symbols when
copy-pasting somewhere else.
Change-Id: Ifc89fffac0443d94f3e49555684975b293ef90fb