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
This commit is contained in:
Harald Welte 2021-02-04 18:15:57 +01:00
parent 3d6188304b
commit 9c6d89bdd1
1 changed files with 10 additions and 1 deletions

View File

@ -207,7 +207,16 @@ private function fill_err_bucket(boolean has_error) runs on FR_Emulation_CT {
/* 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);