Project

General

Profile

Bug #3675

TC_mo_ussd_euse_defaultroute fails

Added by fixeria 19 days ago. Updated 18 days ago.

Status:
Resolved
Priority:
High
Assignee:
Target version:
-
Start date:
10/28/2018
Due date:
% Done:

100%


Description

I just noticed that the 'TC_mo_ussd_euse_defaultroute' always fails in Jenkins:

MTC@DELL: Test case TC_mo_ussd_euse_defaultroute finished.
MTC@DELL: Verdict: fail reason: Non-matching VTY response: pattern "% Created subscriber *" 
MTC@DELL: Starting external command `../ttcn3-tcpdump-stop.sh HLR_Tests.TC_mo_ussd_euse_defaultroute fail'.
------ HLR_Tests.TC_mo_ussd_euse_defaultroute fail ------

I also managed to reproduce the failure in my local environment, and noticed the following:

  • the tests case always fails when OsmoHLR is just launched (the first execution);
  • every even tests case execution is successful,
  • every odd tests case execution is unsuccessful.

Please see logs and VTY captures for both successful and unsuccessful executions attached.

osmo_hlr_fail.log osmo_hlr_fail.log 5.08 KB fixeria, 10/28/2018 10:23 AM
osmo_hlr_ok.log osmo_hlr_ok.log 17.7 KB fixeria, 10/28/2018 10:23 AM
vty_capture_fail.pcapng.gz vty_capture_fail.pcapng.gz 1.38 KB fixeria, 10/28/2018 10:31 AM
vty_capture_ok.pcapng.gz vty_capture_ok.pcapng.gz 4.29 KB fixeria, 10/28/2018 10:31 AM
vty_debug.patch vty_debug.patch 1.36 KB fixeria, 10/28/2018 11:21 AM
vty_debug_v2.patch vty_debug_v2.patch 1.42 KB fixeria, 10/28/2018 11:40 AM

History

#1 Updated by fixeria 19 days ago

With the attached patch applied, one can see the following difference
between successful and unsuccessful test case executions:

MTC@DELL: "Sending VTY: enable" 
MTC@DELL: > ENABLE
MTC@DELL: "Sending VTY: configure terminal" 
MTC@DELL: > CONFIG
MTC@DELL: "Sending VTY: hlr" 
MTC@DELL: > CONFIG
MTC@DELL: "Sending VTY: ussd default-route external foobar" 
MTC@DELL: > CONFIG
MTC@DELL: "Sending VTY: end" 
MTC@DELL: > ENABLE
MTC@DELL: "Sending VTY: subscriber imsi 262428880126457 create" 
MTC@DELL: > ENABLE
MTC@DELL: "Sending VTY: subscriber imsi 262428880126457 update msisdn 491613302188" 
MTC@DELL: > ENABLE
MTC@DELL: "Sending VTY: subscriber imsi 262428880126457 update aud2g comp128v1 ki 000102030405060708090A0B0C0D0E0F" 
MTC@DELL: > ENABLE
MTC@DELL: "Sending VTY: subscriber imsi 262428880126457 update aud3g none" 
MTC@DELL: > ENABLE
...

vs

MTC@DELL: "Sending VTY: enable" 
MTC@DELL: > ENABLE
MTC@DELL: "Sending VTY: configure terminal" 
MTC@DELL: > CONFIG
MTC@DELL: "Sending VTY: hlr" 
MTC@DELL: > CONFIG
MTC@DELL: "Sending VTY: ussd default-route external foobar" 
MTC@DELL: > CONFIG
MTC@DELL: "Sending VTY: end" 
MTC@DELL: > CONFIG
MTC@DELL: "Sending VTY: subscriber imsi 262423101630462 create" 
MTC@DELL: > CONFIG
MTC@DELL: Test case TC_mo_ussd_euse_defaultroute finished. Verdict: fail reason: Non-matching VTY response: "" 
MTC@DELL: Starting external command `../ttcn3-tcpdump-stop.sh HLR_Tests.TC_mo_ussd_euse_defaultroute fail'.
------ HLR_Tests.TC_mo_ussd_euse_defaultroute fail ------

For some reason, sending 'end' command doesn't change the current VTY node to 'ENABLE' in the second case.
Thus, the following subscriber creation command is getting rejected, because it belongs to 'ENABLE' node, not 'CONFIG'.

#2 Updated by fixeria 19 days ago

According to Wireshark and the HLR log, subscriber is created in both cases, so 'end' works fine.
It seems we are detecting the VTY prompt incorrectly. Please check out the updated version of debug patch.

MTC@DELL: "Sending VTY: configure terminal" 
MTC@DELL: "> CONFIG OsmoHLR(config)# " 
MTC@DELL: "Sending VTY: hlr" 
MTC@DELL: "> CONFIG OsmoHLR(config-hlr)# " 
MTC@DELL: "Sending VTY: ussd default-route external foobar" 
MTC@DELL: "> CONFIG Switching default route from <none> to foobar" 
MTC@DELL: "Sending VTY: end" 
MTC@DELL: "> CONFIG OsmoHLR(config-hlr)# " 
MTC@DELL: "Sending VTY: subscriber imsi 262422087836837 create" 
MTC@DELL: "> CONFIG end" 
MTC@DELL: Test case TC_mo_ussd_euse_defaultroute finished. Verdict: fail reason: Non-matching VTY response: "" 
MTC@DELL: Starting external command `../ttcn3-tcpdump-stop.sh HLR_Tests.TC_mo_ussd_euse_defaultroute fail'.
------ HLR_Tests.TC_mo_ussd_euse_defaultroute fail ------

The TTCN-3 VTY code recognised "Switching default route from <none> to foobar" as 'CONFIG'!

#3 Updated by fixeria 18 days ago

  • Status changed from New to Feedback
  • Assignee set to fixeria
  • % Done changed from 30 to 90

Please see: https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/11489
With this change the test case now always passes.

#4 Updated by fixeria 18 days ago

  • Status changed from Feedback to Resolved
  • % Done changed from 90 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)