Re: Osmo-nitb v_0.13.0.48-9e22 broke compatibility with Nokia - OpenBSC

2 Aug 2013

Hi Peter,

...
  Ok. Do you have a later message from the following
line? 
...
  LOGP(DLLAPD, LOGL_INFO, "I received in state
%s\n", lapd_state_names[dl->state]); 
Sure, this is how it looks with all relevant debugging enabled:

Fri Aug  2 16:50:13 2013 <0018> lapd_core.c:1465 I received in state
LAPD_STATE_MF_EST
Fri Aug  2 16:50:13 2013 <0018> lapd_core.c:1548 incrementing V(R) to 1
Fri Aug  2 16:50:13 2013 <0018> lapd_core.c:222 stop T203
Fri Aug  2 16:50:13 2013 <0018> lapd_core.c:206 start T203
Fri Aug  2 16:50:13 2013 <0018> lapd_core.c:1557 message in single I frame
Fri Aug  2 16:50:13 2013 <001b> e1_input.c:594 RX: 80 80 00 08 81 00 00 01 5f 23 01
01  sapi=62 tei=1
Fri Aug  2 16:50:13 2013 <0005> bts_nokia_site.c:1668 Nokia: Abis received!
Fri Aug  2 16:50:13 2013 <0005> bts_nokia_site.c:1688 ABIS_OM_MDISC_FOM
Fri Aug  2 16:50:13 2013 <0005> bts_nokia_site.c:1515 (0x81) NOKIA_BTS_ACK
Fri Aug  2 16:50:13 2013 <0005> bts_nokia_site.c:1547 ACK = 1
Fri Aug  2 16:50:13 2013 <0005> bts_nokia_site.c:1588 Nokia: STOP OML
& RSL lapd (cause: RESET)
Fri Aug  2 16:50:13 2013 <0018> input/lapd.c:513 LAPD DL-RELEASE request TEI=1
SAPI=62
Fri Aug  2 16:50:13 2013 <0018> lapd_core.c:2183 Message DL-RELEASE-REQUEST received
in state LAPD_STATE_MF_EST
Fri Aug  2 16:50:13 2013 <0018> lapd_core.c:2024 perform local release
Fri Aug  2 16:50:13 2013 <0018> lapd_core.c:229 new state LAPD_STATE_MF_EST ->
LAPD_STATE_IDLE
Fri Aug  2 16:50:13 2013 <0018> lapd_core.c:222 stop T203
Fri Aug  2 16:50:13 2013 <0018> input/lapd.c:628 LAPD DL-RELEASE confirm TEI=1
SAPI=62
Fri Aug  2 16:50:13 2013 <001b> e1_input.c:585 DL_REL: sapi(62) tei(1)
Fri Aug  2 16:50:13 2013 <001b> bsc_init.c:318 Lost some E1 TEI link: 1 0x887f038
Fri Aug  2 16:50:13 2013 <0018> lapd_core.c:1781 lapd_send_i() called from line
1615
Segmentation fault (core dumped)

bsc_init.c probably complaining because the LAPD connection is closed,
but the OML context does not. Maybe this is the root cause of the
problem: if the OML context not disconnected with the LAPD connection,
it still listens on the OML timeslot and if something got received, it
tries to process it. But still: this is not how it should work. The
OML context is not closed, because we are waiting for the already
resetting BTS, then the OML lapd got restarted again (after the
RESET_TIMER expired). My opinion is that after we closed the lapd
connection, it should not reactivate itself, if data appears on the OML
TS.

BR,
Csaba