This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Michael Spahn michaelspahn.osmo at gmail.comHi, 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 at 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 at gnumonks.org> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6)