commit e8ac8da62a8b207f40d3cd221a9a82b72cbd18dc
author Pau Espin Pedrol <pespin@sysmocom.de> Wed Mar 29 17:29:25 2023 +0200
committer laforge <laforge@osmocom.org> Tue Jun 20 07:17:52 2023 +0000
tree 2c23f88a9cc91320e5dc8c3b00bce3bc800ccc7a
parent dca3c906b0b9ba77f8475f40d5cb9f0cb9d32521

Fix DL_TBF PACCH ass done on UL_TBF already scheduled to tx last PKT CTRL ACK

Dispatching TBF_EV_CONTENTION_RESOLUTION_MS_SUCCESS means the UL TBF is
able to be used to assign DL TBFs over PACCH.
However, there's an extra implicit restriction: if the PCU already sent
the final UL ACK/NACK to that UL TBF, then whatever message sent
after it cannot be reliably answered, since the MS will go back to idle
state after issues the PKT CTRL ACK for that final UL ACK/NACK.
This condition is already being checked in
contention_resolution_success():

"""
	if (ms_need_dl_tbf(ms()) && !tbf_ul_ack_waiting_cnf_final_ack(this))
		ms_new_dl_tbf_assigned_on_pacch(ms(), this);
"""

Since we are considering the UL TBF to have done contention resolution
when we transmit the *first* UL ACK/NACK, it mans we are doing both things
on the same code path iif the *first* UL ACK/NACK is at the same time
the *final* UL ACK for that UL TBF. This can happen if the UL TBF is
only sending 1 block, which will have CV=0. This can usually happen
during GMM Attach Request.
In this scenario, with current code goes into a situation where first
the TBF_EV_CONTENTION_RESOLUTION_MS_SUCCESS is triggered and *afterwards*
the UL_ACK/NACK state is updated. As a result, the code snippet check
above (!tbf_ul_ack_waiting_cnf_final_ack()) will be true and the DL TBF
be assigned, but afterwards in the same code path it figures out the
final ack happens.

In order to fix this, first update the ACK/NACK state and only
afterwards trigger the Contention Resolution Success event.

Change-Id: I62ae91b494e4fd0ade3f4a3ba3817bcaedbdebf5