Change in titan.TestPorts.AF_PACKET[master]: FrameRelay_Emulation: Use Rx SeqNR == 0 to force link down

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/.

laforge gerrit-no-reply at lists.osmocom.org
Thu Feb 4 17:22:11 UTC 2021


laforge has submitted this change. ( https://gerrit.osmocom.org/c/titan.TestPorts.AF_PACKET/+/22705 )

Change subject: FrameRelay_Emulation: Use Rx SeqNR == 0 to force link down
......................................................................

FrameRelay_Emulation: Use Rx SeqNR == 0 to force link down

In quickly repeated test case executions we have the problem that
both the Q.933 LMI detection of link outage/interruption, as well as
the NS-ALIVE mechanism are too slow to detect the outage, and in fact
don't detect the outage.  This leads to inconsistent state on both
sides, with one side thinking NS-VCs are still ALIVE/UNBLOCKED, while
the other side considers them DEAD.

A Q.933 conforming transmittere would never send a sequece number of
zero, but always start from one.  This means we can use this as
a flag to force the peer to assume a "service affecting condition"
which will make it tell NS that the link went down, etc.

Related: OS#4974
Change-Id: I3e38ade112e11c86db906da9846a966cb33ac1bd
---
M src/FrameRelay_Emulation.ttcn
1 file changed, 10 insertions(+), 1 deletion(-)

Approvals:
  laforge: Looks good to me, approved; Verified



diff --git a/src/FrameRelay_Emulation.ttcn b/src/FrameRelay_Emulation.ttcn
index 90cfd73..fbca3bd 100644
--- a/src/FrameRelay_Emulation.ttcn
+++ b/src/FrameRelay_Emulation.ttcn
@@ -207,7 +207,16 @@
 
 /* handle incoming Link Integrity Verification IE */
 private function q933_handle_rx_link_int(Q933_LinkIntegrityIE link_int) runs on FR_Emulation_CT {
-	if (q933em.tx_seq_nr != link_int.recv_seq_nr) {
+	if (link_int.recv_seq_nr == 0) {
+		/* The value '0' shall never be sent by a standards-conforming implementation,
+		 * See Q.933 section A.4.2 (NOTE).  In Osmocom we use it as "magic" value to
+		 * artificially indicate a 'service affecting condition' */
+		q933em.service_affecting_condition := true;
+		log("Detecting service affecting condition after zero receive sequence number");
+		notify_all_clients(FRemu_Event:{link_status:=FR_LINK_STS_UNAVAILABLE});
+		q933em.num_cycles := 0;
+		T392.stop;
+	} else if (q933em.tx_seq_nr != link_int.recv_seq_nr) {
 		log("Link Integrity IE with discontiguous sequence numbers: expected=",
 		    q933em.tx_seq_nr, " received=", link_int.recv_seq_nr);
 		fill_err_bucket(true);

-- 
To view, visit https://gerrit.osmocom.org/c/titan.TestPorts.AF_PACKET/+/22705
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: titan.TestPorts.AF_PACKET
Gerrit-Branch: master
Gerrit-Change-Id: I3e38ade112e11c86db906da9846a966cb33ac1bd
Gerrit-Change-Number: 22705
Gerrit-PatchSet: 1
Gerrit-Owner: laforge <laforge at osmocom.org>
Gerrit-Reviewer: laforge <laforge at osmocom.org>
Gerrit-MessageType: merged
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20210204/c6300ad2/attachment.htm>


More information about the gerrit-log mailing list