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 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 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)