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