https://osmocom.org/https://osmocom.org/favicon.ico?16647414092020-01-28T12:30:18ZOpen Source Mobile CommunicationsDistributed GSM - Feature #4380: D-GSM TTCN-3 testshttps://osmocom.org/issues/4380?journal_id=173572020-01-28T12:30:18Zosmith
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/17357/diff?detail_id=28712">diff</a>)</li></ul> Distributed GSM - Feature #4380: D-GSM TTCN-3 testshttps://osmocom.org/issues/4380?journal_id=173642020-01-28T16:33:57Zosmith
<ul></ul><p>I've fixed "Couldn't find GsupExpect" by connecting vc_GSUP_server with GSUP_PROC too. That resulted in a new error "GSUP_PROC has more than one active connections. Message can be sent on it only with explicit addressing.". To fix that, I've tried to decouple GSUP_ConnHdlr from HLR_ConnHdlr, to have 2x GSUP_ConnHdlr per HLR_ConnHdlr. But connecting the ports did not work then ("Referencing fields of a component is not allowed"). I've considered duplicating the ports to make it work, but ran into more errors. I've reverted the decoupling idea.</p>
<p>Finally, with figuring out and actually using explicit "to" and "from" addressing, and passing the related component vars, the emulated GSUP server in ttcn-3 receives the message! \o/</p>
<p>This was probably the hardest problem to solve, the rest should just be implementing the rest of the LU checking and cleaning up the patches. New patch pushed to the branch. Before submitting to gerrit, I'll make the emulated GSUP server in the ttcn-3 tests optional, so it doesn't break existing tests that don't use explicit to/from addressing.</p> Distributed GSM - Feature #4380: D-GSM TTCN-3 testshttps://osmocom.org/issues/4380?journal_id=173722020-01-29T15:12:34Zosmith
<ul><li><strong>% Done</strong> changed from <i>70</i> to <i>80</i></li></ul><p>Test infrastructure adjustments and OsmoHLR proxy test submitted: <a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/17061/1">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/17061/1</a> (and following patches)</p>
<p>The remaining bit before this issue can be closed, is a test where OsmoHLR is proxy again, but answers (or not) to mDNS requests. This should be rather easy.</p> Distributed GSM - Feature #4380: D-GSM TTCN-3 testshttps://osmocom.org/issues/4380?journal_id=173742020-01-30T15:55:12Zosmith
<ul><li><strong>% Done</strong> changed from <i>80</i> to <i>90</i></li></ul><p>Three more tests submitted, that cover all requirements set above.</p>
<p><a class="external" href="https://gerrit.osmocom.org/q/topic:dgsm-ttcn3">https://gerrit.osmocom.org/q/topic:dgsm-ttcn3</a></p> Distributed GSM - Feature #4380: D-GSM TTCN-3 testshttps://osmocom.org/issues/4380?journal_id=174072020-02-10T07:35:06Zosmith
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>90</i> to <i>100</i></li></ul><p>All test-related patches were merged.</p>
<p>Afterwards, all HLR TTCN-3 tests were failing, because the OsmoHLR patches that add new D-GSM related VTY commands were not merged yet. Until this is done, I've set "mp_hlr_supports_dgsm := false" (can be reverted once related D-GSM patches are merged to osmo-hlr.git): <a class="external" href="https://gerrit.osmocom.org/c/docker-playground/+/17113">https://gerrit.osmocom.org/c/docker-playground/+/17113</a></p>