Others projects don't contain a dash in there, and it seems to cause
problems with TTCN3 VTY expectations.
Change-Id: I3430abb5fc622dec293457466e760de95fa3a05c
Some are used to control (M)CS values for downlink while some do it for
uplink. Let's make clear which one is used for what. Take the chance to
document the fields a bit better than they were.
Some more information about the origin of cs_downgrade_threshold can be
found in the commit introducing it: 70b96aa232.
Related: OS#4286
Change-Id: I4e890e924b094a1937fbd3794de96704cf0421a8
Since there can be multiple PDCH channels configured on different
timeslots, different TRXes, and BTSes, the PTCCH/U handling code
in OsmoPCU needs to know the exact origin of a given RACH.ind.
Otherwise, it is not known which subscriber originated a given
PTCCH/U indication, and hence it is impossible to send PTCCH/D
Timing Advance notification properly.
Fortunately, we can extend the RACH.ind message without even
bumping the protocol version, because every single PDU has a
fixed size defined by the largest message - INFO.ind. In case
if the actual message payload is smaller, the rest is filled
with a constant padding byte (0x00).
Older versions of OsmoPCU will consider the new fields as padding,
while the messages from older OsmoBTS versions will always have
both fields set to 0x00. Since C0/TS0 cannot be configured to
PDCH, this can be easily detected on the other end.
Change-Id: If209001885ffb14b64a8e808df3700d85a4b2ef9
Related: OS#1545
So far there was a memory leak, because free()ing 'the_pcu.bctx'
would cause ASAN to complain. And that's reasonable, because it
needs to be freed properly. Moreover, 'the_pcu.bctx' may simply
be uninitialized in some cases, e.g. when OsmoPCU is terminated
before connecting to the SGSN.
Let's use the new bssgp_bvc_ctx_free() from libosmogb.
Change-Id: I274e79e1746c7678b81720ec11e8a564befe38ba
Depends: Ia78979379dbdccd6e4628c16f00d0c06d9212172
Share a single instance of 'pcu_l1_meas' between all unit tests,
set initial measurement values in main(). This way we can get
rid of the following warnings:
Unable to update UL (M)CS CS-X because we don't have link quality measurements.
Change-Id: I1c82076df6cd0833d243e1e6afb140bae3bd2ec9
Fixes: OS#3828
Both BSSGP SUSPEND ACK and NACK messages use BVCI=0 (signaling),
which always exists. Claiming that BVCI=0 is unknown is wrong.
Instead of adding both BSSGP_PDUT_SUSPEND_{ACK,NACK} to the 'if'
statement, let's rather avoid rejection for all BVCI=0 messages,
as there may be other unlisted message types.
Change-Id: I780657c1e8f67e0bef0e92a31db7ba61b57d7ec4
Related: OS#4111
Recent commit added an assertion to check for buffer boundaries and it
actually gets hit.
One of the 2 code paths calling pcu_l1if_tx_pch() was passing a buffer
of 23 bytes while one of maximum 22 is expected (because plen is not set
in the buffer but set inside pcu_l1if_tx_pch()).
So it seems before the assert, that code path was actually writing 1
byte outside the boundaries of data buffer, since bitvec_pack() uses
data_len field of bitvec.
Related: OS#4228
Fixes: 8dc09e73d0
Change-Id: I84c5dfd4d5580e9d4c00ed21887cb51bd9abbd2e
For a long time the VTY command to show all active TBFs was broken.
The TBF filtering (by allocation origin) logic allows one to show
TBFs allocated on CCCH, PACCH, or on both of them. In the latter
case we have been checking whether a TBF was allocated on both
logical channels at the same time.
Let's fix this by passing a flag-mask instead of boolean arguments.
To be able to use GPRS_RLCMAC_FLAG_* definitions from "tbf.h", let's
exclude them from "#ifdef __cplusplus ... #endif" block.
Change-Id: I1c9f401368af880a97d32905c4cce0da481ffc21
paging group is 3 bytes and imm assign with plen prepended is 23 bytes,
so there's 1 extra byte not needed and makes code confusing.
Change-Id: Id7835e5aa1506505ff54e019b38f30111f79b5dc
Otherwise, a new meas object is allocated in the stack in upper layers
which doesn't contain the link_qual information (have_link_qual=0),
outputting following error:
osmo-pcu/src/gprs_ms.cpp:644 Unable to update UL (M)CS CS-2 because we don't have link quality measurements.
Change-Id: I1980ca325c8d65f3f6310fa697dd810eec7ab077
Move code in rcv_block_gprs() only needed for rcv_control_block() into
the later. This way rcv_block_gprs() is simplified and shows similar
code paths with regards to rcv_data_block().
It can now be seen that the main difference between both is the meas
param no being passed in the control case.
Change-Id: I2a0133463edced93c72ccc743a0cf00d1d6922cf
Make sure that the compiler always assumes the same C dialect, to
prevent unexpected compiler errors when building with older compilers
(on other Linux distrubtions like in OBS, or in docker).
Use gnu89 and gnu++03, because that is what the code currently compiles
with.
Related: https://lists.osmocom.org/pipermail/openbsc/2019-September/013030.html
Related: OS#3598
Change-Id: Ia57ba101627e3cc0babeca82631e207a3e2e0960
Do not use C++11 extended initializers to prevent the following error.
AppInfoTest.cpp:109:54: error: extended initializer lists only available with -std=c++11 or -std=gnu++11
pcu_prim.u.app_info_req = {0, 15, {0xff, 0x00, 0xff}};
I ran into this when modifying the gerrit build verification job to
build with docker (which still uses GCC-4.9).
Related: OS#4204
Change-Id: I307cd87af88e86804a90d6466e9cc3909bfe701f
This commit would also remove the option from config_write_pcu() since
it's automatically filled in by osmo_tdef, but there was actually a bug
because that param was never printed when saving the config...
Change-Id: Id8e70b0f44ef2f7e20ecdb3fd8ca93ae2a05b9a3
osmo-pcu code is really verbose, and since log lines printing start and
end of tests are sent to a different file, it's really difficult to
understand which test outputs what.
Change-Id: I3e887158e2c9585c360d44f12f995f55861170f2
Receive an Application Information Request from the BTS via PCU
interface. Construct a Packet Application Information message from it
(3GPP TS 44.060 11.2.47) and send it to all MS with active TBF.
The TTCN-3 test infrastructure to test this feature is not quite ready
yet, so I've added C unit tests instead.
Related: OS#4048
Change-Id: Ie35959f833f46bde5f2126314b6f96763f863b36
This will allow for configuration of some of the timers by the user,
and allow him to inspect current values being used.
It will be also useful for TTCN3 tests which may want to test some of
the timers without having to wait for lots of time.
Timers are splitted into 2 groups: BTS controlled ones and PCU controlled
ones. The BTS controlled ones are read-only by the user (hence no
"timer" VTY command is provided to change them).
TbfTest.err output changes due to timers being set up correctly as a
consequence of changes. Other application such as pcu_emu.cpp and
pcu_main.cpp had to previosuly set the initial values by hand (and did
so), but apparently TbfTest.c was missing that part, which is now fixed
for free.
Depends: libosmocore.git Id56a1226d724a374f04231df85fe5b49ffd2c43c
Change-Id: I5cfb9ef01706124be262d4536617b9edb4601dd5
Since [1], OsmoPCU already starts to retransmit downlink blocks before
the MS has had a chance to receive them and/or send the related
acknowledgement in uplink. Make this optional with the new VTY option
"no dl-tbf-preemptive-retransmission".
[1] e25b5b91f6 ("tbf: Only create dummy frames if necessary")
Related: OS#2408
Change-Id: Id08aed513d4033aa0d4324c6ce07cbb2852f2f92
Those namings my collide with usual osmocom "T" variable name associated
to a timer number, which will be added in following patches.
Change-Id: Ic2b5068a4882e4a043bf81496be30a378fdb9a09
Pau Espin
Harald Welte
Vadim Yanitskiy
Oliver Smith