Hi all,
I have seen a strange OML NACK loop in OpenBSC with the ipaccess BTS. When I restart the osmo-nitb it is working again, so I suspect somehow our state of the BTS is corrupted.
any ideas holger
Do you get this error when starting osmo-nitb?
SET ATTR NACK CAUSE=Message cannot be performed
Sent from my iPhone
On Jul 14, 2011, at 4:58 PM, Holger Hans Peter Freyther holger@freyther.de wrote:
Hi all,
I have seen a strange OML NACK loop in OpenBSC with the ipaccess BTS. When I restart the osmo-nitb it is working again, so I suspect somehow our state of the BTS is corrupted.
any ideas holger <change_admin_null_nack.pcap>
On 07/14/2011 09:58 AM, Holger Hans Peter Freyther wrote:
Hi all,
I have seen a strange OML NACK loop in OpenBSC with the ipaccess BTS. When I restart the osmo-nitb it is working again, so I suspect somehow our state of the BTS is corrupted.
Hi,
okay, this was introduced in this b7849987e516eb3bf102b29298ecc103b8b24d53 commit. Now in general this appears to be a step forward. So what about.
a) 1.) We call the reset after the initial init 2.) try to understand our init code again
b) 1. Revert but I don't think it is necessary.
comments?
holger
Hi Holger,
On Sat, Jul 16, 2011 at 03:37:28PM +0200, Holger Hans Peter Freyther wrote:
okay, this was introduced in this b7849987e516eb3bf102b29298ecc103b8b24d53 commit. Now in general this appears to be a step forward. So what about.
sorry for introducing the problem ...
a) 1.) We call the reset after the initial init 2.) try to understand our init code again
b)
- Revert but I don't think it is necessary.
I'm definitely in favor of 'a', as 'b' would also break OsmoBTS ;) But more seriously speaking, I think we can not make any assumptions on the MO state after loosing the BTS link.
And what would be 'a1', i.e. reset after initial init? Maybe I don't understand you correctly, but this doesn't seem to make sense to me.
If we first do some initialization of the BTS (i.e. change its state) and then reset our view of that state, I don't think it can be right...
On 07/16/2011 05:19 PM, Harald Welte wrote:
And what would be 'a1', i.e. reset after initial init? Maybe I don't understand you correctly, but this doesn't seem to make sense to me.
My point would be to get the OML state in the state it would be after a loss of connection before we have the first connection. This way we would know the re-connection case is working. Maybe my understanding of what the state should be like after a disconnect is wrong.
If we first do some initialization of the BTS (i.e. change its state) and then reset our view of that state, I don't think it can be right...
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
Hi Holger,
On Mon, Jul 18, 2011 at 12:12:26PM +0200, Holger Hans Peter Freyther wrote:
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.
Ok, seems fine to me. Feel free to apply. I'll do some tests with osmo-bts later today, and fix it up if it causes any problems.
Right now I'm doing a port of osmo-bts to libosmo-abis, just to get some experience with it.
On 07/18/2011 03:05 PM, Harald Welte wrote:
Hi Holger,
Ok, seems fine to me. Feel free to apply. I'll do some tests with osmo-bts later today, and fix it up if it causes any problems.
thanks, I did a very basic test with osmo-bts before sending the patch, it seemed to work (RSL was estbalished)
holger
-
Harald Welte -
Holger Hans Peter Freyther -
Seungju Kim