This will prevent subsequent failures from overwriting the verdict so we
can easily see the root cause of the test failure.
Using testcase.stop instead for errors internal to our test
infrastructure to mark them as test errors instead of failed.
Change-Id: Idc6819aaf0b01e70c38fad828dd44dcec6bdd778
procedure ports (like message ports) require us to specify the
destination of a message ("reply") in case it is connected 1:N and not
just 1:1. This didn't show up as a problem so far, as we typically only
had one component talking to those procedure ports at any given point
in time.
Change-Id: I696ec67080815348bb95e43ecbbf262e533e39a3
We don't have a good way to make the BSSMAP code wait for the lower
SIGTRAN layers to be up and running. To avoid the RESET being
sent before the lower layers are up, introduce a sleep of 1s.
This is ugly, but appears to work for now. A more proper solution
is more than welcome.
Change-Id: I7a43b3e381405f3af30b3ffe04bc50e64ec66f57
The existing code generating L3 sequence numbers in MO direction
made the assumption that the L3 message inside ComplL3 would always
be MM/CM, and increment the sequence number.
However, in case of a paging response, it is actually RR, which
does *not* have L3 sequence counters. So we must make the sequence
counter increment dependant on the L3 protocol discriminator.
Change-Id: I25a5dd0c180c9acfa870984c6b122ac0c46383b3
This seems not to be required on TITAN 6.3.0 on my laptop, but the
older 6.1.0 on Debian 9 seems to need it.
Change-Id: I574d8b79ac43e0fceddb3f9815666aef0ed66a3f
If we're emulating BSC/BTS/MS, then we must be able to dispatch
incoming paging requests based on their IMSI or TMSI to the right
ConnHdlr component. This introduces a new table to facilitate that
dispatch.
Change-Id: I85c1ea3bcf8fb4a100f20cffdc991826b58e290b
If the ConnHdlr initiates an outbound connection, it needs to know
once that connection is established if it wants to send further
data. Transform the N-CONNECT.confirm into a MSC_CONN_PRIM_CONF_IND
and send it to the ConnHdlr.
Make use of it from the MSC_Tests when issuing a Complete L3 Info.
Change-Id: I7293a9f4993d13c90316224eb9f13e10130388ef
It's quite cumbersome if the user of the BSSMAP_Emulation (the ConnHdlr)
will have to manually decode the DTAP in every BSSAP/DTAP message he
receives (and encode on the transmit side). Let's introduce a new
optional mode in which the DTAP messages are already decoded for
more convenient matching inside the ConnHdlr.
Change-Id: I35cd4ea78aca0ce7c7d745e082d7289882c11e81
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
So far, BSSMAP_Emulation used the SCCPasp_SP_PORT directly, explicitly
calling BSSAP encode/decode functions while processing the primitives.
Let's clean this up and use the BSSAP_CodecPort which has meanwhile
been developed as a dual-faced port that can be stacked between SCCPasp
and the user to avoid any manual encode/decode function calls.
Change-Id: Icded789d18f3469f74e16f552df2c7ac44ac4294
Daniel Willmann
Harald Welte