OsmoBSC has some misunderstanding about how IPA CCM works and hence
we need to work around this until that bug is fixed in OsmoBSC.
See https://osmocom.org/issues/2718
Change-Id: I304535d28a165f76a0a140dc0a15dd81a9db28c8
Related: OS#2718
By default all the elements in the conn table seem to be considered
<unbound>.
f_cid_create() manages to set ra, ra_fn and comp_ref in the
ConnectionData element, but checking for
ispresent(ConnectionTable[i].ra) still returns false while
log(ConnectionTable[i].ra) returns 23. Setting every optional element to
omit as f_cid_clear() does before using the connection table seems to
solve this issue.
The assignment_fr_* tests now continue after receiving the Immediate
Assignment, but still fail after receiving the CM Service Request.
Change-Id: I24205425c5b6ae5b8a0f6288ba89ea5a1dc4669d
This will make sure that all log files will contain information about
the .ttcn source file name and line number that has caused the log,
which is extremely useful during debugging.
Change-Id: Id6785757f20279ba84b34747f878baf67d065b20
This new test exercises the new 'msc.0.connection_status' control
command which is added in https://gerrit.osmocom.org/#/c/5630/
Change-Id: I55faa1ec413629234e24831dbc05d8b0afec8099
Related: OS#2729
The paging tests expect BTS 0 and 1 in LAC 1, and BTS 2 in LAC 2.
BUt the osmo-bsc configuration file had BTS 1 in LAC 2, and BTS 2 in LAC 1.
Change-Id: I1d6b02fe06116dee59977422bc93bcafcd3aba76
Ever since I46de7fb9c324654275a27aa5f8c1be70340e3229 we had problems
linking the object files together due to a missing object
Change-Id: I5d8c37f924b3a2c8b28cace4da2add1fadd0151a
Sometimes it's not entirely clear which error code should be returned,
so let's accept multiple options, depending on the situation
Change-Id: I6d6eaec4d025b9da170f59c759884afe2e768521
We used to have a big (OS#2784) where only endpoint numbers below
10 (0x0A) were working due to failed interpretation in hex/dec.
Let's use up to 30 endpoints to ensure hex as well as two-digit
digit numbers.
Change-Id: Ifb3e01b5d31decefbf0c87ea39ec5021c8795579
Don't expect the ASSIGNMENT to fail in case of unsupported A5/4,
but expect a CIPHERING MODE REJECT.
Change-Id: I15024f61e67795b7e5ce72e1b641db6ca92ff76d
For some weird reason the link_id is *not* the second IE in
RSL_MT_ENCR_CMD, while it is in all other RSL RLL or DCHAN messages.
Change-Id: Iea93aa8dba74d25c74a257d011ba43308ee375e4
The as_reset_ack() exists to acknowledge any incoming RESET without
every test case having to deal with it explicitly. However, of course,
the processing of an inbound RESET should not abort but the alt clause
shall continue.
Change-Id: I94dc72b5788ccc8dff2c4b80599c9fbf7e90e730
In all RSL messages the link identifier is usually the second IE.
However, as the only known exception, the RSL Encryption Command has it
as third IE.
Fixes the following error message:
Dynamic test case error: Using non-selected field link_id in a value of
union type @RSL_Types.RSL_IE_Body
Change-Id: I2bbb83b5394d0b693a47d286beed5c699ab6e8ae
Let's verify the operation of the CIPHERING MODE COMMAND as issued
by MSC, performed by BSC and implemented by simulated BTS/MS.
Change-Id: Ibc06bd2177c63837a794a0ca1f54ebef17499e78
This way we benefit from the ability to handle the RR MODE MODIFY,
RSL MODE MODIFY, IPA CRCX and IPA MDCX capabilities of the MSC_ConnHdlr
component. While each test case now needs a separate function in
addition to the actual testcase, this allows for more flexibility
and a more complete emulation of BTS behaviour.
Change-Id: Iba50663cb5104bf34bd6fc8aac2aa3b47155fe99
Using the MSC_ConnHdlr component, we can now handle the BSSAP (MSC)
and RSL (BTS) side of a single radio channel.
Change-Id: I00dcf1e4eaa7f133788cc01fbbcd4148a0258ef4
They all are related to a dedicated channel and carry a channel number
as first information element.
Change-Id: Ic3fdc029a96c34a9d2d9ec669b789526c8325637
The existing tests were implemented directly on top of the BSSMAP
and RSL CodecPorts. If we loop in the RSL_Emulation and
BSSMAP_Emulation components, we can properly multiplex/demultiplex
multiple MS (radio channels) on both the RSL and the MSC (SCCP
connection) side.
In order to have a single component that handles both the RSL and the
BSSAP side of a given channel/subscriber/call, we introduce the concept
of BSSMAP "Expects", where the test csse can register the L3 INFO that
it sends in the RLL ESTablish INDication on the RSL side, so the BSSMAP
handler cna route the BSC-originated SCCP connection with that L3 INFO
back to the same component. This is a bit inspired "in spirit" of the
"expect" mechanism of netfilter connection tracking.
Change-Id: I71f777cd4f290422fa68897952b6505875e35f0e
Daniel Willmann
Harald Welte
Stefan Sperling