Project

General

Profile

Bug #3707

nanoBTS fails to start

Added by manatails 19 days ago. Updated about 3 hours ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
11/26/2018
Due date:
% Done:

90%

Spec Reference:

Description

With the newest git repo version of osmo-bsc, my nanoBTS fails to start.

I can confirm that it works normally with ip.access softBSC and it used to work with osmo-nitb.

I thought osmocom Redmine issue #3063 might be relevant and tried
setting/unsetting force-combined-si but I am still getting the same
result.
Attached are the packet capture and bsc config file, and debug log from osmo-bsc

osmo-bsc.cfg osmo-bsc.cfg 3.54 KB manatails, 11/26/2018 01:04 PM
nanobts.pcap nanobts.pcap 29.6 KB manatails, 11/26/2018 01:04 PM
bsc.log bsc.log 130 KB manatails, 11/26/2018 01:04 PM
nanobts_working.pcap nanobts_working.pcap 25.5 KB manatails, 11/26/2018 05:14 PM
nanobts_new.pcap nanobts_new.pcap 30.4 KB manatails, 11/26/2018 06:09 PM

Related issues

Related to OsmoBSC - Bug #3063: OsmoBSC + nanoBTS 165AU (DCS1800): smartphone Samsung 4mini 5 unable to register (it can on osmo-nitb)Resolved2018-03-13

History

#1 Updated by pespin 19 days ago

  • Related to Bug #3063: OsmoBSC + nanoBTS 165AU (DCS1800): smartphone Samsung 4mini 5 unable to register (it can on osmo-nitb) added

#2 Updated by pespin 19 days ago

  • Assignee set to pespin

Can you please test with following TS configuration and provide feedback?

   timeslot 0
    phys_chan_config CCCH+SDCCH4
    hopping enabled 0
   timeslot 1
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 2
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 3
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 4
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 5
    phys_chan_config TCH/F
    hopping enabled 0
   timeslot 6
    phys_chan_config PDCH
    hopping enabled 0
   timeslot 7
    phys_chan_config PDCH
    hopping enabled 0

#3 Updated by manatails 19 days ago

It fails in the same way, in fact it was the first thing I tried, I only used SDCCH8 because it was the last known working config.

#4 Updated by pespin 19 days ago

Which commit of libosmocore, libosmo-abis, libosmo-netif and osmo-bsc are you using?

Could you do some test running with slightly older osmo-bsc to see if the issue persists?
Some interesting points for testing (newer to older):
77cd1129931928d2a6e7667d0374feeeed71b0ce
726b097b0c1a6042186736ffc18d4666a609453b
8f02f0fdca72526813cd0f808f470dfb9b137971
c459699483f1773d197768961c2ad58576737eb5
f535cc84c7090ba1340d756ad2b03b13572aeadf
89d72d8055191bde798df3fd2be5db17a93193d8

Try testing first the oldest (last) one, and if it works, then keep going up through the list until it fails.

#5 Updated by manatails 19 days ago

libosmocore is at 7ab5fc1f3b373fadc644448442b985c12597f8f0
libosmo-abis is at 4179207e0ec2833c649174aef5b32b54431f23a8
libosmo-netif is at 7028d7387efc2e0fbac403de075c4c9c2d310f80

osmo-bsc initially failed with the newest git version: 08155e90654c145737a5b5fe614ecf27aa725086

I just tested the oldest one you posted and it also failed: 89d72d8055191bde798df3fd2be5db17a93193d8

#6 Updated by pespin 19 days ago

Ok, then it's not related to any recent change in osmo-bsc.

If you still have a working osmo-nitb setup, it would be great if you could compile latest osmo-nitb (openbsc.git) with latest libosmocore, libosmo-abis and libosmo-netif and test if it still works fine, and provide a pcap file so we can compare what's different protocol-wise.

#8 Updated by pespin 19 days ago

In your pcap file, I don't see any SI known to have conflict with nanoBTS being enabled.

SI2bis, SI2ter and SI2quater, SI5bis, SI5ter are disabled.

SI2, SI3, SI4, SI5, SI6 are enabled.

See pcap file frame nr 127 "SACCH Filling (CCCH)"

#9 Updated by pespin 19 days ago

Is your nanoBTS expected to work on band PCS1900?

Please provide information regarding your nanoBTS (you can find it in the sticker glued to the metal. For instance: Model 165AU (012) V55 DCS1800" in the one I have with me right now).

#10 Updated by manatails 19 days ago

Sure it is...

Attaching a working packet capture with openbsc version at daaea0c84fee46d9b63b746d5ed2cdf66f990352
(It's 2015!!)

I had a newer setup in 2017 but I think I deleted the VM.

#11 Updated by pespin 19 days ago

Quick look shows 2 differences:

  • osmo-nitb sends SI13 in SACCH FILLing, osmo-bsc doesn't
  • osmo-bsc sends SI2bis, SI2ter and SI2quater, SI5bis, SI5ter disabled, that is with empty L3 Info. osmo-nitb doesn't send them at all.
  • osmo-nitb sends wrong contents in SI6 according to wireshark: "Expert Info (Error/Protocol): Missing Mandatory element SI 6 Rest Octets, rest of dissection is suspect"

I bet the third point is going to be causing the issue. I'd suggest trying to modify the code in osmo-bsc to stop sending the SI6 Rest Octects and see if with that it works. We can then add a VTY option to enable/disable it.

#12 Updated by pespin 19 days ago

I think this change should be enough to disable sending the SI6 Rest Octets. Can you apply it to osmo-bsc and test it and provide pcap file if still doesn't work?

diff --git a/src/osmo-bsc/system_information.c b/src/osmo-bsc/system_information.c
index 4709f7fc0..915f79582 100644
--- a/src/osmo-bsc/system_information.c
+++ b/src/osmo-bsc/system_information.c
@@ -1138,7 +1138,7 @@ static int generate_si6(enum osmo_sysinfo_type t, struct gsm_bts *bts)

        /* SI6 Rest Octets: 10.5.2.35a: PCH / NCH info, VBS/VGCS options */
        rc = rest_octets_si6(si6->rest_octets, is_dcs_net(bts));
-
+       rc = 0;
        return l2_plen + rc;
 }

#13 Updated by manatails 19 days ago

With hopes I applied the patch but it did not work.

Attaching the new packet capture file

#14 Updated by pespin 19 days ago

OK, then given the error that we get from nanoBTS:

BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1149
****
** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType )
** IPA_SW_FATAL_ERROR
** In task "TRX Proc:L2_BCH" @ (325).
****

.

I guess it means your firmware doesn't support receiving empty SI (with no L3 Info). That's point 2 of the list of possible issues I found before.

#15 Updated by pespin 19 days ago

I think this patch should provoke the desired effect for point 2.
Please again, patch + build + test + provide feedback and pcap file.

diff --git a/src/osmo-bsc/bsc_init.c b/src/osmo-bsc/bsc_init.c
index 2f44b200a..1611b58df 100644
--- a/src/osmo-bsc/bsc_init.c
+++ b/src/osmo-bsc/bsc_init.c
@@ -177,7 +177,8 @@ int gsm_bts_trx_set_system_infos(struct gsm_bts_trx *trx)
                 * RSL BCCH FILLING / SACCH FILLING * in order to deactivate
                 * the SI, in case it might have previously been active */
                if (!GSM_BTS_HAS_SI(bts, i))
-                       rc = rsl_si(trx, i, 0);
+                       //rc = rsl_si(trx, i, 0);
+                       rc = 0;
                else
                        rc = rsl_si(trx, i, si_len[i]);
                if (rc < 0)

#16 Updated by manatails 18 days ago

With the new patch nanobts starts up properly.

I tested it again with the first patch removed, and it is still working.

#17 Updated by pespin 18 days ago

  • Status changed from New to Feedback

Great. In order to understand better the exact issue (or the SI not supported), it would be great if you could do some more tests. With the previous patch we avoid sending an empty L3 Info for ALL disabled SI.

Now, we want now to avoid sending it only for 1 each time, to see which SI exactly causes the failure.

So you should run for each of the following SI defines:
SYSINFO_TYPE_2bis
SYSINFO_TYPE_2ter
SYSINFO_TYPE_2quater
SYSINFO_TYPE_5bis
SYSINFO_TYPE_5ter

the following patch (change XYZ for each of the defines above each time you test):

diff --git a/src/osmo-bsc/bsc_init.c b/src/osmo-bsc/bsc_init.c
index 2f44b200a..e632f363d 100644
--- a/src/osmo-bsc/bsc_init.c
+++ b/src/osmo-bsc/bsc_init.c
@@ -176,9 +176,12 @@ int gsm_bts_trx_set_system_infos(struct gsm_bts_trx *trx)
                /* if we don't currently have this SI, we send a zero-length
                 * RSL BCCH FILLING / SACCH FILLING * in order to deactivate
                 * the SI, in case it might have previously been active */
-               if (!GSM_BTS_HAS_SI(bts, i))
-                       rc = rsl_si(trx, i, 0);
-               else
+               if (!GSM_BTS_HAS_SI(bts, i)) {
+                       if (i == XYZ)
+                               rc = 0;
+                       else
+                               rc = rsl_si(trx, i, 0);
+               } else
                        rc = rsl_si(trx, i, si_len[i]);
                if (rc < 0)
                        return rc;

Then provide for each XYZ where we avoid sending the empty L3 Info, when nanoBTS crashes and when it succeeds.

This way we can write a proper fix (once we see the magnitude of the issue).

#18 Updated by manatails 16 days ago

SYSINFO_TYPE_2bis => crashes
SYSINFO_TYPE_2ter => crashes
SYSINFO_TYPE_2quater => working
SYSINFO_TYPE_5bis => crashes
SYSINFO_TYPE_5ter => crashes

Now we see which one is the problem :)

#19 Updated by pespin 16 days ago

I guess you mean "which oneS" right? Because all of them except one needs fixing. Just to make sure we are on the same understanding.
I guess we could add a VTY param with a list of SI for which we avoid sending a SI with an empty L3 Info.

#20 Updated by laforge 15 days ago

On Thu, Nov 29, 2018 at 11:20:32AM +0000, pespin [REDMINE] wrote:

I guess we could add a VTY param with a list of SI for which we avoid sending a SI with an empty L3 Info.

As the problem only seems to affect nanoBTS with specific firmware versions, I would rather avoid
inventing too general solutions here. Either make it

  • a global on/off switch, or
  • dynamically detect a reject of empty SI and then stop doing so
  • always send no empty SI L3 info on bts_type == nanobts, or
  • simply ask users to upgrade their nanoBTS firmware to a more compatible version

AFAIR, TS 08.58 explicitly states that a given SI can be disabled by sending a zero-length one.

For most setups it also doesn't really matter, as SI content rarely changes. Particilarly, it's
even more unlikely that you first broadcast a given SI and then later on stop broadcasting that
one - at least not in production networks.

#21 Updated by pespin 10 days ago

  • % Done changed from 0 to 90

Hi manatails ,

can you please test following patch and provide feedback saying if it solves the issue with your nanoBTS?
You need to add following option to your VTY cfg file under the "bts" node, then it should work: "no system-information disabled-si-send-empty-bcch-info"

https://gerrit.osmocom.org/#/c/osmo-bsc/+/12133 Add VTY option to avoid sending empty Full BCCH Info for disabled SI

#22 Updated by manatails 5 days ago

pespin wrote:

can you please test following patch and provide feedback saying if it solves the issue with your nanoBTS?

I can confirm that it is working with "no system-information unused-send-empty" option.

Thank you.

#23 Updated by ptrkrysik about 3 hours ago

Hi laforge,

The nanoBTS I got from you seems to have this issue. I'm interested in performing the option with firmware upgrade. However only explanation where to get new firmware for nanoBTS I got is from this thread from 2011:
http://lists.osmocom.org/pipermail/openbsc/2011-February/003531.html

So basically it is "ask your supplier" for the new firmware.

Is it possible to download it from somewhere now?

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)