29 Mar
2018
29 Mar
'18
8:43 a.m.
Hello all,
I have recently tried migrating an OsmoNITB setup to the new standard using mostly this
guide right here:
https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I…
<https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box>
However, while my nanoBTS works perfectly fine in the old setup, it just doesn not work at
all in the new one. When I start osmo-bsc the LED on the BTS starts flashing green after a
few seconds and then stops flashing and just stays green all the time, which is the
expected behaviour. Unfortunately though, after another couple of seconds, the LED starts
flashing green again and then turns red.
This is what the log shows:
BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable
cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1154
****
** l2_bch.c#1154:BCHbcchSItypeValid( prim_p->infoType )
** IPA_SW_FATAL_ERROR
** In task "TRX Proc:L2_BCH" @ (1063).
****
.
BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable
cause=Manufacturer specific values: Fatal software error, Additional Text=TRX
Proc:L2_BCH:l2_bch.c#1154 (1063).
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure,
Probable cause=Manufacturer specific values: Software warning, Additional
Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#255:TRX has logged the error:
.
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure,
Probable cause=Manufacturer specific values: Software warning, Additional
Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#256:TRX Proc:L2_BCH:l2_bch.c#1154 (1063)
.
BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable
cause=Manufacturer specific values: Fatal software error, Additional
Text=BCHbcchSItypeValid( prim_p->infoType ).
BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure,
Probable cause=Manufacturer specific values: Software warning, Additional
Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#260:BCHbcchSItypeValid( prim_p->infoType
)
20180328072641280 DLINP <0013> input/ipaccess.c:247 Sign link vanished, dead socket
20180328072641281 DLINP <0013> input/ipaccess.c:71 Forcing socket shutdown with no
signal link set
20180328072641282 DCTRL <000e> osmo_bsc_ctrl.c:160 No more BTS connected, sending
TRAP.
Now I'm not claiming that my config is already 100% correct but I feel like this
isn't a configuration issue. I'm using the most recent nightly builds of the
entire osmocom library.
Does anyone know what could be at fault here?
Kind regards,
Michael Spahn
29 Mar
29 Mar
12:26 p.m.
Hi Michael,
I've personally been running a nanoBTS (1900 band) with latest master of
all standard components a few days ago, and everything seems fine.
Furthermore, osmo-gsm-tester is running nowadays tests against 2 nanoBTS
(1 in 1900 band, one in 900 band) successfully with latest osmocom
master in
https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-teste….
Of course it could be that your network configuration is not correct, or
you may want to look at the possibility to change/update the firmware in
your nanoBTS.
Check also with wirehsark the communication between the nanoBTS and
osmo-bsc, you may be able to find some error reported in there which may
give you some information.
Cheers,
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
12:30 p.m.
Hi Michael,
On Thu, Mar 29, 2018 at 08:43:20AM +0200, Michael Spahn wrote:
BTS 0: Failure Event Report: Type=processing failure,
Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software
error, Additional Text=BCHbcchSItypeValid( prim_p->infoType ).
It seems that the nanoBTS, at least in the firmware version you are using, is not
supporting
a certain system information type that OsmoBSC is sending. We have no documentation on
those
nanoBTS, but it might be something like SI2ter / SI2quater that it doesn't like.
You could try to disable generation/sending of those. I think we simply iterate over
all SI types and send an empty system information as BCCH INFO via RSL to make sure
that the BTS doesn't transmit any SI that it might have cached from state initialized
before the current RSL connection.
So OsmoBSC might suppress some of those, depending on bts-model nanobts/osmobts.
Interesting side-note:
We have recently added nanoBTS support to osmo-gsm-tester, i.e. we're contintuously
testing SMS and call signalling with latest 'master' of all osmocom code against
two nanoBTSs that are connected to the osmo-gsm-tester setup.
@Pau: Do we see any indication that our setup is showing the same issues?
If we don't see it in our setup, it most likely depends on the specific firmware
release installed on the nanoBTS. Without knowing when exactly the support for the
related SI types was introduced, it's difficult to automatically determine
if we should send SI2ter/SI2quater, or if we should not send 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)
12:42 p.m.
Hi Harald,
Hi Pau,
So I’m trying to find out which firmware is installed on our nanoBTS right now and I’m
also going to try and contact our supplier and ask if they can provide us with the most
recent firmware version. I’m also going to look at the communication between osmoBSC and
the BTS with Wireshark. I’ll get back to you when I have the results.
Thank you all very much!
On 29. Mar 2018, at 12:30, Harald Welte
<laforge(a)gnumonks.org> wrote:
Hi Michael,
On Thu, Mar 29, 2018 at 08:43:20AM +0200, Michael Spahn wrote:
BTS 0: Failure Event Report: Type=processing
failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal
software error, Additional Text=BCHbcchSItypeValid( prim_p->infoType ).
It seems that the nanoBTS, at least in the firmware version you are using, is not
supporting
a certain system information type that OsmoBSC is sending. We have no documentation on
those
nanoBTS, but it might be something like SI2ter / SI2quater that it doesn't like.
You could try to disable generation/sending of those. I think we simply iterate over
all SI types and send an empty system information as BCCH INFO via RSL to make sure
that the BTS doesn't transmit any SI that it might have cached from state
initialized
before the current RSL connection.
So OsmoBSC might suppress some of those, depending on bts-model nanobts/osmobts.
Interesting side-note:
We have recently added nanoBTS support to osmo-gsm-tester, i.e. we're contintuously
testing SMS and call signalling with latest 'master' of all osmocom code against
two nanoBTSs that are connected to the osmo-gsm-tester setup.
@Pau: Do we see any indication that our setup is showing the same issues?
If we don't see it in our setup, it most likely depends on the specific firmware
release installed on the nanoBTS. Without knowing when exactly the support for the
related SI types was introduced, it's difficult to automatically determine
if we should send SI2ter/SI2quater, or if we should not send 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 Apr
3 Apr
10:30 a.m.
Hi,
so I’ve disabled sending of System Information Types and now the BTS isn’t rebooting
anymore and the log doesn’t seem to show any errors. However, as long as osmo-bsc is
running my phone endlessly scans for networks. The scan only ends when I stop osmo-bsc. I
guess that’s a configuration issue of some sort?
Kind regards,
Michael
On 29. Mar 2018, at 12:30, Harald Welte
<laforge(a)gnumonks.org> wrote:
Hi Michael,
On Thu, Mar 29, 2018 at 08:43:20AM +0200, Michael Spahn wrote:
BTS 0: Failure Event Report: Type=processing
failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal
software error, Additional Text=BCHbcchSItypeValid( prim_p->infoType ).
It seems that the nanoBTS, at least in the firmware version you are using, is not
supporting
a certain system information type that OsmoBSC is sending. We have no documentation on
those
nanoBTS, but it might be something like SI2ter / SI2quater that it doesn't like.
You could try to disable generation/sending of those. I think we simply iterate over
all SI types and send an empty system information as BCCH INFO via RSL to make sure
that the BTS doesn't transmit any SI that it might have cached from state
initialized
before the current RSL connection.
So OsmoBSC might suppress some of those, depending on bts-model nanobts/osmobts.
Interesting side-note:
We have recently added nanoBTS support to osmo-gsm-tester, i.e. we're contintuously
testing SMS and call signalling with latest 'master' of all osmocom code against
two nanoBTSs that are connected to the osmo-gsm-tester setup.
@Pau: Do we see any indication that our setup is showing the same issues?
If we don't see it in our setup, it most likely depends on the specific firmware
release installed on the nanoBTS. Without knowing when exactly the support for the
related SI types was introduced, it's difficult to automatically determine
if we should send SI2ter/SI2quater, or if we should not send 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)
10:57 a.m.
On Tue, Apr 03, 2018 at 10:30:55AM +0200, Michael Spahn wrote:
Hi,
so I’ve disabled sending of System Information Types
which of the types did you disable, and which are still sent?
and now the BTS isn’t rebooting anymore and the log
doesn’t seem to show any errors. However, as long as osmo-bsc is running my phone
endlessly scans for networks. The scan only ends when I stop osmo-bsc. I guess that’s a
configuration issue of some sort?
You will need SI2/3/4 as a minimum. And those of course shouldn't contain any
indication that other SI types are present, as otherwise the phone will wait for that SI
to appear.
--
- 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)
12:04 p.m.
Nevermind, it’s working perfectly now, I accidentally disabled all SI types….
So the only type I disabled is SI2quater and now everything seems to work completely
fine.
Doesn’t SI2quater handle 3G-related information? I could see why that would cause problems
on a 2G cell.
On 3. Apr 2018, at 10:57, Harald Welte
<laforge(a)gnumonks.org> wrote:
On Tue, Apr 03, 2018 at 10:30:55AM +0200, Michael Spahn wrote:
Hi,
so I’ve disabled sending of System Information Types
which of the types did you disable, and which are still sent?
and now the BTS isn’t rebooting anymore and the
log doesn’t seem to show any errors. However, as long as osmo-bsc is running my phone
endlessly scans for networks. The scan only ends when I stop osmo-bsc. I guess that’s a
configuration issue of some sort?
You will need SI2/3/4 as a minimum. And those of course shouldn't contain any
indication that other SI types are present, as otherwise the phone will wait for that SI
to appear.
--
- 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)
1:50 p.m.
For reference in case you are interested, it's probably not the same
issue but I also noticed a few days ago some issues when using nanoBTS
with SI 2ter. See https://osmocom.org/issues/3063
In this case sending the SI2ter prevents some phones from registering to
my network.
I didn't have time to give it a deeper look yet.
--
- Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte
3:08 p.m.
From reading the osmocom redmine bug 3063, it seems to me yoiu simply suppressed si5ter,
not si2ter?
--
Sent from a mobile device. Please excuse my brevity.
1 Jun
1 Jun
8:14 p.m.
W dniu 03.04.2018 o 12:04, Michael Spahn pisze:
Nevermind, it’s working perfectly now, I accidentally
disabled all SI types….
So the only type I disabled is SI2quater and now everything seems to work completely
fine.
Doesn’t SI2quater handle 3G-related information? I could see why that would cause
problems on a 2G cell.
> On 3. Apr 2018, at 10:57, Harald Welte <laforge(a)gnumonks.org> wrote:
>
> On Tue, Apr 03, 2018 at 10:30:55AM +0200, Michael Spahn wrote:
>> Hi,
>>
>> so I’ve disabled sending of System Information Types
>
> which of the types did you disable, and which are still sent?
>
>> and now the BTS isn’t rebooting anymore and the log doesn’t seem to show any
errors. However, as long as osmo-bsc is running my phone endlessly scans for networks. The
scan only ends when I stop osmo-bsc. I guess that’s a configuration issue of some sort?
>
> You will need SI2/3/4 as a minimum. And those of course shouldn't contain any
indication that other SI types are present, as otherwise the phone will wait for that SI
to appear.
Hi all,
I think I have the same/similar issue with NanoBTS.
Is it possible for you to share what exactly solved your problem?
It would make this thread more helpful/finished.
--
Best Regards,
Piotr Krysik
2158
days inactive
2222
days old
9 comments
4 participants
participants (4)
-
Harald Welte -
Michael Spahn -
Pau Espin Pedrol -
Piotr Krysik