Description: 188.8.131.52 ns sequence error
Missing second REJ
This looks like an actual bug in our libosmocore.git LAPDm implementation
The roundtrip delay for a LAPD link must be less than T200.
Osmocom-bb runs LAPDm on the host machine via serial interface and USB interface that may cause a roundtrip delay that exceeds T200. Also osmo-bts may have that problem, due to latency between physical interface and osmo-bts software.
What may happen:
An I frame gets lost.
The sending side transmits the next I frame. The receiving side detects the send-sequence error and responds with a REJ frame.
Due to the round trip delay, the T200 expires on the sending side and causes the I frame to be retransmitted with the P bit set, it enters the timer recovery state. The receiving side detects the send-sequence error and responds with a REJ frame with the F bit set.
The sending side will then receive two REJ frames. The first REJ frame will clear the timer recovery state. The second REJ frame (with F bit set) is received when not in timer recovery state, causing an MDL-ERROR-INDICATION.
The layer 2 connection is broken.
Early tests with osmocom-bb in a real network showed exactly this problem.
The solution is to suppress every second REJ frame at the receiving side, until the sequence error condition is cleared. If the first REJ frame gets lost, the sending side would retransmit the I frame again after another expiry of T200. Then the receiving side would respond with a REJ frame again.
The solution for the TTCN3 test case is to resend the I frame twice and then expect the REJ response.
- % Done changed from 0 to 90
Resolved by patches in libosmocore. A flag added to suppress subsequent REJ frame when using serial link. This flag is set only by osmocom-bb. For osmo-bts the flag is not required. This test passes with the patches. Patches applied to Gerrit.