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.comHi Holger
I've made some progress with the segfault problem regarding Nokia and
patch: f5a079f739c57d8be7c59149fd45475c402a45fc
It seems if I use "nokia_site skip-reset 1" in the config file, the
problem is gone. I am pretty sure after these months, that the problem
about the LAPD errors, this segfault problem and the multi-BTS problem
is somewhere around the code that is responsible for this reset
sequence, because if I turn it off, all problems are gone.
Maybe the cause is that the code is not multi-BTS aware (the reset
part). For
example it sends the RESET code for one BTS (despite the first one
got acked properly), but it wont send the RESET code to the other BTS.
Another thing is that after the RESET code sent to a particular BTS
(and recieved an ack), all LAPD connections should be disconnected and
keep it that way, till the RESET_TIMER expires (because NOkia BTS
sends garbage on the E1 during reset), then try the
bootstrapping again. And this is what actually happens:
1. OpenBSC sends BTS_RESET
2. OpenBSC receives ACK.
3. OpenBSC closes the LAPD connections as it should.
4. But somehow the LAPD connection got restarted during the reset
period (some data received from the BTS, there is a lot of
unimplemented TRAU warnings because the data is garbage).
The problem is that if I have to change some parameters, I have no choice
but to use the NOkia reset code, otherwise the parameters are not
going to be change in the BTS (despite the successful bootstrapping of
OML and RSL).
Otherwise the code seems to handle multi Nokia BTSes well. It seems
that the solution is somewhere in the code responsible for the reset
part.
I hope I can get some help from someone who understands the code
better. Once again, I am happy to do whatever it takes to sort this
out.
BR,
Csaba
> On Sun, Jun 30, 2013 at 12:00:06PM +0200, Sipos Csaba wrote:
>> Thanks Holger,
> Good Afternoon,
>> <0018> input/lapd.c:628 LAPD DL-RELEASE confirm TEI=1 SAPI=62
> this releases the LAPD structures.. (and now sets dl->tx_hist to NULL)
>> #0 0xb774c11d in lapd_send_i (line=1606, lctx=<optimized out>) at lapd_core.c:1802
>> 1802 if (!dl->tx_hist[h].msg) {
> and it is accessed even after it has been released. Now I don't know
> if this access would be legetimate but it is from 'dead' memory.
> Could you please create a PCAP file of the communication on the line?
> NITB has a config param for that and it should work for LAPD.