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 <[email protected]> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
