On ArchLinux /bin/sh is actually a symlink to bash, so bash is running
in limited mode and emulating the Bourne Shell. The shell detection
logic added in [1] does not work correctly for me because the cmdline
would be 'sh' or '/bin/sh', not 'bash'. This is what I am getting:
\033[1;32m====== FooBar_Tests.TC_foo_bar pass ======\033[0m
Let's switch to printf, which does interpret the backslash escapes
as expected by default, regardless of the actual shell in use.
Also fix ttcn3-dumpcap-stop.sh, which was left untouched by [1].
Change-Id: Id28193a7ca00b5501a6852e5b4a5412fbaa5e063
Fixes: [1] bf45a5cff8
Revert submission 30430
Reason for revert: I did not consciously merge these, maybe some misunderstanding of Gerrit UI elements. Although it really surprises me that merging could have happened that easily without me noticing
Reverted Changes:
I85c2dc201:WIP: ns: Add test for SNS Size Num. of IP Endpoint...
I3584b7b04:WIP: ns: Add test for SNS Size NSEI IE
Ic69c461cd:WIP: ns: Add test for SNS Size Num. of NSVCs IE
Change-Id: Ifab74bd8ae568a3099637fb53f5fe407f85952b6
Revert submission 30430
Reason for revert: I did not consciously merge these, maybe some misunderstanding of Gerrit UI elements. Although it really surprises me that merging could have happened that easily without me noticing
Reverted Changes:
I85c2dc201:WIP: ns: Add test for SNS Size Num. of IP Endpoint...
I3584b7b04:WIP: ns: Add test for SNS Size NSEI IE
Ic69c461cd:WIP: ns: Add test for SNS Size Num. of NSVCs IE
Change-Id: I2b963d8d547b7c97ba8499921e42c57bab4ffaee
Revert submission 30430
Reason for revert: I did not consciously merge these, maybe some misunderstanding of Gerrit UI elements. Although it really surprises me that merging could have happened that easily without me noticing
Reverted Changes:
I85c2dc201:WIP: ns: Add test for SNS Size Num. of IP Endpoint...
I3584b7b04:WIP: ns: Add test for SNS Size NSEI IE
Ic69c461cd:WIP: ns: Add test for SNS Size Num. of NSVCs IE
Change-Id: I838b9b608a939ff909efe24ce3c1fdbfb539939d
It can happen that the RLCMAC req arrives at osmo-pcu before the
CS_PAGING we send to it over BSSGP, in which case osmo-pcu will schedule
an RLCMAC DL Dummy Block. Take into account this scenario to avoid
failing id it occurs.
Change-Id: I30da93835c7738aefcd84691d83f39759dd4b599
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state
Change-Id: Icc94eb0544226facddcd65be65a8a41bcfc662cc
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state
Change-Id: I67483bc423567d1fc98eb912ece1cf5cda746119
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state.
Change-Id: If7121473a3580b40d3a658dc38b9bb1421196127
So far the test asked osmo-upf to use an actual IP address and TEID, but
normally it is sent with CHOOSE = 1 so that osmo-upf picks a new local
TEID and returns it with the proper local IP address in the response.
This is making the test more realistic, and also prepares for testing
Network Instance handling, where osmo-upf will need to return the proper
IP addresses for specific Network Instance names.
Change-Id: Iaba372cbb2e0cf0c5bee80b09d346f9bcb78bfbe
The proper name is mp_verify_gtp_actions.
jenkins is not affected because it uses another .cfg from
docker-playground.git.
Change-Id: Ia13407db795021a2c3e2923c08b63ad6cdd6b0f9
`lsof` isn't available in the docker image, use /proc fs instead to get
the shell type
Related: OS#5736
Change-Id: I38e132f49b0711d611d08b61c28b3092c991a191
The old output is preserved, too, in order to ensure
compatibility with expectations regarding legacy behavior.
Related: OS#5736
Change-Id: Ia92ff32c8ce09ab7805c5509837ec88fa4b864c5
osmo-upf has changed the naming of GTP action kinds, need to adjust the
test here to avoid failing tests.
Related: I49ac7b1f8b5b74f586edfed1dfb29f9af55a521b (osmo-upf)
Change-Id: I6fe4a4cf02ca05b772491d11a5edbdbd7b0b429a
Since osmo-ggsn.git Ia15c1cfd201d7c43e9a1d6ceb6725ddf392d2c65 osmo-ggsn
supports configuration of X3 timer, which should be set to (T3-RESPONSE
* N3-REQUESTS) configured at the peer.
The default values are 5 and 3 respectively, hence X3 is by default
5*3=15 seconds.
Let's use that default value for now.
Once new osmo-ggsn version is released, we can speed up test duration by
decreasing the values of the module parameters introduced in this commit
and configure VTY gtp timers at osmo-ggsn accordingly.
Related: OS#5485
Change-Id: I02c0982674b43317a5fc8f341c03eeeb1efee77f
Adjust the test to also check the special case ARFCN=0, which is at the
end of each sub list.
Related: OS#5717
Related: osmo-bsc Ic5e4f0531e08685460948b102367825588d839ba
Change-Id: Ia8f94d72651061427afc9e34f678544f89d0149b
osmo-bts-trx declares a connection failure when the radio link counter
S reaches 0. This counter is decreased every time the Viterbi decoder
yields a decoding error on the Uplink SACCH. For more details, see
3GPP TS 45.008, section 5.2.
The scheduler in osmo-bts-trx expects NOPE indications to be sent by
the transceiver in the absence of valid Uplink bursts. However, due
to the asynchronous nature of TRXD link, our virtual Um interface
implementation, fake_trx.py, does not generate NOPE indications on
it's own. Instead, trxcon is sending empty TRXDv0 PDUs (BURST.req),
which are then translated to proper TRXDv1 NOPE.ind by fake_trx.py.
The TC_conn_fail_crit currently sends L1CTL_DM_REL_REQ in order to
simulate connection loss, what makes trxcon disable all active
timeslots and thus stop sending NOPE.req to fake_trx.py.
Let's tune trxcon back to BCCH, in order to ensure that NOPE.req
messages are still being sent, so that osmo-bts-trx will be able
to declare a connection failure over the RSL as expected.
Change-Id: I34aee95111eafea90eeeea861682f1b4547d7b03
Related: Ic292d180ba64206fb4d88adb284f9f9d058b4587
Test 12 permutations of
(auth optional,required) x (a5 '0', '0 3', '3') x (hlr has auth info)
In TC_auth_options_2(), expect behavior after implementing OS#4830: if
the HLR fails to return auth info and auth + ciph are configured
optional, fall back to no authentication. This test will start
succeeding starting with commit
I5feda196fa481dd8a46b0e4721c64b7c6600f0d1 in osmo-msc.git.
All other tests yield the current behavior of osmo-msc.
Related: I5feda196fa481dd8a46b0e4721c64b7c6600f0d1 (osmo-msc)
Related: OS#4830
Change-Id: I8e3b02ca83e56ef5349d85f08407509e19fa353c
Some AMR format's payload size doesn't necessarily fit octet boundaries.
When AMR octet-aligned is used, padding bits are appended at the end to
fill the octet.
Until this patch, the padding bits where set with whatever payload fill
pattern was provided. Instead of doing so, better set the padding bits
to 0 to avoid conflicts when checking the received paytload later on,
since those bits are potentially be going to be set to 0 (eg when
converting to bandwidth-efficient).
Related: SYS#6161
Change-Id: I5bc68eb05c2f5500a259f4c73d14b51794f7f078
For the purpose of testing MGW pooling, test cases TC_mgwpool_*
configure an additional MGW instance by calling f_vty_mgw_enable()
and then remove it by calling f_vty_mgw_disable().
Unlike the other two TC_mgwpool_* test cases, TC_mgwpool_pin_bts
does not call f_vty_mgw_disable() - this breaks LCLS testcases
executed after it. Add the missing call.
Change-Id: I3157203888d704b25aabd2569035cd95d48c48b2
Fixes: 3f41e321c7
Fixes: OS#5727
Add a couple tests to validate some MGW pool features, like load
balancing and skip selection blocked MGWs from the pool.
Related: SYS#5987
Change-Id: I6a8c30309be406e37190dc67b6ee5af13e1b9e68
OsmoBSC has supported this VTY interface since more than a year ago.
Let's update the config files to use the new "mgw" node.
The recently submitted VTY commands without the redundant "mgw" prefix
are still not used here in order to have the config file work with
latest release which still doesn't support those.
Related: SYS#5987
Change-Id: I9b869e6bf4a3910f38014d570dce27e67af6e0d6
Vadim Yanitskiy
arehbein
Pau Espin
Neels Hofmeyr
Oliver Smith