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
Previously the test was starting to count Osmux packets too early.
Now that osmux conn state has been improved in osmo-mgw [1], Osmux
Rx packets are not forwarded until the conn is completely configured
through MGCP, hence first osmux packets snet by our async emulation
are dropped.
So we must start counting the transmitted valid osmux packets according
to what the test says, when the full conn is set up.
[1] osmo-mgw.git Change-Id I7654ddf51d197a4107e55f4e406053b2e4a02f83.
Related: SYS#5987
Change-Id: I7efd87bbbda2ffa8fd0c5a64658d42edd0f30857
Since osmo-mgw.git 2177919edb3bc0dd308be388272486ffd97f4761, osmo-mgw can handle
properly conns containing a different remote and local CID.
Hence this hack can be dropped.
Related: SYS#5987
Change-Id: I531631d716581f68c11d3c0b07fc6755a822a0d3
Some tests require to match what's configured in osmo-mgw.
Let's make it possible to change it through a module parameter.
This will be needed for a follow-up patch to test >256 concurrent osmux
conns, which will require increasing the number of configured endpoints
above that value.
Change-Id: Ia1e5a0b59ba7c49e97c2cf7ee7a009f3827cf36d
There also exists UL equivalent of this message, for which I am
planning to add a template. Let's clarify direction in the name.
Change-Id: I3b19c6679eb432b062e28aee9dd1220dbf33ee31
Until now we forgot to properly configure the osmux socket local ip, but
that was fine because 0.0.0.0 was taken as a default.
With addition of IPv6, this changed, and the socket is not bound unless
an IP address is set (to allow conditional use of IPv4, IPv6 or both).
Depends: osmo-mgw.git Change-Id I446cd7da217e9f4a74995d7784ae55dcc60a29b7
Change-Id: I4e0ea11ae7e55da600aec56bebf694f3ba0f7b72
in Diameter, the CC-Input/Output direction is defined as follows in
RFC4006:
"""
8.24. CC-Input-Octets AVP
The CC-Input-Octets AVP (AVP Code 412) is of type Unsigned64 and
contains the number of requested, granted, or used octets that can
be/have been received from the end user.
8.25. CC-Output-Octets AVP
The CC-Output-Octets AVP (AVP Code 414) is of type Unsigned64 and
contains the number of requested, granted, or used octets that can
be/have been sent to the end user.
"""
So:
* 3GPP uplink is from end user to PGW, and hence 'CC-Input-Octets'
* 3GPP downlink is to end user to PGW, and hence 'CC-Output-Octets'
This test started failing a few days ago since a bug was recently
fixed in open5gs which was swapping the counters in open5gs-upfd:
https://github.com/open5gs/open5gs/pull/1793f72a1edc6e
Change-Id: I2f64649ce70d85634f14b84eff98731f7711cbad
The RSL_IE_MultirateCfg was implemented and added to union RSL_IE_Body
in [1]. Before this change, this IE was decoded as RSL_LV (basically
an octetstring). Now this IE is decoded as RSL_IE_MultirateCfg, while
some AMR tests still expect RSL_LV. Let them use RSL_IE_MultirateCfg.
Change-Id: I40dab41d5dc5d14e358ba5a070ce174e7d8d4a4b
Fixes: [1] I0a5ddce570c0fd70f096d897b0b609d20b552ff7
In TTCN-3 it's not possible to store templates in records, so in
f_assignment_codec() we match received RSL_IE_MR_CONFIG against the
value (not template!) stored in g_pars.expect_mr_conf_ie.
Because of that, the length field is not being calculated by TITAN
for us, so we need to calculate it in ts_RSL_MultirateCfg ourselves.
Automatic length calculation only works during encoding/decoding
and when matching against a receive template.
Change-Id: I595be86d69913ba25e965a5a5c6977e00c342e60
Currently this testcase fails:
RSL MR CONFIG IE does not match expectation.
Expected: { other := { len := 2, payload := '2804'O } }
Change-Id: Icc5381eccb924803b1117b46d2b4c47cee6dabd7
Pau Espin
Oliver Smith
arehbein
Vadim Yanitskiy
Neels Hofmeyr