Bug #6191
closedosmo-pcu from OBS latest feeds transmits Dummy blocks a few more FNs after last TBF in TS was freed
100%
Description
After new release 1.3.0/1.3.1, it was spotted that the following tests pass in ttcn3-pcu-test (nightly) but not in ttcn3-pcu-test-latest (running1.3.1).
TC_n3105_max_t3195 TC_pcuif_suspend_active_tbf TC_pdch_energy_saving TC_ta_ptcch_idle TC_ul_tbf_reestablish_with_pkt_resource_req_t3168
I can reproduce this locally using the docker setup with TC_n3105_max_t3195. Using default IMAGE_SUFFIX=master, the test passes. However, using IMAGE_SUFFIX=latest, the test fails.
This is strange since current master has no real big changes over latest release 1.3.1, only a commit modifying a bit a log message.
In fact, I tried running with IMAGE_SUFFIX=master and OSMO_PCU_BRANCH pointing to commit in 1.3.1, and then it passes too. So that means it has something to do with how osmo-pcu binary in the OBS package was built.
I attach a successful pcap and a failing pcap as reference.
Among other thing, the test expects that after T_3195 times out it should receive an empty dl data block from the PCU because there's no more TBFs active in that TS. This seems to work as expected when running against master or 1.3.1 compiled by the docket container, as seen in the good pcap. After the last DUMMY dl block is sent, one can see how the MS and TBF is freed and hence no more DUMMY dl blocks are sent.
However, when running against the package from OBS ("latest"), one can see that after the TBF and MS is freed, the PCU still submits DUMMY DL DATA blocks for a few (3-4) more FN rounds, which is wrong.
The following patch was submitted in the ttcn3 test to more clearly show the problem:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/34536 pcu: Fail immediately in TC_n3105_max_t3195
So all in all, it looks like:
1- Bug in the compiler used in OBS
2- Some bug of ours only appeareing when compiled against specific compile flags or compiler version
The logic on whether to submit a DL Dummy block or an empty one, is done in osmo-pcu at gprs_rlcmac_rcv_rts_block():
/* Prio 3: send dummy control message if need to poll or USF */
else {
/* If there's no TBF attached to this PDCH, we can submit an empty
* data_req since there's nothing to transmit nor to poll/USF. This
* way we help BTS energy saving (on TRX!=C0) by sending nothing
* instead of a dummy block. The early return is done here and
* not at the start of the function because the condition below
* (num_tbfs==0) may not be enough, because temporary dummy TBFs
* created to send Imm Ass Rej (see handle_tbf_reject()) don't
* have a TFI assigned and hence are not attached to the PDCH
* TS, so they don't show up in the count below.
*/
const unsigned num_tbfs = pdch->num_tbfs(GPRS_RLCMAC_DL_TBF)
+ pdch->num_tbfs(GPRS_RLCMAC_UL_TBF);
bool skip_idle = (num_tbfs == 0);
#ifdef ENABLE_DIRECT_PHY
/* In DIRECT_PHY mode we want to always submit something to L1 in
* TRX0, since BTS is not preparing dummy bursts on idle TS for us */
skip_idle = skip_idle && trx != 0;
#endif
if (!skip_idle && (msg = sched_dummy())) {
/* increase counter */
gsmtap_cat = PCU_GSMTAP_C_DL_DUMMY;
} else {
msg = NULL; /* submit empty frame */
}
}
In theory ENABLE_DIRECT_PHY should not be enabled in the OBS build, so in summary, the dummy message should only be generated based on:
const unsigned num_tbfs = pdch->num_tbfs(GPRS_RLCMAC_DL_TBF)
+ pdch->num_tbfs(GPRS_RLCMAC_UL_TBF);
bool skip_idle = (num_tbfs == 0);
if (!skip_idle)
msg = sched_dummy()
Files
