OML issue?

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

Holger Hans Peter Freyther holger at freyther.de
Mon Jul 18 10:12:26 UTC 2011


On 07/18/2011 11:00 AM, Holger Hans Peter Freyther wrote:
> On 07/16/2011 09:08 PM, Holger Hans Peter Freyther wrote:
>> On 07/16/2011 05:19 PM, Harald Welte wrote:
>>
> 
> 
> I am debugging this now, what also jumped into my eye is that the
> administrative is set. This will e.g. change the setting of the TRX lock.

Hi Harald,
and actually the above was the problem. In bts_ipaccess_nanobts:sw_activ_rep
we will use the administrative state of the TRX (rc_state variable) and issue
a change_adm_state, with NM_OPSTATE_NULL as rc_state we will get a NACK.

Now my understanding might be wrong but I think the administrative state is
something we want to 'maintain' from the BSC. So I think the administrative
state should survive a BTS disconnect.

In theory there is one way this could still fail, in the administrative ACK
code path we will set the administrative state to the one returned by the BTS,
we probably want to compare the result and then send a signal if setting the
admin state didn't result in what we asked for.

My proposed patch will call gsm_bts_mo_reset from within bts_bootstrap and
removes setting the administrative state.

what do you think?
	holger


More information about the OpenBSC mailing list