Problems during initial bring-up of nanoBTS

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

Harald Welte laforge at gnumonks.org
Sun Jun 19 09:03:53 UTC 2011


Hi zecke and others,

I may have found a cause of one of the problems that we've been
experiencing in nanoBTS bring-up, at least at some point in the past.

The problem could be observed/described as:  During the first OML
connect of the nanoBTS, OpenBSC fails to bring it up completely.  Second
and successive connects worked fine.

What I have just noticed is that we never re-set the NM state
information for the 12.21 MOs inside OpenBSC.  This means, if the A-bis
link is lost, the old state information continues to exist.

I guess it would be cleaner to simply re-set all the nm_state strucures
that are part of the 'struct gsm_bts', gsm_bts_trx, etc. when the A-bis
link is lost.

As I'm working in this area right now anyway, I intend to produce a
patch addressing the issue.

But now that I think more about it:  I guess it is unrelated to the old
problem, as a typical work-around was to re-start OpenBSC, at which time
all state is re-set again.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)




More information about the OpenBSC mailing list