Bug #2901
closedOsmoBSC paging doesn't stop after RSL disconnect or even OML re-connect
0%
Description
When we start the paging procedure/timers on a given BTS, it doesn't seem to stop even when RSL disconects. This leads to messages like
Wed Jan 31 15:55:57 2018 DLINP <0013> e1_input.c:235 abis_sendmsg: msg->dst == NULL: 0c 15 01 90 0e 02 0c 08 09 10 10 00 00 00 00 21 28 00
and it also means that as soon as a RSL connection is re-established, the paging continues. Before we even have sent the BCCH FILLING or the SACCH FILLING, and also before OML handshake is even complete.
Not serious, but I could imagine some BTSs might get distracted this way...
An OML state machine could solve the problem if it would simply block all RSL messages until the respective TRX is in operational state.
Updated by laforge about 6 years ago
- Assignee set to 4368
Update: This can be reproduced using the BSC_Tests testsuite and the paging related tests, where the tests terminate before the paging timer expires or is answered to. So this also has the potential to cause flaky test results, as it leaks state from one test case to another, in an unintended way.
Updated by stsp almost 6 years ago
Related patches, one of which (7880) should address the problem:
https://gerrit.osmocom.org/#/c/7877/
https://gerrit.osmocom.org/#/c/7880/
https://gerrit.osmocom.org/#/c/7881/
Note that when the OML link is dropped, all RSL links are dropped as well
which means that the 7880 patch also works for OML.
Updated by stsp almost 6 years ago
Log messages with above patches:
<0013> bts_ipaccess_nanobts.c:361 (bts=2,trx=0) Dropping RSL link. <0015> bsc_init.c:410 Lost some E1 TEI link: 2 0x7f7a7a33c070 <0006> paging.c:457 (bts=2) Stop paging IMSI:001010000000010 (flush) <0013> input/ipaccess.c:247 Sign link vanished, dead socket
Without the patches, paging continues and results in the errors shown in the description of this issue.
Updated by stsp almost 6 years ago
This issue is now fixed for ipaccess BTS types.
Do we need a similar fix for other types of BTS? If so, which ones?
Updated by laforge almost 6 years ago
On Wed, May 02, 2018 at 10:09:48AM +0000, stsp [REDMINE] wrote:
Do we need a similar fix for other types of BTS? If so, which ones?
I think IP based BTS is sufficient for now.
Updated by stsp almost 6 years ago
- Status changed from In Progress to Resolved
Alright, closing this issue then.
Please re-open this issue, or create a new issue, if an implementation for another BTS type turns out to be needed after all.