detect VTY TELNET port connection failures (attempt #2)
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
diff --git a/library/Osmocom_VTY_Functions.ttcn b/library/Osmocom_VTY_Functions.ttcn
index 6e4eb74..427bd5c 100644
--- a/library/Osmocom_VTY_Functions.ttcn
+++ b/library/Osmocom_VTY_Functions.ttcn
@@ -46,6 +46,7 @@
/* wait for any of the permitted prompts; buffer + return all intermediate output */
function f_vty_wait_for_prompt(TELNETasp_PT pt) return charstring {
var charstring rx, buf := "";
+ var integer fd;
timer T := 2.0;
T.start;
@@ -57,6 +58,14 @@
testcase.stop(fail, "VTY: Unknown Command");
};
[] pt.receive(charstring:?) -> value rx { buf := buf & rx; repeat };
+ [] pt.receive(integer:?) -> value fd {
+ if (fd == -1) {
+ setverdict(fail, "VTY Telnet Connection Failure");
+ mtc.stop;
+ } else {
+ repeat; /* telnet connection succeeded */
+ }
+ }
[] T.timeout {
setverdict(fail, "VTY Timeout for prompt");
mtc.stop;