This commit raises the LAPD RSL N200 (retransmission) counter for Nokia RSL links. The reason is that the readiness of the TRX is not signalled (OML) nor can be queried from the BTS in any way, and on larger macro setups the TRX reset takes ~15 seconds, thus the RSL bootstrap times out before the TRX becomes ready.
This issues presents itself with UltraSite types, does not affect InSite or MetroSite (the later two are "integrated TRX" units).
Runtime tested with InSite and UltraSite (multi-TRX).
Scenario: * A DYNAMIC/OSMOCOM TS in PDCH mode is selected to be used for TCH/F, hence the TS is being switched to TCH/F: RF Channel Release is being transmitted and waiting to receive RF Channel release ACK. Hence, lchan is in state LCHAN_ST_WAIT_TS_READY, and there's a conn with an assignment FSM pointing to it in conn->assignment.new_lchan. lchan->conn also points to the related conn. * The BSSMAP SCCP link goes down (link lost), which will terminate the conn->fi of all conns related to the MSC peer going down. During that teardown, first gscon_pre_term()->gscon_release_lchans()-> assignment_reset() is called, which sets conn->assignment.new_lchan=NULL and calls lchan_release(). This path leaves conn->assignment.new_lchan->conn untouched! * Later in the call path, when finally the bsc_subscr is put() to 0 references and associated lchan gets its lchan_forget_conn() called, it will access lchan->conn which was not freed in the previous step mentioned above during assignment_reset().
This patch fixes the issue by adding a lchan_forget_conn() after the lchan_release() in assignment_reset(), to make sure the conn is no longer user by the lchan afterwards.
Related: OS#6936 Change-Id: Ifbb9a61cd8a40d953ef5c2b52f9be9ef0dffefa4 (cherry picked from commit 44efd5b20b50ab894ed32ada3340fb5507b4852b)
Scenario: * A DYNAMIC/OSMOCOM TS in PDCH mode is selected to be used for TCH/F, hence the TS is being switched to TCH/F: RF Channel Release is being transmitted and waiting to receive RF Channel release ACK. Hence, lchan is in state LCHAN_ST_WAIT_TS_READY, and there's a conn with an assignment FSM pointing to it in conn->assignment.new_lchan. lchan->conn also points to the related conn. * The BSSMAP SCCP link goes down (link lost), which will terminate the conn->fi of all conns related to the MSC peer going down. During that teardown, first gscon_pre_term()->gscon_release_lchans()-> assignment_reset() is called, which sets conn->assignment.new_lchan=NULL and calls lchan_release(). This path leaves conn->assignment.new_lchan->conn untouched! * Later in the call path, when finally the bsc_subscr is put() to 0 references and associated lchan gets its lchan_forget_conn() called, it will access lchan->conn which was not freed in the previous step mentioned above during assignment_reset().
This patch fixes the issue by adding a lchan_forget_conn() after the lchan_release() in assignment_reset(), to make sure the conn is no longer user by the lchan afterwards.