summaryrefslogtreecommitdiffstats
path: root/sccp
AgeCommit message (Collapse)AuthorFilesLines
2018-10-24Add Misc_Helpers.ttcn to centralize TTCN3 shutdown handlingDaniel Willmann1-1/+1
This function can now be called from anywhere to try and safely shutdown a testcase. It is not optimal as we can't call "all component.stop" from outside the mtc, but without any proper and orderly shutdown handling of all our emulation components I believe this is the best we can do. To use it: import from Misc_Helpers all; in your module and then call Misc_Helpers.f_shutdown(__BFILE__, __LINE__); You can also pass the function a verdict and a message and it will take care of calling setverdict, but beware of the following: While setverdict would accept any number of arguments as log message and convert them to a log string f_shutdown expects one charstring. It's possible to use the log2str function to use the log arguments in setverdict for f_shutdown, for example setverdict(fail, "Template didn't match: ", tmpl_foo); would become Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, log2str("Template didn't match: ", tmpl_foo)); Change-Id: I84d1aa6732f6b748d2bfdeac8f6309023717f267
2018-07-27detect VTY TELNET port connection failures (attempt #2)Stefan Sperling1-0/+1
Pass the CTRL_DETECT_CONNECTION_ESTABLISHMENT_RESULT parameter to the TELNET port by default. This allows tests to make progress into an error handling path if they are started while the osmo-* program they want to connect on VTY is not running. Observed with osmo-ggsn tests, where if the one test runs into a VTY connection failure the subsequent test would get stuck forever in a map() call on the VTY TELNET port. Teach the function f_vty_wait_for_prompt() about connection reports by the TELNET module. We may now receive an integer which represents the socket file descriptor for the telnet connection. This case was not handled by the previous change made in commit cb111b21aba1d5881da1a1d3f19754cbd15b3779. As a result, BSC tests started failing with "VTY Timeout for prompt" because the alt-statement in f_vty_wait_for_prompt() would not progress past the integer sitting on the VTY port's receive queue. Change-Id: I56925f93af6c55e93f3f417099db135744da6a40 Related: OS#3149
2018-07-27Revert "detect VTY TELNET port connection failures in TTCN3 tests"Neels Hofmeyr1-1/+0
With this patch, I see all ttcn3-bsc-tests failing with "Verdict: fail reason: VTY Timeout for prompt" This reverts commit cb111b21aba1d5881da1a1d3f19754cbd15b3779. Change-Id: I215d7ab5eee75cf6d3afaac760af64356c943140
2018-07-27detect VTY TELNET port connection failures in TTCN3 testsStefan Sperling1-0/+1
Pass the CTRL_DETECT_CONNECTION_ESTABLISHMENT_RESULT parameter to the TELNET port by default. This allows tests to make progress into an error handling path if they are started while the osmo-* program they want to connect on VTY is not running. Observed with osmo-ggsn tests, where if the one test runs into a VTY connection failure the subsequent test would get stuck forever in a map() call on the VTY TELNET port. Change-Id: I9acf7793d5d68aec6d087cff254a10d8b673dab1 Related: OS#3149
2018-07-24introduce a TTCN3 test suite for SCCPStefan Sperling5-0/+282
This test suite acts as an SCCP server on top of M3UA. SCCP tests are run against the sccp_demo_user program which can be found in libosmo-sccp/examples. This program must be started in client mode: sccp_demo_user -c The SCCP test suite should then work out of the box with the provided SCCP_Tests.cfg file and this additional change to sccp_demo_user default point codes: https://gerrit.osmocom.org/#/c/libosmo-sccp/+/9652/ There is currently only one test, for the libosmo-sccp crash reported as issue OS#2666. The implementation of this test is currently using an ugly workaround due to shortcomings of the M3UA Emulation layer (see source code comments). Whether a better solution is feasible is still to be determined. The test requires a patch to the SCCP Protocol Emulation which has been submitted upstream: https://git.eclipse.org/r/#/c/124552/ Change-Id: I03f5e8b282a7396b45417495c88d8fb81b26cda8 Related: OS#2666