This param is not needed anymore since new releases used in -latest don't
need to disable it.
Change-Id: I484267c169646310564bd6d9cd13a196b61400e4
Related: OS#5042
GSUP proxy routing, as it is implemented in an upcoming osmo-hlr patch,
requires that osmo-hlr returns a received Source Name IE back as Destination
Name IE. Add tests for these, for various situations.
These tests pass since GSUP request handling with request->response association
was introduced to osmo-hlr in I179ebb0385b5b355f4740e14d43be97bf93622e3.
Implement this by adding a source_name to the g_pars, which should be sent out
in ts_GSUP_* to osmo-hlr, and expected back as destination_name in returned
messages.
Add source_name and destination_name to various templates, with default :=
omit.
Add f_gen_ts_ies() and f_gen_tr_ies() to compose expected IEs more generically.
Change-Id: I3728776d862c5e5fa7628ca28d74c1ef247459fa
Request "gsup.hlr" service right after creating subscriber from the home
HLR. "TC_MSLookup_mDNS_service_other_home" is similar, but does not query
the "gsup.hlr" service. The "gsup.hlr" service has a different code path
in OsmoHLR:
- it exists without being explicitly configured and returns the IP and
port of the HLR's own GSUP server
- the request is answered, even if the subscriber is not attached to the
HLR (for Location Update via proxy)
Related: OS#4380
Change-Id: Id567989e4be7ac2d3857d3ea61a1ca3a2401a8dc
Send an mslookup mDNS request to the home HLR, asking about a service
that is not "gsup.hlr". Hence the "_other" in the test name, service
"gsup.hlr" has different code paths, and related tests will be added in
follow-up patches.
This is the first test using MSLookup_mDNS_Emulation, so add related
test infrastructure.
Related: OS#4380
Depends: osmo-hlr I2fe453553c90e6ee527ed13a13089900efd488aa
Change-Id: Ia7f92d33691f910549353b16a7b0efc18e521719
Make it possible to do CS location update, not only PS. This is needed
for upcoming D-GSM related tests.
Related: SYS#4618
Change-Id: Idd699f054c9242614b9bea066428293f8b2da9c2
TC_gsup_sai_num_auth_vectors tests the GSUP IE
GSUP_IE_NUM_VECTORS_REQ which allows the client to
ask for a specific amount of auth tuples in a
Send Auth Info request.
Change-Id: I10a523cbaf08fe42924ffd0dc498496fdc76395f
In Change-Id I40c6cf7e28ad9331e6c27fe7acafa3f9e277eedf we introduced
a patch that verifies the AMF separation bit for 3G/3G vs 4G
authentication. However, the test ignored the fact that AUTN cannot
be present in pure 2G tuples.
This makes TC_gsup_sai pass again.
Change-Id: I9b61e62a58b583461dd5e67dd12119be282cae21
I found some of the tests hard to analyse when geting failures, because they
don't stop the test on failure. Spread some 'mtc.stop' so that the test stops
at the failed message instead of carrying on.
Change-Id: I804aca84d0ccf4767a5c097cf6c882ccbd87c4e1
Test all possible code paths where a subscriber on demand can be
created:
* Check IMEI early
* Location Update
* Send Auth Info
Related: OS#2542
Change-Id: Id544fa906ad442c2bbbccff437c18d04ddccde2e
Create tests for most code paths of rx_check_imei_req() in hlr.c (except
for subscriber create on demand, this will be in an upcoming patch).
Add missing message types to GSUP_Types.ttcn, and adjust the IMEI and
IMEI_Result IEs for consistency with the existing IEs, and to make the
tests compile.
Related: OS#2541
Change-Id: I97c8462f0817149feadd0c4865e3df6c2af92a80
Allow to check if a certain pattern does not match the "show subscriber"
output. This will be used by upcoming tests for the check IMEI GSUP
message type, to check if the IMEI was not stored, depending on the
OsmoHLR configuration.
Change-Id: I176d8fd2ee74e1eb7ac797f931cd6005d398740f
Some of our files didn't have a copyright notice at all, let's add
it. Also, update the notices in other files and ensure a SPDX
identifier is present in all but the most trivial files.
Change-Id: If7fa19ce484b415bc645e39b3d0d666b44b5f0fd
In the most use cases of f_SS_expect() we are not interested in
GSUP_PDU returned by this function. Calling it without storing
the returned value causes TTCN-3 compiler to complain:
warning: The value returned by function
`@HLR_Tests.f_SS_expect' is not used
Let's make use of previously unused variable 'res', and save
the returned GSUP_PDU to make the TTCN-3 compiler happy.
Change-Id: Ifda42aa18af8076013b436364513296b2b008731
Both session state and session ID IEs are always being encoded
together by libosmocore's GSUP implementation. So, if a message
contains a session ID IE, session state IE shall also be there.
For some reason, the session state IE was missing in both
ts_GSUP_PROC_SS_ERR and tr_GSUP_PROC_SS_ERR templates. This
could led to incorrect matching in our test cases.
This change fixes both templates by adding the missing IE. Since
tr_GSUP_PROC_SS_ERR templete is used in HLR_Tests.ttcn, all the
affected matching statements were also corrected.
This correction doesn't affect successful test case executions,
because we don't test possible problematic situations yet. But
if something went wrong on the HLR side (i.e. SUT), the matching
statements wouldn't match the PROC_SS_ERR message correctly
and continue to wait until the guard timer is expired.
Change-Id: I44070396ce7119eab4608d9f9fb090bb223dfaa2
As at the moment, OsmoHLR doesn't support "structured" SS, such
requests are being rejected. This test case aims to verify that.
Change-Id: I147b919d0242b3b44e39a4587bf1b4660fa58bd2
Related: OS#3651
Call mtc.stop after setverdict(fail), add reasons to most failures and
fail with verdict error for internal errors.
Change-Id: I9b618235939fa41160b9be6677b121963d3ec857
Going via GSUP_Emulation (rather than using GSUP_CodecPort directly)
adds many benefits, such as:
* ability to have multiple transactions in parallel
* no silent discard/ignore of unexpected GSUP messages, like those
for IMSIs we don't expect.
Change-Id: Id2ddd6b81c374ad6350b62fcc5442436757d66cd
Check for reception of an Insert Subscriber Data with outdated MSISDN.
This happened to me while working on a fix for issue OS#2785, and it
seems to be an easy mistake implementations can make. Catch this
situation in the test and log an explicit message about the problem.
Related: OS#2785
Change-Id: Ib0809617cca621cc22f29b078828057fd49f27e5
Don't exit too early: After sending ISD.resp we still need to wait
for the UL.res from the HLR before continuing processing.
Change-Id: Iab42a397cbca83b86fc8a6b26ae2d66abb81c187
This tests whether the HLR is sending an InsertSubscriberData to the VLR
of an active/registered subscriber after the MSISDN is updated in the
HLR.
Change-Id: I597a3c2d49aa6fa65007304105363a3e99fa4ae9
Related: OS#2785
Pau Espin
Vadim Yanitskiy
Neels Hofmeyr
Oliver Smith
Harald Welte
Daniel Willmann