Temporarily use titan.ProtocolModules.BSSGP_v13.0.0 from
https://github.com/osmocom/ as we have some fixes that are not
yet part of upstream.
Change-Id: I5d7261a5ac33a0231c1a3d73bdff7fb099568687
If a given setting is identical to the GBProxy_Tests.ttcn compile-time
default, we don't need to repeat it in the config file.
Change-Id: I3359f632eaf53bc602b1d10bb51de357f0eb2b45
The loopback interface should always be captured, as it includes
the 'ping' commands we use to detect the start of the packet capture.
Change-Id: Ic3aee59dd230141a5d182e9babf8d33d59144aa4
Recent commit 7d0f9a0ec383fcfca934731bd6979b6be6629c90 in osmo-pcu.git
fixed situation where lots of unneeded LLC UI dummy frames where being
sent. As a result, osmo-pcu correctly counts less dl rlcmac payload
bytes being sent, so we must adjust our test expectancies.
Related: OS#4849
Change-Id: I01c34a0948094b17cc0d67e613cd9b756f78c372
if we test if /sbin/setcap exists, we als should execute it from that
path, as running from a normal user doesn't have /sbin included in $PATH
Change-Id: I5131f869f86e6d136e0485da5e3749abbfc951e3
We cannot use "-i all" but must list each interface separately,
which is only supported by dumpcap. We also must write pcapng
files.
Change-Id: Id412af3bb6bcad5e0f2cf40a6dc497d7e4f3d948
Printing an unbound 'rx' variable when nothing was received due to
timeout is somehow not really useful. Print what we expected to
receive.
Change-Id: I4fee89baa954736ae8298b63667297dd57d8ec4f
For 12+ days, suspend/resume related SGSN + PCU TTCN3 tets have been failing.
It was the introduction of the BSSGP_CT:GLOBAL test port in
I40d973d80709f5d56f59247e8647b52754f09bc8 +
I805372f3024a0ec2491a24422e02c0bc6dc669d2 which caused the related PDUs
now to no longer show up where they used to.
Change-Id: I1977302fef4868dc1c330bc6f48f6a6608949393
Closes: OS#4902
When sending the SNS ADD in the test case the ip/port to add must be different
from the current NSVCs.
Fixes: 90f1974fb0 ("NS_Emulation: Support multiple NS-VC within one NSE (NS-VCG)")
Change-Id: I9bbbf1431468a452df324a7559518496e3eb48e3
Destroying at least most of the components in an orderly fashion avoids
at least most of the race conditions during test shutdown.
Change-Id: I2aa4ef8a70c1139893c9621f5a6b6007b221c13d
We did have a guard time in each ConnHdlr, but not in the MTC (test_CT).
However, we do have tests that don't use any ConnHdlr, and those were so
far ran without a guard timeout. Fix that.
Change-Id: Iee90fc26a151c692d3c6f3eb6ad80f528f8d939f
This way it's more obvious that it refers to the PTP BVC, like we
already use PCU_SIG and SGSN_SIG for the signaling BVCs.
Change-Id: Ie8d327b0c6fae0e7963cc5907ab0bc94e97c67f3
There are some messages/procedures on a PTP BVC which are not related
to one specific TLLI, but affect the whole PTP BVC. First and foremost
that is the FLOW-CONTROL-BVC. Let's check if the user is interested in
handling those internally (by connecting to the GLOBAL port). If not,
fall back to acknowledging all incoing FC-BVC and ignoring all ACKs.
Related: OS#4891
Change-Id: Ib80a6a522dbcb33fd0e7bd31a73ef28fdc636f57
Currently osmo-bts seems to be sending IPA RSL Connect ACK
unconditionally, even if the remote peer is not reachable.
Change-Id: Ibfa58f670401907801f610578dd9b4ebf155a83a
This port is used for sending/receiving RIM related BSSGP messages. It
exists once per BSSGP_CT Component (i.e. once per NSE), as RIM is global
for the entire NSE.
Change-Id: I04511df5dffbfe19faabf22014acc72b7673b7d6
Particularly in case both sides initiate a BLOCK or UNBLOCK procedure
at almost the same time, it can happen thet we're already in BLOCKED
state and receive a late BLOCK-ACK or in UNBLOCKED state and receive a
late UNBLOCK-ACK.
Let's just silently discard them instaed of generating NS-STATUS which
may confuse the peer.
Change-Id: I2e5b934e1cf6c6cf982d5ab1dbb32e8920b91071
These functions would not set a verdict in case no message was ever
received. This patch ensures that a timeout while waiting for a paging
message actually fails the test.
Change-Id: If71db2d37d67d02c5d9550202128ee3470762964
Related: SYS#5002
LLC UI dummy frames are only to be sent alone in order to delay TBF
termination. Until recently (osmo-pcu.git
Ifae1a7b2b3dfad8df19585063088ba0df2749c8f), osmo-pcu was sending LLC UI
dummy frames instead of padding at RLCMAC layer, which made no sense.
Related: OS#4849
Change-Id: I7e0d9ed2475dbf989fbf932c8b83117ff5fb28fc
With this setup we can and do now test:
* Paging a LAI on BVC0 is sent once per matching NSE
* Paging a LAI on BVC0 is sent to multiple different matching NSE
* Paging a RA ID on BVC0 is sent once per matching NSE
* Paging a RA ID on BVC0 is sent to multiple different matching NSE
Change-Id: I698a932b3dc78c776e9350283109463bcdc40e6b
Related: SYS#5226
We need to ensure that before each test the gbproxy does not have any
state. Move the vty commands into loops that run before we init either
SGSN or PCU Gb. This ensures that we don't send some spurious block or
other message at the start of the test.
Related: SYS#5002
Change-Id: Iaedfadf94f716b190495a807c28785be0078addc
We cannot specify create_cb function references from the config file,
so let's patch them into the data structure at start-up.
Change-Id: Idac9e97dde62b61d0423fdde16e3bd700d5287c0
Any NSE should be unconfigured at start up of the test case in order
to avoid any state leakage from previous test executions into the
newly-started test case.
Change-Id: I1dd491d5bce17b4602f1e26b42df003f1627714a
More recent clients start to send ID RESP, which was not the case at the
time the TTCN3 test suite was written.
As we don't really want to test the IPA CCM behavior, but we want to
test the actual remsim functionality, we can simply ignore any such
responses.
Change-Id: Id557ea9c540bf96465e7f18da87719888dd7a318
The NS specs state up to 1600 bytes "gross NS size" must be supported,
at least by the underlying FR layer. Let's test up to that. Let's
also speed things up by using 4-byte size increments, and print
the size of the current message.
Change-Id: I76358323e79cfc3d0e9c979c716b7a552f3b8e3b
This test shows that in current osmo-bsc, the start-mode fails to
propagate to the MultiRate Config IE, the only start-mode so far has
always been zero.
Change-Id: I75515baf8cda04567cad8a93c5aa88361c2d259f
Make sure that when a 'start-mode auto' is set, that the previous start
mode setting does not linger in the unused bits.
- after I577ff590d7588fd7e3ee4846c7955ab8f84cf2b1, osmo-bsc sets its
ICMI bit properly, but passes this test only because it *always* sends
smod (start-mode) bits as zero.
- in I49691df01745a7c485bf165e897872c35fc4b147, the smod bits are
properly sent on RSL, but this test shows that when ICMI becomes zero
for 'start-mode auto', the smod bits will remain whatever start-mode
was set in the previous osmo-bsc config. Instead, osmo-bsc should
clear the smod bits for 'start-mode auto' so that its MultiRate Config
does not vary depending on what was previously configured.
- in I1ec5bad0bce01cc425ee05ecf70c83ec662a226a, clearing smod is
implemented and this test is expected to pass.
Change-Id: I151678f64e680f30f35b6bb2b0036d63efde9f2c