Our TTCN3 implementation of the IPA multiplex with CCM handshaking
has been based on some wrong assumptions about the protocol logic.
To make the code stricter, we
* send an ID_ACK immediately after connecting TCP in a client
* separate client and server CCM responder logic
* always respond with ID_ACK to ID_RESP (we accept any identity)
Also, as the Osmocom CTRL interface uses an IPA multiplex but no CCM,
we introduce a boolean variable (and function argument) to clearly
enable/disable CCM support in a given IPA_Emulation component. The
CTRL_Adapter has been modified to use this flag to disable CCM.
This also removes the need of cherry-picking
"HACK: Work around IPA CCM bug in OsmoBSC"
Change-Id: I304535d28a165f76a0a140dc0a15dd81a9db28c8
from the laforge/bsc-workaround branch.
Change-Id: I6d9eaf0d69457caacc03b9049a8bc57976480617
In addition to the existing 3GPP AoIP stacking, allow BSSAP to
run on top of a SCCPlite stacking. Implement both the server and the
client role for IPA.
Related: OS#2544
Change-Id: Ie844c4de62e0ef5d5c4c366185968211a7f6d676
The testcase TC_assignment_sign does not assign g_pars in its
test function. However, it assigns local variable pars but then
never uses it.
- remove local variable pars and assign g_pars instead
Change-Id: Iad65d8ff8bfb98df2b212c69916f1e74dc2c61af
Related: OS#2762
Our patch for SMPP AlertNotification was merged, so we can switch
back to use upstream instead of our osmocom fork.
Change-Id: Ib171451af264aa675b173b5cad37f08bcd64fbc3
for some reason, the number of TMSI paging requests that arrive
on the jenkins build slave is quite a bit lower than those I see
on my laptop. Let's adjust our expectations to make the test pass.
Change-Id: I548dedd1b3391d059a141a2eef71c32be4b97cc1
Closes: OS#3025
Don't use explicit log() statements for normal message forwarding
between ports. This will be visible in the automatically-generated log
statements anyway...
Change-Id: Idcfb1897dd00df1839cf1a0182a5a030bf71c0cb
the osmocom fork has support for AlertNotification, which upstream
doesn't. Pull request is pending, so we have to use our osmocom
fork repo meanwhile.
Change-Id: I9b6b120fe74b46183517264d85651ac0d99b4035
In Change-Id I52a4c8118828c1605cf672889982f987568ad17d we introduced
a name change for the SCCP/M3UA components, which meant that the log
level configuration did no longer apply as intended.
Change-Id: Iebdaf3446a81ea5f8310110f5cca2bdb3e552e3f
The L3 transaction-id in MT-SMS is allocated in the MSC, so any
messages we expect from the MSC must carry c_TIF_ORIG.
Change-Id: I6ea977a7662fdfc9c504f13ac5632ac20a04f522
Provide a script to mask timestamps and source file lines in expected results
files: when updating expected changes, it is useful to see the exact semantic
changes, not the timestamp and source file line changes in the git diff.
Change-Id: I785e126b1f5afddd1b722bc5e922ed90970efa8a
'make clean' as generated by ttcn3_makefilegen removes all *.log files, which
of course cleans out expected-results.log, which should not happen. Since this
is a junit XML file, rename the suffix to .xml.
Change-Id: Ic334f6b758eef865e3a497aa430691a3ae696d25
The testcase intentionally responds to the RAN sided CRCX
with a garbeled message to cause the MGCP handlin inside
the MSC to fail. The MSC is then expected not to perform
further MGCP operations since it did not get a proper
response to the first CRCX, so the specific endpoint name
is not known, eventually preventing from doing an MDCX.
However, the testcase responds to incoming DLCX commands,
instead setting the verdict to fail.
Also the altstep that dispatches the message after the
errornous MGCP response unconditionally catches all BSSAP
messages before entering the sub-altstep
as_clear_cmd_compl_disc() that handles the clearing of
the connection. Eventually the clear command is never
received in this sub-altstep.
- Make sure the verdict is set to fail when an MGCP
message is received after the errornous response to
the CRCX.
- Remove the unconditional BSSAP.receive in order to
be able to dispatch the clear command properly
- Update the expected-results.log file
Change-Id: I806491741d310e4410f6cb4ce0309235e9bf4300
Related: OS#2882
All three BTS are configured for ARFCN 871 and BSIC 63, which causes trouble
for handover tests. Set BSICs to 10, 11 and 12 (not 0,1,2 to mark the
distinction from the cell_identity).
It wasn't a problem so far since we cheated by passing the BTS target number
from VTY. But as soon as we will start identifying handover target cells by
ARFCN+BSIC exclusively, TC_ho_int would fall on its face without this patch.
See also: docker-playground I29a117aa54aa06ca49646f25a08af8521832fd8d
Change-Id: I2ea8889ea40953f5a23eab40db52585556a410bc
With https://gerrit.osmocom.org/#/c/7685/ the test TC_vty_msisdn_isd
is now passing. Update expected log output accordingly.
Change-Id: Ie8cfbef5a0adcb927917b0623f89309479a60001
Depends: Iffe1d7afb9fc7dbae542f70bbf5391ddc08a14b4
Related: OS#2785
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
This adds a set of four new testcases relted to dynamic PDCH switching:
One successful and one unsuccessful for each Osmo + IPA style dynamic
PDCH.
Closes: OS#3099
Change-Id: I7a7a937548a35461d86e93ead79c39a37a59563e
By default, if ccache is found in PATH when regen-makefile.sh runs,
use cached compiled C++ object files during the build (or populate
the cache in case an object is not cached yet). Objects are cached
in ccache's default cache directory (~/.ccache) unless overriden by
the CCACHE_DIR environment variable.
The USE_CCACHE environment variable overrides auto-detection
in regen-makefile.sh and disables (USE_CCACHE=0) or enables
(USE_CCACHE=1) use of ccache.
Rebuilding the test suite from scratch with a populated cache
is an order of magnitude faster than doing an initial build.
ccache only speeds up C++ (.cc) to object file (.o) compilation.
Linking object (.o) files into shared object (.so) files is still
performed by the real compiler during every build.
Change-Id: Ibb538f602206535c06980f88191c1dabe3c4cd82
Add VTY functionality to GGSN tests, and use the VTY to enable/disable
GTP-U Tx sequence numbers in the running osmo-ggsn.
The GTPU packet template now makes sequence numbers optional.
A template created with its sequence number set to 'omit' will result in
a packet without a sequence number, i.e. the 'sequence number present' bit
in the packet header is cleared, and the sequence number field is omitted
from the encoded GTPU T-PDU packet.
Re-use the existing TC_pdp4_clients_interact() test for testing the
behaviour of osmo-ggsn. This test is now run twice, once with and
once without GTP-U Tx sequence numbers. Verify that packets relayed by
osmo-ggsn match its "g-pdu tx-sequence-numbers" configuration setting.
Change-Id: I1dc299407c61b1c865035add44067b8ab89001b3
Related: OS#2519
The osmocom fork of the titan.TestPorts.UNIX_DOMAIN_SOCKETasp master
branch has been force-pushed in order to incorporate patch review
comments from upstream TITAN.
Change-Id: I23ec12fa5fb30796f37257cf5ea3fcd74d3ecb80
When the MS sends a Clear Request in the middle of a Location Updating, it
should be permitted for the MSC to send a Location Updating Reject back. Extend
with an alt that also allows a LU reject before the Clear Command.
The test explicitly hints at https://osmocom.org/issues/2862 which rightfully
forbids the MSC to send a second Clear Command after the first is completed.
However, this test so far explicitly permits a second Clear Command, so it was
probably passing in error all the time. Set verdict to failure if a second
Clear Command is received before the DISC_IND.
This changes the test verdict to failure with current osmo-msc master,
rightfully so; the failure will be fixed by the upcoming MSC subscr conn FSM
refactoring.
Change-Id: I7bc5555b829d61b0a2529107bc9b58446865545d
Compare current test results to the expected results, and exit in error on
discrepancies.
Add compare-result.sh: (trivially) grep junit xml output to determine which
tests passed and which didn't, and compare against an expected-result.log,
another junit file from a previous run. Summarize and determine success.
Include an "xfail" feature: tests that are expected to fail are marked as
"xfail", unexpected failures as "FAIL".
In various subdirs, copy the current jenkins jobs' junit xml outputs as
expected-results.log, so that we will start getting useful output in both
jenkins runs and manual local runs.
In start-testsuite.sh, after running the tests, invoke the results comparison.
Due to the single-line parsing nature, the script so far does not distinguish
between error and failure. I doubt that we actually need to do that though.
Related: OS#3136
Change-Id: I87d62a8be73d73a5eeff61a842e7c27a0066079d
The MDISC_IPACCESS is only used for the media (CRCX/MDCX/DLCX) related
commands, not for the PDCH activation/deactivation. The latter uses
normal MDISC_DCHAN.
Also, add the inverse templates for PDCH actiation/deactivation, so we
now have both receive and transmit template for each of the 6 related
messages (activation, deactivation, plus each their ACK + NACK).
Change-Id: I170a90391859d71e1f96a72205487cccba5b6ae7
NOTE: This needs changes to your osmo-bsc.cfg, as it will now need
an osmocom-style dyn PDCH on TS4, and an IPA-style dny PDCH on TS3.
--- a/ttcn3-bts-test/osmo-bsc.cfg
+++ b/ttcn3-bts-test/osmo-bsc.cfg
@@ -154,10 +154,10 @@ network
phys_chan_config TCH/F
hopping enabled 0
timeslot 3
- phys_chan_config TCH/F
+ phys_chan_config TCH/F_PDCH
hopping enabled 0
timeslot 4
- phys_chan_config TCH/F
+ phys_chan_config TCH/F_TCH/H_PDCH
hopping enabled 0
timeslot 5
phys_chan_config TCH/H
Corresponding change in docker-playground.git has Change-Id
I229000ce7609845fdf24cafe1f5ec2bfa3f507e8
Change-Id: I2a42531dc5555ab4772d538fda462343605b8feb
For upcoming dynamic PDCH activation/deactivation tests we would
like to access the PCU socket from ConnHdlr, rather than test_CT.
Let's prepare for that.
Change-Id: Ib8811dd87f737f326f7ed8f652aa6f552c3f05f8
The bit-string type should be indexed by timeslot number, i.e. the first
element [0] should equal timeslot 0, the last one TS7
Change-Id: Ib89689abd998d4940895ba04f49eb140888bc73f
The purpose of the various IP addresses used by our GGSN tests is not
immediately clear. Add documentation based on the current status quo.
Change-Id: I079efcff3dab09d71330625f5b661cd81e42bf38
Start and stop the CTRL interface and provide CTRL bind interface config
modulepars.
Possibly everyones' local setups may need modification to allow the
ttcn3-bts-tests to reach osmo-bts-trx's CTRL port.
WARNING: This commit has to be merged "at the same time" as
I1ec86b157ebd46bf622a0ca51eba225f15c99fbb or the jenkins ttcn3-bts-tests will
fail.
a) if we want to set a modulepar mp_ctrl_ip here, it needs to be added to
osmo-ttcn3-hacks.
b) if we have the f_ipa_ctrl_start() in osmo-ttcn3-hacks, we need to configure
the proper IP and bind interface here, or all tests will fail because
f_ipa_ctrl_start() cannot connect.
Change-Id: I502b4891e6720ae2fb251c03542f707880a6f728
Various improvements to the comments documenting packet templates
used in GGSN_Tests: fix IPv4 vs. IPv6 confusion, clearly indicate
whether templates are used for sending or for receiving/matching
packets, and add a missing comment.
Found while studying code to prepare for issue OS#2519.
Change-Id: I3bfc21a5ba74e0505457e4874f93501ad7c68b7b
Related: OS#2519
In Change-Id: I52a4c8118828c1605cf672889982f987568ad17d we introduced
config file syntax errors. It seems that change was not tested at all
before pushing :(
Change-Id: I80577798b502957afaa46abb510bcca3dc174ee4
Harald Welte
Philipp Maier
Neels Hofmeyr