diff options
author | Holger Hans Peter Freyther <holger@moiji-mobile.com> | 2014-04-19 16:45:36 +0200 |
---|---|---|
committer | Holger Hans Peter Freyther <holger@moiji-mobile.com> | 2014-06-03 12:51:16 +0200 |
commit | 1e93b79cce4702fb79fa4fe8990a1bbcdb97b4f0 (patch) | |
tree | 0c7bcf0f46855b55de233b29f2f845cda8d6ca6a /openbsc/src/libbsc/bts_unknown.c | |
parent | f0405068d8e53ecd6126af04e1c96155dce80e82 (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