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_In... 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
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-tester....
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,
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
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@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@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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@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@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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.
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@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@gnumonks.org http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
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.
From reading the osmocom redmine bug 3063, it seems to me yoiu simply suppressed si5ter, not si2ter?
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@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.
-
Harald Welte -
Michael Spahn -
Pau Espin Pedrol -
Piotr Krysik