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.
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.
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
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.
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.
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.
These test cases check if gbproxy behaves as expected when it comes to
dealing with BVC-RESET on the signaling BVC. The tests are not passing
due to limitations of gbproxy. So it's not clear if the tests are 100%
correct until gbproxy is fixed.
We want to move a virtual subscriber between BVC with one NSE,
but also to other NSE/PCU at runtime. The number of BVC and NSE
may be large in a given test config, and we really don't need
hundreds of test ports per component; Instead, reconnect the
test ports to whichever BVC we want at runtime.
Let's use a 'record of' with indefinite length in order to be able to
dynamically adjust the number of BSSGP_BVC_CT references based on how
many BVCs we have configured.
The hard-coded array of three cell identifiers in the ConnHdlr
configuration doesn't really reflect situations with a different
number of PCUs than three, and a different count of BVCs than one
Let's pass the entire PCU configuration as parameter into every
ConnHdlr. This way, the ConnHdlr can learn whatever cell identities
there mgiht be in whatever number of BVCs of each NSE.