Osmo-nitb v_0.13.0.48-9e22 broke compatibility with Nokia InSite

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.com
Sun Jul 28 21:39:05 UTC 2013


Hey Holger,

Thanks for the help. I am a little new in debugging so it might take a
while, till I find out why the LAPD connection got reopened after
OpenBSC receives the ack for the Nokia reset_req.

Until we can figure it out what is the problem, there is a temporary
solution.

With "nokia_site skip-reset 1" in the config file and with the
following modification in bts_nokia_site.c:

static int shutdown_om(struct gsm_bts *bts)
{
        /* TODO !? */
        LOGP(DNM, LOGL_NOTICE, "Sending Nokia RESET_REQ before
        shutdown\n");
        abis_nm_reset(bts, 1);
        return 0;
}

now the reset takes place not during the initialization, but during
the shutdown. The result is the same: on the next OpenBSC run all
Nokia BTS will be in a "clean restarted" state already, so despite the
"skip-reset 1" both the OML and the RSL can be bootstrapped properly.

This is not a final solution for sure, there is no exception handling,
it doesn't wait for ACK or anything, but at least it seems it is
working for now, and there is no LAPD errors and segfault failures
neither, even with the "problematic" patch applied.

Will test this in 1-2 days, and report back with the results.

BR,
Csaba

> On Sun, Jul 28, 2013 at 05:34:57PM +0200, Sipos Csaba wrote:
>> Hi Holger
>> 
>> I've made some progress with the segfault problem regarding Nokia and
>> patch: f5a079f739c57d8be7c59149fd45475c402a45fc

> Hi,

> I can only provide you with debug aid.

>> 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.


> * the reset will lead to LDAP release..
> * some one is using the released link..


> debug:

> * Set a breakpoint in the code that is relreasing the hist buff
> * Once it is hit set a watchpoint on the memory regions...
> * Figure out who is accessing it first..
> * Then try to figure out if that is correct or not
>  ** E.g. do we need to flush a queue>





More information about the OpenBSC mailing list