pespin submitted this change.
sgsn: Fail in obvious way when unexpected ServiceAccept is received
since osmo-ttcn3-hacks.git 2ff5b2633a43cecaed75b30b85537d6de3a52c97, the
code doesn't expect to receive a ServiceAccept after SecurityCommand,
ie. osmo-sgsn is wrong. As a result, tests such as
TC_attach_pdp_act_user end up failing with a tGuard timeout waiting for
a RAB ASs Req. The result is confusing since osmo-sgsn actually sends
the RAB Ass Req, but since the unexpected ServiceAccept is first in the
queue, the ttcn3 code doesn't process the RAB Ass Req.
Make the test explicitly fail if something else from RAB Ass Req is in
the queue preventing reading from it.
Change-Id: Ifbb7da1d02c8bde3406a9dd445c03ed140b8c0a3
---
M sgsn/BSSGP_ConnHdlr.ttcn
1 file changed, 9 insertions(+), 0 deletions(-)
diff --git a/sgsn/BSSGP_ConnHdlr.ttcn b/sgsn/BSSGP_ConnHdlr.ttcn
index eac01d5..696aa83 100644
--- a/sgsn/BSSGP_ConnHdlr.ttcn
+++ b/sgsn/BSSGP_ConnHdlr.ttcn
@@ -1053,6 +1053,7 @@
function f_pdp_ctx_act(inout PdpActPars apars, boolean send_recovery := false, integer ran_index := 0, float Tval := 5.0)
runs on BSSGP_ConnHdlr {
timer T := Tval;
+ var RANAP_PDU rx_ranap;
f_pdp_tx_ctx_act(apars, ran_index);
as_ggsn_gtp_ctx_act_req(apars, send_recovery := send_recovery);
@@ -1065,6 +1066,14 @@
send_recovery := send_recovery,
ran_index := ran_index);
}
+ [] RAN_CONN.receive(RANAP_PDU:?) -> value rx_ranap {
+ Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail,
+ log2str("Rx unexpected RANAP msg ", rx_ranap, " while waiting for RAB ASS REQ"));
+ }
+ [] RAN_CONN.receive {
+ Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail,
+ "Rx unexpected msg while waiting for RAB ASS REQ");
+ }
[] T.timeout {
Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail,
"Timeout waiting for RANAP RAB AssReq");
To view, visit change 43261. To unsubscribe, or for help writing mail filters, visit settings.