Test test_ul_tbf_t3166_timeout needs to be modified in order to avoid
triggering T3180 once it is implemented in a follow-up patch.
Both T3180 and T3166 are armed at the same time, so modify the scenario
to really scenify the case where T3166 matters: the MS keeps receiving USF
indications but the PCU doesn't see them and hence never sends a PKT UL
ACK/NACK.
Related: OS#6209
Change-Id: Ib84ccfd89773913703e0ab3e09d0ce9eb123e994
Test test_ul_tbf_t3182_timeout needs to be modified in order to avoid
triggering T3180 once it is implemented in a follow-up patch.
Both T3180 and T3182 are armed at the same time, so modify the scenario
to really scenify the case where T3182 matters: the MS keeps receiving USF
indications but the PCU doesn't see them and hence never sends a PKT UL
ACK/NACK acking the last block.
Related: OS#6209
Change-Id: I73b648bc04d863b9eb67093e5fa510ba88d712c8
Re-arming upon retransmission of block CV=0 is only described in the
unacknowledged mode of operation.
Change-Id: I532def7f87367b446b5370daf8c81f511e26eb5f
The restriction to only to transmit last data block (CV=0) up to 4 times
only applies in Unacknowledged mode of operation, which we don't
support. Hence, simply comment it out so that it can be enabled if
unacknowledge mode is ever supported.
Related: OS#6208
Change-Id: Ie7cdb286b9c7255e3fbf9f936f103fab04acf96a
The previous logic was wrongly written. We want:
* If PKT UL ASS didn't have a tbf_starting_time but had an S/P+RRBP,
it means we have to delay completing the FSM until we send the PKT CTRL ACK (next_blk)
* If it contained tbf_starting_time, if it happens before next_blk, still wait until next_blk
Change-Id: I60cdc0315e28f71843c51eba88acc78780c6ab43
The FSM can be reused several times to assign a UL TBF over its
lifespan, eg. if a DL TBF DL ACK/NACK is reuse to request allocation of
a UL TBF several times.
Some state like ctx->tbf_starting_time_exists was being left as =true
during the initial run of the FSM, and as a result subsequent runs going
through the check delaying completing after sending the PKT CTRL ACK.
Change-Id: Iaddbd1e3924036be1cf6eed41367031d3e127f57
Fixes following warning detected by clang:
"""
tbf_ul.c:1118:37: warning: implicit conversion from enumeration type
'enum gprs_rlcmac_rlc_egprs_ul_reseg_bsn_state' to different enumeration type
'enum gprs_rlcmac_rlc_egprs_dl_reseg_bsn_state' [-Wenum-conversion]
blk->spb_status.block_status_dl = reseg_status;
"""
In practice it's not much of a problem since both fields are put
together in a union, so it ends up in the same place in memory.
Change-Id: Iccd57b74640754f2aebf81a149a633f141c6e38f
The RA value does change during RACH retransmissions, so we cannot
expect a specific value in gprs_rlcmac_handle_ccch_imm_ass_ul_tbf()
anymore. Offload checking it to the lower layers.
* Rename submit_rach_req() to submit_packet_access_req().
* Get rid of gen_chan_req(), indicate only the access cause.
Ideally, we should also rename the OSMO_GPRS_RLCMAC_L1CTL_RACH
to something like OSMO_GPRS_RLCMAC_L1CTL_PKT_CHAN_ACCESS, but
let's better do this separately.
Change-Id: If0de3ed86b1e2897d70183f3b0f4fbfd7d2bda80
Related: osmocom-bb.git Iab6d9147f6e0aeb99239affacf318a3897fd6ffe
Related: OS#5500, OS#6131
This also fixes a memcpy writing out of bounds reported by Coverity
CID#323120 in gprs_rlcmac_tbf_ul_ass_start_from_dl_tbf_ack_nack(), due
to the difference of size between struct gprs_rlcmac_ul_tbf_allocation
and struct gprs_rlcmac_dl_tbf_allocation.
While fixing it, actually properly implement passing of the 1 only
interesting TS to the tbf_ul_ass_fsm at that point in time.
Change-Id: I89b15982b73f00599183981142495d7b9befbb78
Some solutions are not meant to be final ones, but some small
workarounds to have the whole thing running until the lower layers are
fixed/improved.
Related: OS#5500
Change-Id: I94bd0de6917b004cba73d2fffc7cf69b3b5c305d
[this fix already exists in most of the other repos]
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: I577e7d7b07acf76e5d97dcce5da206d10f5e2aeb
This is unfortunately not yet working since lower layers are always
sending hardcoded fn=0 and hence ctx->tbf_starting_time calculated in
handle_imm_ass()->TBF_StartingTime_to_fn() is wrong.
Related: OS#6130
Change-Id: If6b7766ee1ba6667db4e54e897f376f5b27ad73d
This code part will also be used by tbf_ul_ass_fsm.c to temporarily
configure lower layers with ctx->phase1_alloc in order to receive RTS
indications which the RLC/MAC uses to tick the FSM in state
GPRS_RLCMAC_TBF_UL_ASS_ST_WAIT_TBF_STARTING_TIME1.
Change-Id: I174327b25b726662a6b5902008e205ddb3de2fe0
The Starting time contains a "frame number, FN modulo 42432", aka RFN.
The translation to absolute FN was missing.
Depends: libosmocore.git Change-Id Ib71e8da976f6cc84c3a4ab17b0a8c2101492e243
Change-Id: I00741289333853a8db472950ee2ac38dc2c74fd3
This is needed after RAU Update since the PCU may still be using the old
TLLI to reference the MS for a while until it finds out about the TLLI update.
Change-Id: I2653db3dac58342df02a1b4d0c76e69e0e8d583f
This enum should match osmo_gprs_gmm_gmmrr_prim_type, and I placed that
osmocom-specific enum at the wrong place in the rlcmac counterpart.
Change-Id: I3f198c756866417f8f975373f84fd3ec4da608fa
The "Radio Priority" received in GMM Attach Accept are for SMS and TOM8
SAPs only. For GMM/SM unitdata transferred to LLC, use highest
radio_prio=1.
Change-Id: Ie583c433547fb5ecbb6b6077c39a157961f73cfc
This simplifies the array handling in the LLC queue, and moves param
checking to the rx rlcmac_prim path instead of deep in the llc_queue
enqueuing code.
This commit also fixes the RADIO_PRIORITY field in the Channel Request
Description section of PKT DL ACK/NCK, since
gprs_rlcmac_llc_queue_highest_radio_prio_pending() now returns the enum
normalized 0..3 as expected by the field format (before it was returning
1..4).
Change-Id: If2d1946522bc4a1c19d65acb23605f1a3f05ab45
Ported from open5gs.git/lib/gtp/v1/types.{c,h} 5764f7267d16a8ea6aeedc6c227552575915def5,
for which I was the author too.
The ARP extra byte field at the start of the IE val which is introduced in the
GTP variant is dropped when porting to SM, since it's not present there
(and offsets/sizes are adjusted).
The QoS code is moved is moved into a common/ directory where a new
libosmo-gprs-common.la private static library is created.
This is done in order to be able to resuse the QoS dec/enc code in
several libraries since it's actually planned to use it in SNDCP and SM
layers.
The most natural place to add the APIs is SM, and that's where the
public API to accees the enc/dec is provided, since the user app will
have to use them in the SM SAP.
However, the SNDCP will also have to decode the QoS recived by SM
through the SNSM SAP, and we don't really want libosmo-gprs-sndcp depend
on libosmo-gprs-sm. This way libosmo-gprs-sndcp will be able to use the
private APIs directly in a follow-up commit.
Change-Id: I6c0676e55bb1f0f424f41d8d04d4f5e5bf376f4f
LLC is only expected to signal new values if SNDCP XID params are
received, or if the default N201 values change.
Change-Id: I68f54d329b326895ed8f010cf50f20fa30948d30
Getting out of contention resolution means we may have to update our
calculated CV state because we are no longer sending TLLI.
Same happens if a new tx CS is provided by the network, since different
block size means different CV.
In this commit only code paths for the state where already in Countdown
Procedure are added. If TBF has to enter Countdown Procedure due the
above mentioned changes, it will do so using regular path where a new
RLC block is created.
Related specs: TS 44.060 9.3.1
Related: OS#6018
Change-Id: I6ca88c005060ba1302d46717e45b0d9731d86d8d
Recalculating CV when in Countdown Procedure will be implemented in a
follow-up commit.
Related: OS#6108
Change-Id: I1e7b28c2e5f1d77a962ec3070f3a027b8f66a69e