Miscellaneous Projects » Core testing infrastructure

laforge wrote in #note-1:

[...] I think we should immediately create a jenkins setup (maybe osmith can take that part? feel free to coordinate) so we catch if that should break for some reason.

Sure. Dexter, feel free to assign the issue to me once it's ready for that.

As a preparation I am currently working on getting the already existing MME tests to run in docker. Building and test execution already works, but the network connection between testsuite and MME does not work yet.

The MME tests now run in docker. The test results are the same as when I execute the tests locally. A patch is up for review in gerrit:
https://gerrit.osmocom.org/c/docker-playground/+/33571 MME_Tests: add docker tests for MME

The patches for docker-playground now made it into master, so now we can configure a jenkins job that executes the MME tests.

On Mon, Jul 17, 2023 at 09:02:00AM +0000, dexter wrote:

The problem here is that the Global ENB ID is ASN.1 (presumably APER) encoded. I already tried to make an encoder but I am stuck at fftranscode, which presumbably lacks the encoder/decoder for the Global ENB ID. In any case, this is probably a minor problem.

The entire S1AP is ASN.1 APER, and we use libfftranscode to transcode it. The Global ENB ID is supposedly one information element that's usually somewhere deep inside the information elements of a S1AP message, right? So it does have the encoder/decoder.

However, given the thousands of data types, we really only expose symbols/functions to transcode complete PDUs of the respective protocol, and not individual members/types, sorry.

It is understandable that we can not expose random information elements in libfftranscode. However, I think I can work around the problem. I could just encode a random PDU and find the offset where the Global-ENB-ID IE begins. Then I could chop off everything I do not need. If that does not work I still can use a hardcoded Global-ENB-ID, this would not look very nice, but it would work for sure.

I also had a lot of trouble with the accessibility of unit-data from indie the ConnHdlr but I managed to find a solution, the following patch is currently in review:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33898 S1AP_Emulation: improve accessibility of unit-data

There are also a couple of other fixes that were required:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33893 GTP-Templates: fix incorrect comment
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33894 GTP_Templates: Add RIM_RoutingAddress to RANInfoRelay templates
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33896 GTP_Templates: add template tr_GTPC_RAN_Information_Request
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33897 S1AP_Templates: Add templates for MMEDirectInformationTransfer
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/33898 S1AP_Emulation: improve accessibility of unit-data

I now have a round-trip RAN information request running, it still requires a bit of cleanup and verification of the contents of the last S1AP message (RAN Information) from the MME.

The testcase TC_RIM_RAN_INF is merged into master. We also reached a point now where all testcases show up green:
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-mme-test-ogs/test_results_analyzer/

The following changes were made to add a testcase for the Tracking Area Update:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34267 NAS_Templates: fix ts_NAS_GUTI
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34268 NAS_Templates: add templates for EPS_Mobile_ID_IMSI/IMEI/GUTI
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34269 NAS_Templates: add template for EPS update type
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34270 NAS_Templates: add template for NAS key set identifier
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34271 NAS_Templates: add template for Tracking Area Update Request
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34280 NAS_Templates: add template for Tracking Area Update Reject
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34281 MME_Tests: add new testcase TC_s1ap_tau_unknown_guti

We are now able to send a TAU to the MME, but the MME reject this TAU. The reason for this is that it does not know the TMSI in the OldGUTI field yet. Unfortunately there is no way to tell the MME an IMSI or alike that it knows. TAU is entirely relying on a valid TMSI. A valid TMSI is returned by the MME during the NAS Attach request. Unfortunately the testcase of the NAS Attach Request (TC_s1ap_attach) is not testing the procedure beyond the Create Session Request (towards the SGW-C). It is up to the testsuite to emulate the SGW-C. This means we will have to add an S11/GTPv2 interface to the testsuite. This has been done in the following patches:

https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34266 MME_Tests: Add S11/GTPv2 interface
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34286 GTPv2_Emulation: improve accessibility of unit-data (TEID0)
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34287 TC_s1ap_attach: setup S11 interface, catch Create Session Request [NEW]

The last patch [NEW] is still in gerrit. All it does is extending TC_s1ap_attach so that it catches the Create Session Reqest. This is mainly to verify that we are able to receive S11 messages from the MME.