aboutsummaryrefslogtreecommitdiffstats
path: root/openbsc/src/libbsc/bts_unknown.c
diff options
context:
space:
mode:
authorHolger Hans Peter Freyther <holger@moiji-mobile.com>2014-04-19 16:45:36 +0200
committerHolger Hans Peter Freyther <holger@moiji-mobile.com>2014-06-03 12:51:16 +0200
commit1e93b79cce4702fb79fa4fe8990a1bbcdb97b4f0 (patch)
tree0c7bcf0f46855b55de233b29f2f845cda8d6ca6a /openbsc/src/libbsc/bts_unknown.c
parentf0405068d8e53ecd6126af04e1c96155dce80e82 (diff)
rsl: Avoid double channel release procedure in error conditions
When we receive an ERROR INDICATION and CONNECTION FAILURE we might call rsl_rf_chan_release multiple times. The channel release handling is still a bit messy and there too many paths that lead to the call. 1.) In case we receive an ERROR INDICATION for SAPI=3. A RLL error signal will be emitted that leads to the release of the channel through the SMS code in case of the NITB. The call to rsl_rf_chan_release might be a double release. 2.) In case a CONNECTION FAILURE is received when the release process has already been started we would unconditionally call rsl_rf_chan_release as well. Because the lchan state is changed by the callers of the rsl_rf_chan_release we can not move the state checking into this code but need to do it in the caller. The issue was seen in a trace from Rhizomatica and I created the DoubleRelease.st to re-produce the issue and verified that we have no duplicate RF Channel Releses. The other option would be to introduce a new state to track the release process and see if we have already released SAPIs deactivated the SACCH or such. We can not simply look at these as for a channel that fails to activate they will be null already.
Diffstat (limited to 'openbsc/src/libbsc/bts_unknown.c')
0 files changed, 0 insertions, 0 deletions