17 Nov
2009
17 Nov
'09
9:11 p.m.
Hi Harald,
I have one problem with the BTS on cold start. OpenBSC is sending the RSL
connect, Radio Carrier/Baseband attributes too early and we are receiving
NACKs from the BTS and the RSL link is never established.
The first question is if others have seen this problem? I have solved the
problem my moving the OP start/set attributes/RSL connect of the RC and
Baseband out of the state change code into the "Software Activated Report".
Doing a quick check it seems to still work and solve my cold start problem. Do
you think this is a legitimate workaround for the problem right now?
In the future we probably should attempt to have a better state machine,
report errors, retry and such things...
regards
holger
18 Nov
18 Nov
12:21 p.m.
Me2.
Need to restart bsc_hack the first time after nanobts coldboot.
Best Regards
Björn Heller
Am 17.11.2009 um 21:11 schrieb Holger Freyther <zecke(a)selfish.org>rg>:
Hi Harald,
I have one problem with the BTS on cold start. OpenBSC is sending
the RSL
connect, Radio Carrier/Baseband attributes too early and we are
receiving
NACKs from the BTS and the RSL link is never established.
The first question is if others have seen this problem? I have
solved the
problem my moving the OP start/set attributes/RSL connect of the RC
and
Baseband out of the state change code into the "Software Activated
Report".
Doing a quick check it seems to still work and solve my cold start
problem. Do
you think this is a legitimate workaround for the problem right now?
In the future we probably should attempt to have a better state
machine,
report errors, retry and such things...
regards
holger
10:02 a.m.
Ill try later on today when Im at home.
Best Regards
Björn Heller
Am 19.11.2009 um 09:51 schrieb Holger Freyther <zecke(a)selfish.org>rg>:
On Wednesday 18 November 2009 12:21:39 Bjoern Heller
wrote:
Me2.
Need to restart bsc_hack the first time after nanobts coldboot.
could you please attempt to test the following patch?
<bsc_start_hack.diff> 
20 Nov
20 Nov
4:09 p.m.
On Thu, Nov 19, 2009 at 9:51 AM, Holger Freyther <zecke(a)selfish.org> wrote:
On Wednesday 18 November 2009 12:21:39 Bjoern Heller
wrote:
I have a nanoBTS at home and it takes two restart for it to work.
I just got a another nanoBTS with a different SW version today and
without the patch, it would not even start, even when trying multiple
times (it seems to reset all OML stuff on disconnect ...), with it, it
start reliably.
Sylvain
Me2.
Need to restart bsc_hack the first time after nanobts coldboot.
could you please attempt to test the following patch?
11:37 p.m.
I just got a another nanoBTS with a different SW
version today and
without the patch, it would not even start, even when trying multiple
times (it seems to reset all OML stuff on disconnect ...), with it, it
start reliably.
i have mispoken.
I also needed to add an SITE MANAGER OPSTART in case I get a "Disabled /
Offline" status report for it.
Sylvain
2:09 p.m.
On Tue, Nov 17, 2009 at 09:11:36PM +0100, Holger Freyther wrote:
Hi Harald,
I have one problem with the BTS on cold start. OpenBSC is sending the RSL
connect, Radio Carrier/Baseband attributes too early and we are receiving
NACKs from the BTS and the RSL link is never established.
The first question is if others have seen this problem? I have solved the
problem my moving the OP start/set attributes/RSL connect of the RC and
Baseband out of the state change code into the "Software Activated Report".
Yes, this is what we had before. If you look at the revision log, it used to
be this way and worked more reliably. I already spent way too much time trying
to find out the correct state machine but failed.
Doing a quick check it seems to still work and solve
my cold start problem. Do
you think this is a legitimate workaround for the problem right now?
In the future we probably should attempt to have a better state machine,
report errors, retry and such things...
Meanwhile I think it should be sufficient to return to the old code, as it was
working quite reliably for many months.
--
- 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)
22 Nov
22 Nov
10:57 a.m.
On Fri, Nov 20, 2009 at 02:54:11PM +0100, Holger Freyther wrote:
On Friday 20 November 2009 14:09:46 Harald Welte
wrote:
simply use that new patch that you posted. The old change that I introduced
changes multiple things in one patch, as far as I remember... so reverting it
might not be a good idea. But at least the decision what to initialize when
should be the same as it was before my changes.
--
- 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)
Meanwhile I think it should be sufficient to
return to the old code, as it
was working quite reliably for many months.
Should I revert the whole patch or just parts of it?
5276
days inactive
5281
days old
8 comments
5 participants
participants (5)
-
246tnt＠gmail.com -
Bjoern Heller -
Harald Welte -
Holger Freyther -
Sylvain Munaut