Changes
Started by upstream project gerrit-osmo-s1gw #636
Started 2 hr 5 min ago
Queued 8.2 sec
Took 1 min 51 sec
on built-in
enb_proxy: fix stale SCTP events misprocessed during MME pool selection
When closing a connection to one MME and opening a new one to the next,
a SHUTDOWN_COMP event from the old (now-closed) socket can still be
pending in the process mailbox. The sctp_assoc_change handlers in the
'connecting' and 'wait_s1setup_rsp' states were matching '_Socket',
ignoring the socket identity. A stale SHUTDOWN_COMP would therefore
fall into the '_ -> repeat_state_and_data' branch, triggering a spurious
re-entry of 'connecting', which immediately closed the newly established
connection to the next MME and skipped to yet another pool entry.
Fix this by matching the Socket against the current S#state.sock in both
handlers. Events arriving on a previously closed socket no longer match
these clauses and are silently dropped by the catch-all handle_event/4.
This was found thanks to the MME pooling TCs in ttcn3-s1gw-test.
Change-Id: I4211dd343607f045cf4dd33fa568ed580c79dd9f
Related: SYS#7052
When closing a connection to one MME and opening a new one to the next,
a SHUTDOWN_COMP event from the old (now-closed) socket can still be
pending in the process mailbox. The sctp_assoc_change handlers in the
'connecting' and 'wait_s1setup_rsp' states were matching '_Socket',
ignoring the socket identity. A stale SHUTDOWN_COMP would therefore
fall into the '_ -> repeat_state_and_data' branch, triggering a spurious
re-entry of 'connecting', which immediately closed the newly established
connection to the next MME and skipped to yet another pool entry.
Fix this by matching the Socket against the current S#state.sock in both
handlers. Events arriving on a previously closed socket no longer match
these clauses and are silently dropped by the catch-all handle_event/4.
This was found thanks to the MME pooling TCs in ttcn3-s1gw-test.
Change-Id: I4211dd343607f045cf4dd33fa568ed580c79dd9f
Related: SYS#7052