This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Sipos Csaba dchardware at gmail.comHey Holger, After placing some markers into the code, I have found the part which is responsible for proper close of the OML connection: lapd_sap_stop(ts->lapd, link->tei, link->sapi); which is called properly by the Nokia related code, after the ACK got received for the RESET_REQ. The lapd connection closes as it should: Fri Aug 2 01:10:16 2013 <0018> input/lapd.c:513 LAPD DL-RELEASE request TEI=1 SAPI=62 Fri Aug 2 01:10:16 2013 <0018> lapd_core.c:2183 Message DL-RELEASE-REQUEST received in state LAPD_STATE_MF_EST Fri Aug 2 01:10:16 2013 <0018> lapd_core.c:2024 perform local release Fri Aug 2 01:10:16 2013 <0018> lapd_core.c:229 new state LAPD_STATE_MF_EST -> LAPD_STATE_IDLE Fri Aug 2 01:10:16 2013 <0018> lapd_core.c:222 stop T203 Fri Aug 2 01:10:16 2013 <0018> input/lapd.c:628 LAPD DL-RELEASE confirm TEI=1 SAPI=62 Now OML lapd connection is closed, but for some unkown reason lapd_core.c still try to process the received lapd messages for an already closed connection, which causes the segfault: Fri Aug 2 01:10:16 2013 <0018> lapd_core.c:1781 lapd_send_i() called from line 1615 Segmentation fault (core dumped) And this is not because the Nokia related code tries to send something when the lapd connection is closed. From the above log, it is clear that the LAPD connection got terminated as it should, so it seems this is a problem with lapd_core.c in general, that for an already closed connection, if something got received on the OML timeslot, lapd_core.c tries to process it. And this behavior leads to the segfault. This is normal, that lapd_core.c tries to process data related to an already closed connection? BR, Csaba