14 Jul
2011
14 Jul
'11
9:58 a.m.
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
14 Jul
14 Jul
10:50 a.m.
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(a)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>
16 Jul
16 Jul
3:37 p.m.
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
5:19 p.m.
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)
1. 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...
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
9:08 p.m.
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...
12:12 p.m.
On 07/18/2011 11:00 AM, Holger Hans Peter Freyther wrote:
On 07/16/2011 09:08 PM, Holger Hans Peter Freyther
wrote:
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
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.
3:05 p.m.
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.
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
3:10 p.m.
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
4683
days inactive
4687
days old
8 comments
3 participants
participants (3)
-
Harald Welte -
Holger Hans Peter Freyther -
Seungju Kim