Change in osmocom-bb[master]: trxcon/scheduler: check TDMA frame order, drop out of order bursts

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.

fixeria gerrit-no-reply at lists.osmocom.org
Wed Jul 8 23:08:18 UTC 2020


fixeria has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmocom-bb/+/19201 )


Change subject: trxcon/scheduler: check TDMA frame order, drop out of order bursts
......................................................................

trxcon/scheduler: check TDMA frame order, drop out of order bursts

When running together with fake_trx.py (mostly used back-end), it
is currently possible that Downlink bursts are received in a wrong
order if more than one transceiver is configured (multi-trx mode).

This is how it looks like:

  20200708201455837 DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=629 rssi=-86 toa=0
  20200708201455837 DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=629 ts=3 bid=1
  20200708201455841 DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=630 rssi=-86 toa=0
  20200708201455841 DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=630 ts=3 bid=2
  20200708201455846 DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=631 rssi=-86 toa=0
  20200708201455846 DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=631 ts=3 bid=3

  20200708201455846 DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=633 (!) rssi=-86 toa=0
  20200708201455846 DSCHD NOTICE sched_trx.c:663 Substituting (!) lost TDMA frame 632 on TCH/F
  20200708201455846 DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=632 ts=3 bid=0
  20200708201455846 DSCHD DEBUG sched_lchan_tchf.c:60 Traffic received on TCH/F: fn=633 ts=3 bid=1

  20200708201455849 DTRXD DEBUG trx_if.c:612 RX burst tn=3 fn=632 (!) rssi=-86 toa=0
  20200708201455849 DTRXD NOTICE sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647)
                                                 since the last processed fn=633 (current fn=632)

so here a burst with TDMA fn=633 was received earlier than a burst
with TDMA fn=632.  The burst loss detection logic considered the
latter one as lost, and substituted it with a dummy burst.  When
finally the out-of-order burst with TDMA fn=632 was received, we
got the large number of allegedly elapsed frames:

  ((632 + 2715648) - 633) % 2715648 == 2715647

Given that late bursts get substituted, the best thing we can do
is to reject them and log an error.  Passing them the the logical
channel handler (again) might lead to undefined behaviour.

Change-Id: I873c8555ea2ca190b1689227bb0fdcba87188772
Related: OS#4658, OS#4546
---
M src/host/trxcon/sched_trx.c
1 file changed, 10 insertions(+), 0 deletions(-)



  git pull ssh://gerrit.osmocom.org:29418/osmocom-bb refs/changes/01/19201/1

diff --git a/src/host/trxcon/sched_trx.c b/src/host/trxcon/sched_trx.c
index 9195b33..6b872cd 100644
--- a/src/host/trxcon/sched_trx.c
+++ b/src/host/trxcon/sched_trx.c
@@ -719,6 +719,16 @@
 	if (!lchan->active)
 		return 0;
 
+	/* Check TDMA frame order (a race condition is possible with fake_trx.py, see OS#4658) */
+	if (fn < lchan->tdma.last_proc) {
+		/* This burst has already been substituted by a dummy burst (all bits set to zero),
+		 * so better drop it. Otherwise we risk to get undefined behavior in handler(). */
+		LOGP(DSCHD, LOGL_ERROR, "(%s on TS %u) Rx burst with fn=%u older "
+					"than the last processed fn=%u => dropping...\n",
+		     trx_lchan_desc[lchan->type].name, tn, fn, lchan->tdma.last_proc);
+		return -EALREADY;
+	}
+
 	/* Compensate lost TDMA frames (if any) */
 	subst_frame_loss(lchan, handler, fn);
 

-- 
To view, visit https://gerrit.osmocom.org/c/osmocom-bb/+/19201
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmocom-bb
Gerrit-Branch: master
Gerrit-Change-Id: I873c8555ea2ca190b1689227bb0fdcba87188772
Gerrit-Change-Number: 19201
Gerrit-PatchSet: 1
Gerrit-Owner: fixeria <vyanitskiy at sysmocom.de>
Gerrit-MessageType: newchange
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200708/fc6c90da/attachment.htm>


More information about the gerrit-log mailing list