Avoid moving DL-TBF from old_msg to new_ms during ms_merge
The DL-TBF assigned to another MS object may have a totally different
set of reserved resources (TS set, TRX, etc.), so one cannot simply move
those to the new MS. To start with, if the 2 MS are on different TRX it
is clear that one of them will not be really in operation. That's most
probably the DL-TBF being in ASSIGN state on CCCH waiting for PCUIF_CNF
and later X2002 to trigger to start sending DL blocks, but without
confirmation whether the MS is really there. Since the other new MS
object probably has a UL-TBF, that's the one probably operative, and
hence a new DL-TBF can be created at that same time and assigned through
UL-TBF's PACCH.
Unit test test_ms_merge_dl_tbf_different_trx showcases the above
scenario.
Related: SYS#6231
Related: OS#5700
Related: 677bebbe5c49d4607322e96053fe14ddd78d9549
Change-Id: Ie8cb49d5492cfc4cbf8340f3f376b0e6105e8c82
diff --git a/src/tbf_dl_fsm.c b/src/tbf_dl_fsm.c
index 7d1f9b1..6b455da 100644
--- a/src/tbf_dl_fsm.c
+++ b/src/tbf_dl_fsm.c
@@ -163,7 +163,19 @@
* listening on PDCH) in order to move to FLOW state and start
* transmitting data to it. When X2002 triggers (see cb timer
* end of the file) it will send TBF_EV_ASSIGN_READY_CCCH back
- * to us here. */
+ * to us here.
+ */
+ if (!(ctx->state_flags & (1 << GPRS_RLCMAC_FLAG_CCCH))) {
+ /* This can happen if we initiated a CCCH DlAss from an
+ * older TBF object (same TLLI) towards BTS, and the DL-TBF
+ * was recreated and is now trying to be assigned throguh
+ * PACCH.
+ */
+ LOGPTBFDL(ctx->dl_tbf, LOGL_INFO,
+ "Ignoring event ASSIGN_PCUIF_CNF from BTS "
+ "(CCCH was not requested on current assignment)\n");
+ break;
+ }
fi->T = -2002;
val = osmo_tdef_get(the_pcu->T_defs, fi->T, OSMO_TDEF_MS, -1);
sec = val / 1000;