Additional libraries to be linked should be in LINUX_LIBS (appended at
the end of the linker command), not part of LDFLAGS (prepended to
the beginning of the linker command).
On binutils 2.35.1 / Debian unstable, without this patch, I get
/usr/bin/ld: IPL4asp_PT.so: undefined reference to `sctp_bindx'
/usr/bin/ld: IPL4asp_PT.so: undefined reference to `sctp_connectx'
which is resolved by this patch
Change-Id: I8a339076f445e3c650e407ae982c7c2dc4a760b2
It tests IPv6 Transport Address are passed correctly through BSSAP, and
forwards handles them correctly as an MGCP client too.
Change-Id: Id616926dd4a9febc4268eea2ee1e377b2d22753a
These uncover crashes of current osmo-msc master, when a Paging Response
contains an unknown mobile identity. Hence run them last.
The crash is fixed by osmo-msc Ia2c8fa745cfab17ed7114d433f625ddc02ae7b11
Related: OS#4724
Related: Ia2c8fa745cfab17ed7114d433f625ddc02ae7b11 (osmo-msc)
Change-Id: I40496bbccbbd9c496cfa57df49e26f124a2b1554
We already have TC_cmserv_imsi_unknown, but lack a test that shows CM Service
Request behavior for an unknown TMSI.
Looking at OS#4721 I vaguely expected an ID Request to also happen during CM
Service Request, but instead we reject the unknown TMSI completely, and require
the MS to perform a proper LU subsequently.
Related: OS#4721
Change-Id: I54e5efcf4c31625205c99338379a2055633acde9
The test currently fails with osmo-msc master. It uncovers the evil twin aspect
of osmo-msc's VLR, for an attached IMSI re-attaching with an unknown TMSI.
Related: OS#4721
Change-Id: Ia53733fc5bc414b0e3d3897f25b549f5183c862d
There is a race condition when shutting down, as a DLCX might arrive
while we are half-shutdown. Expect both DLCX before terminating
the ConnHdlr.
Change-Id: Ia0342a9bb346929e0e538f4cb571abfc4acac6bf
As of osmo-msc Change-Id I2552736477663adb250c55728093500e8ae83ebb,
osmo-msc is always sending BSSMAP CommonID to the BSC. Let's adjust our
test expectation, while allowing the user to start the tests with
BSC_ConnectionHandler.mp_expect_common_id := false
to get the existing behavior (expect no bSSMAP CommonId) can be
restored, e.g. for testing 'latest'.
Change-Id: I4976d9bb1f07c8ab4ffa02848414f8ddd1bdfd3f
Related: OS#2969
The existing code passed -1 as TCP port number to the SMPP client.
This - very unintuitively - causes TITAN to always chose port number
9999, as that's the default value in IPL4asp. Let's use '0' instead.
Change-Id: I4db38f4099c388bed23f9a3611619866ede9cbc5
osmo-msc failed to record the Complete Layer 3 Information LAC and CI in the
MSC-A as well as the VLR record. Since osmo-msc
Iee1781985fb25b21ce27526c6a3768bf70d4dc9a and
I194271af2acb37b4f8cc2d106ab2fd2b0d443589, osmo-msc properly records these for
successful Complete Layer 3 procedures.
Incorporate verification of the LAC and CI in all tests calling f_perform_lu()
and f_expect_clear(). Implement by scraping the output of vty
'show subscriber imsi 1234 conn'
Some tests model a failure to attach, or expire the VLR record: for those, add
parameter verify_cell_id to g_pars, and pass it as false, to skip checking the
LAC and CI.
Disable CI checking for all Iu tests globally in f_verify_vty_lac_ci(), see
OS#4634.
For the latest build, which does not yet record LAC and CI properly, provide
mp_enable_cell_id_test, which skips all cell id verification if set to false.
Put to effect by docker-playground I052fea208021509e12826c50474b96474e7a58c2.
Related: OS#4627
Depends: Iee1781985fb25b21ce27526c6a3768bf70d4dc9a (osmo-msc)
Change-Id: Ie410714a96353f74a52a104c56fa0a08683e0004
Start a second
- MT SMS
- MT call
while a Paging is already ongoing.
The second trans being an SMS works.
The second trans being a call fails with current osmo-msc master; a fix is in
the related patch (s.b.).
Related: Idd4537b5f4817d17e5c87d9a93775a32aee0e7be
Change-Id: Ieeae6322d4e80893ea3408c6b74bf8e32bea8e46
RLCMAC blocks have a lot of fields and we will potentially require lots
of different templates, as well as functions to handle related structs.
Change-Id: I9c6597178168aa3848b21930f33be698dd2ce545
Test sending MS RA capabilities through Packet Resource Request to
update GPRS multislot class.
EGPRS multislot will come in a later commit.
Change-Id: I5026d8b78a3fb82093956b65989d18fa6f6d5424
All the records related to Mobile Identity IE (see 3GPP TS 24.008,
section 10.5.1.4) are defined in [1], so there is no real need to
dumplicate them. Moreover, most of the related templates in
library/L3_Templates.ttcn are based on these records.
[1] titan.ProtocolModules.MobileL3_v13.4.0/src/MobileL3_CommonIE_Types.ttcn
Change-Id: I27c2743c59db770d6f7e9447dc8c1f539b228ced
Long story short: some time ago I noticed that OsmoMSC crashes if
T3212 expires during the Paging procedure. This is not the case
anymore (as the test case shows) and apparently the bug has been
fixed, hovewer I believe it makes sense to add this test case.
Change-Id: If9147ae8b07d5120d2853b9acda2313910ac48be
This test case reproduces the problem described in OS#4351:
1. MS/UE submits a MO SMS which it getting touted to an ESME;
2. MSC prematurely responds with RP-ACK to the MS/UE;
3. ESME responds with DELIVER-SM error;
4. SMS transaction is already terminated (by RP-ACK).
Expected behaviour:
1. MS/UE submits a MO SMS which it getting touted to an ESME;
2. ESME responds with DELIVER-SM error;
3. MSC terminates the SMS transaction with RP-ERROR.
Change-Id: I33c6ea0ffdf8b8a45f587d690bdceb38fc42c898
Related: OS#4351
Since Ibca0e9196c25ab00803041b81f7b490ba2f0a3ba we can have up to
16 components of type BSC_ConnHdlr running in parallel. Both
TC_multi_lu_and_{mo,mt}_ussd test cases have been updated,
but their Iu/UMTS siblings have not. Let's fix this.
Change-Id: Iaa7347e973ee617cc1780b84e0c298f0a302227c
Both test cases make use of the existing functions:
- TC_multi_lu_and_mo_ussd: f_tc_lu_and_mo_ussd_single_request(),
- TC_multi_lu_and_mt_ussd: f_tc_lu_and_mt_ussd_notification(),
starting several (*) BSC_ConnHdlr components in parallel.
(*) The maximum amount is limited by 16 - this is as much
as both GSUP and SCTP emulation components can handle.
Change-Id: I2fb1c5d285163d5245d92fa24c197a5027ecbe6f
Related: OS#2931
Since [1] we started to match the SMSC Address in f_mt_sms_expect().
That change caused test case failures because OsmoMSC hard-codes
a different SMSC Address. Let's fix this.
[1] Ib467eeca6439bc6cce72293fbb5bb48f6d233db9
Change-Id: I3bdb6a74c8b02e4bf8dc88634e2380c924242b4b
While investigating OS#4340, it was discovered that a malformed
MM Identity Request with MI Type '111'B crashes OsmoMSC.
Unfortunately, I could not find a way to encode such an invalid
message in TITAN (because value '111'B is reserved), so I
figured out that '000'B also crashes OsmoMSC.
MM Identity Request is triggered by initiating an Update Location
Request with reserved TMSI value 'FFFFFFFF'O (unknown to the MSC).
Change-Id: I62f23355eb91df2edf9dc837c928cb86b530b743
Related: OS#4340
Unlike IMSI, both MSISDN and SMSC address in SM-RP-OA/DA not only
contain the BCD encoded digits, but also a little header with
NPI (Numbering Plan Identification), ToN (Type of Number), and
Extension fields.
Change-Id: I3f55834489f3e613f541cf1e216027e8d48ccaf0
Related: OS#4324
When sending MO or MT SMS, we never include both SM-RP-DA/OA IEs
at the same time. In case of MO SMS, SM-RP-OA is omitted, and in
case of MT SMS - SM-RP-DA is omitted.
Change-Id: Ia60bdd2498034b6b849f874cf1eee272abef2b47
After discussion on this thread:
http://lists.osmocom.org/pipermail/openbsc/2019-November/013058.html
Do not expect repeated Paging on GERAN.
Pending clarification on 3G, still expect repeated Paging on Iu, though we are
not 100% certain that this is indeed required.
Fixes MSC_Tests.TC_lu_and_mt_sms_paging_repeated,
but not MSC_Tests_Iu.TC_iu_lu_and_mt_sms_paging_repeated
Change-Id: Ie914ea88f31ac158f4bd1700143bbe728dd05e0b
Fix these tests by using f_mm_common(), which takes care of Iu auth+ciph:
TC_iu_lu_imsi_reject
TC_iu_lu_imsi_timeout_gsup
Change-Id: Id2bf160ac4e1cad4770202c6a6f1b8eeeee21d68
Make sure that osmo-msc doesn't crash if a successful CRCX response contains an
invalid IP address.
Originally/recently, osmo-msc did not validate the IP addresses at all. In an
intermediate patch I added error handling, releasing the call. That uncovered a
use-after-free problem in libosmo-mgcp-client. This problem is fixed by
osmo_fsm_set_dealloc_ctx() and an osmo-mgw fix (see
I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 in osmo-mgw).
Add this test to make sure the crash is not re-introduced.
Change-Id: I0c76b0a7a33a96a39a242ecd387ba3769161cf7a
Harald Welte
Neels Hofmeyr
Pau Espin
Vadim Yanitskiy