As can be seen [1], it happens quite often that a test case gets
stuck and runs forever. Most of the existing test suites have
the guard timeout to prevent this. Let's make use of it here too.
[1] https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-remsim-test-latest/190/
Build has been executing for 1 day 23 hr!
Change-Id: I3897efd2a97c3e0d487057aa7bdc2967f3424dd8
There are some use cases in which we don't want a blocking wait for the
full HTTP request to complete. Let's split it up in two parts, and
make the existing f_http_transact() a wrapper around them.
Also, enable the generation of the Connect_result primitive to detect
connection failures.
Change-Id: I5c7575c0b58c3606d25d8f8cfccd47cfb7a8c400
There are other test suites (like osmo-cbc) which can reuse some of
the HTTP utility code that was developed within the remsim test suite
Change-Id: I87a728272d47649e4faa628fad44d6f8673c8169
More recent clients start to send ID RESP, which was not the case at the
time the TTCN3 test suite was written.
As we don't really want to test the IPA CCM behavior, but we want to
test the actual remsim functionality, we can simply ignore any such
responses.
Change-Id: Id557ea9c540bf96465e7f18da87719888dd7a318
osmo-remsim-client-shell allows to send C-APDU via STDIN of the program
and receive R-APDU via STDOUT. We can attach to that using the PIPEasp
TTCN3 port, and hence test a [local] osmo-remsim-client-shell
transceiving APDUs from/to a simulated bankd in the test case.
The only sad part about this is that we now will need to have the
implementation under test (osmo-remsim-client-shell binary) in the
same container as the TTCN-3 test, as it will fork/exec it.
This is why we disable it by default and a modulepar must be used to
enable those particular tests.
Change-Id: I3a69c692cf3e6bbe04ce58594050b20da0c37d16
VPCD (specifically ifd-vpcd) is an ifd-handler (reader driver)
for a virtual smart card reader integrated with pcsc-lite. It is
part of the virtualsmartcard project. Using this ifd-vpcd, we
can implementa virtual smart card reader beneath osmo-remsim-bankd,
which allows us to implement both the smart card [reader] below
osmo-remsim-bankd as well as the osmo-remsim-server + client above
osmo-remsim-bankd - in other words a fully virtualized test fixture for
bankd.
Change-Id: I967f2d526f4ef1278bd2ac1d590a8dce732379d5
This extends remsim-client test coverage to situations where the
server removes an existing/established mapping, and possibly later
establishes a new mapping.
Change-Id: I8df29a91718b6b2829415fc040b647a58eb71292
Related: OS#4399
This test verifies that a slotmap delete via REST will not only
delete it from the bankd, but also from the client.
Change-Id: I8c4e53231b5386b00fe2938cde2091aa8b2e2027
Related: OS#4399
If a slotmap is re-created with identical client+bankd, we expect
no change and the client-bankd connection to persist.
If a slotmap is overwritten with a create for a different client
than the currently connected one, we expect the client connection
to be closed.
Change-Id: If81e1511521fe478d2367104cd1c7eba254d6450
Related: OS#4278
Since osmo-remsim Change-Id I83e319d22896b881c0d882542842f500075aa546
createMapping will overwrite any existing mappings that may already
exist for that bank-slot. We need to adjust our test expectations
accordingly.
Change-Id: Ia8de9edd7edb0437cd783b7d045571ff69820c42
Related: OS#4278
In general we don't want that bankd retains state from one test
case to another. Let's issue the new RSPRO ResetStateReq at the
start of each relevant test
Change-Id: If810ccbbc848dd2448a4eaea20c80f60f15a2e84