https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092018-11-26T13:10:43ZOpen Source Mobile CommunicationsOsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=126932018-11-26T13:10:43Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-3 priority-2 priority-default closed" href="/issues/3063">Bug #3063</a>: OsmoBSC + nanoBTS 165AU (DCS1800): smartphone Samsung 4mini 5 unable to register (it can on osmo-nitb)</i> added</li></ul> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=126942018-11-26T13:36:13Zpespin
<ul><li><strong>Assignee</strong> set to <i>pespin</i></li></ul><p>Can you please test with following TS configuration and provide feedback?<br /><pre>
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
</pre></p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=126972018-11-26T15:03:30Zmanatails
<ul></ul><p>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.</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127022018-11-26T15:22:02Zpespin
<ul></ul><p>Which commit of libosmocore, libosmo-abis, libosmo-netif and osmo-bsc are you using?</p>
<p>Could you do some test running with slightly older osmo-bsc to see if the issue persists?<br />Some interesting points for testing (newer to older):<br />77cd1129931928d2a6e7667d0374feeeed71b0ce<br />726b097b0c1a6042186736ffc18d4666a609453b<br />8f02f0fdca72526813cd0f808f470dfb9b137971<br />c459699483f1773d197768961c2ad58576737eb5<br />f535cc84c7090ba1340d756ad2b03b13572aeadf<br />89d72d8055191bde798df3fd2be5db17a93193d8</p>
<p>Try testing first the oldest (last) one, and if it works, then keep going up through the list until it fails.</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127032018-11-26T15:30:05Zmanatails
<ul></ul><p>libosmocore is at 7ab5fc1f3b373fadc644448442b985c12597f8f0<br />libosmo-abis is at 4179207e0ec2833c649174aef5b32b54431f23a8<br />libosmo-netif is at 7028d7387efc2e0fbac403de075c4c9c2d310f80</p>
<p>osmo-bsc initially failed with the newest git version: 08155e90654c145737a5b5fe614ecf27aa725086</p>
<p>I just tested the oldest one you posted and it also failed: 89d72d8055191bde798df3fd2be5db17a93193d8</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127042018-11-26T15:45:10Zpespin
<ul></ul><p>Ok, then it's not related to any recent change in osmo-bsc.</p>
<p>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.</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127052018-11-26T16:23:08Zpespin
<ul></ul><p>Seems same kind of issue as <a class="external" href="https://www.mail-archive.com/openbsc@lists.osmocom.org/msg08622.html">https://www.mail-archive.com/openbsc@lists.osmocom.org/msg08622.html</a></p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127062018-11-26T16:34:29Zpespin
<ul></ul><p>In your pcap file, I don't see any SI known to have conflict with nanoBTS being enabled.</p>
<p>SI2bis, SI2ter and SI2quater, SI5bis, SI5ter are disabled.</p>
<p>SI2, SI3, SI4, SI5, SI6 are enabled.</p>
<p>See pcap file frame nr 127 "SACCH Filling (CCCH)"</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127072018-11-26T16:38:27Zpespin
<ul></ul><p>Is your nanoBTS expected to work on band PCS1900?</p>
<p>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).</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127092018-11-26T17:17:03Zmanatails
<ul><li><strong>File</strong> <a href="/attachments/3457">nanobts_working.pcap</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3457/nanobts_working.pcap">nanobts_working.pcap</a> added</li></ul><p>Sure it is...</p>
<p>Attaching a working packet capture with openbsc version at daaea0c84fee46d9b63b746d5ed2cdf66f990352<br />(It's 2015!!)</p>
<p>I had a newer setup in 2017 but I think I deleted the VM.</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127102018-11-26T17:47:49Zpespin
<ul></ul><p>Quick look shows 2 differences:</p>
<ul>
<li>osmo-nitb sends SI13 in SACCH FILLing, osmo-bsc doesn't</li>
<li>osmo-bsc sends SI2bis, SI2ter and SI2quater, SI5bis, SI5ter disabled, that is with empty L3 Info. osmo-nitb doesn't send them at all.</li>
<li>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"</li>
</ul>
<p>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.</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127112018-11-26T17:54:14Zpespin
<ul></ul><p>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?</p>
<pre>
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;
}
</pre> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127132018-11-26T18:10:13Zmanatails
<ul><li><strong>File</strong> <a href="/attachments/3460">nanobts_new.pcap</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3460/nanobts_new.pcap">nanobts_new.pcap</a> added</li></ul><p>With hopes I applied the patch but it did not work.</p>
<p>Attaching the new packet capture file</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127162018-11-26T18:23:14Zpespin
<ul></ul><p>OK, then given the error that we get from nanoBTS:</p>
<pre>
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).
****
.
</pre>
<p>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.</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127172018-11-26T18:29:10Zpespin
<ul></ul><p>I think this patch should provoke the desired effect for point 2.<br />Please again, patch + build + test + provide feedback and pcap file.</p>
<pre>
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)
</pre> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127452018-11-27T00:17:56Zmanatails
<ul></ul><p>With the new patch nanobts starts up properly.</p>
<p>I tested it again with the first patch removed, and it is still working.</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127522018-11-27T11:06:01Zpespin
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul><p>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.</p>
<p>Now, we want now to avoid sending it only for 1 each time, to see which SI exactly causes the failure.</p>
<p>So you should run for each of the following SI defines:<br />SYSINFO_TYPE_2bis<br />SYSINFO_TYPE_2ter<br />SYSINFO_TYPE_2quater<br />SYSINFO_TYPE_5bis<br />SYSINFO_TYPE_5ter</p>
<p>the following patch (change XYZ for each of the defines above each time you test):<br /><pre>
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;
</pre></p>
<p>Then provide for each XYZ where we avoid sending the empty L3 Info, when nanoBTS crashes and when it succeeds.</p>
<p>This way we can write a proper fix (once we see the magnitude of the issue).</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127812018-11-29T01:02:06Zmanatails
<ul></ul><p>SYSINFO_TYPE_2bis => crashes<br />SYSINFO_TYPE_2ter => crashes<br />SYSINFO_TYPE_2quater => working<br />SYSINFO_TYPE_5bis => crashes<br />SYSINFO_TYPE_5ter => crashes</p>
<p>Now we see which one is the problem :)</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127832018-11-29T11:20:31Zpespin
<ul></ul><p>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.<br />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.</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=127982018-11-30T07:20:16Zlaforge
<ul></ul><p>On Thu, Nov 29, 2018 at 11:20:32AM +0000, pespin [REDMINE] wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>As the problem only seems to affect nanoBTS with specific firmware versions, I would rather avoid<br />inventing too general solutions here. Either make it</p>
<ul>
<li>a global on/off switch, or</li>
<li>dynamically detect a reject of empty SI and then stop doing so</li>
<li>always send no empty SI L3 info on bts_type == nanobts, or</li>
<li>simply ask users to upgrade their nanoBTS firmware to a more compatible version</li>
</ul>
<p>AFAIR, TS 08.58 explicitly states that a given SI can be disabled by sending a zero-length one.</p>
<p>For most setups it also doesn't really matter, as SI content rarely changes. Particilarly, it's<br />even more unlikely that you first broadcast a given SI and then later on stop broadcasting that<br />one - at least not in production networks.</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=128382018-12-05T12:48:37Zpespin
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>90</i></li></ul><p>Hi <a class="user active" href="https://projects.osmocom.org/users/35">manatails</a> ,</p>
<p>can you please test following patch and provide feedback saying if it solves the issue with your nanoBTS? <br />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"</p>
<p><a class="external" href="https://gerrit.osmocom.org/#/c/osmo-bsc/+/12133">https://gerrit.osmocom.org/#/c/osmo-bsc/+/12133</a> Add VTY option to avoid sending empty Full BCCH Info for disabled SI</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=128762018-12-10T13:14:02Zmanatails
<ul></ul><p>pespin wrote:</p>
<blockquote>
<p>can you please test following patch and provide feedback saying if it solves the issue with your nanoBTS?</p>
</blockquote>
<p>I can confirm that it is working with "no system-information unused-send-empty" option.</p>
<p>Thank you.</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=129582018-12-15T08:01:13Zptrkrysik
<ul></ul><p>Hi <a class="user active" href="https://projects.osmocom.org/users/7">laforge</a>,</p>
<p>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:<br /><a class="external" href="http://lists.osmocom.org/pipermail/openbsc/2011-February/003531.html">http://lists.osmocom.org/pipermail/openbsc/2011-February/003531.html</a></p>
<p>So basically it is "ask your supplier" for the new firmware.</p>
<p>Is it possible to download it from somewhere now?</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=129592018-12-15T18:51:53Zpespin
<ul><li><strong>Assignee</strong> changed from <i>pespin</i> to <i>laforge</i></li></ul><p>Patch has been merged. Issue can be closed once laforge answers the last question.</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=129602018-12-16T14:00:08Zlaforge
<ul></ul><p>On Sat, Dec 15, 2018 at 08:01:15AM +0000, ptrkrysik [REDMINE] wrote:</p>
<blockquote>
<p>Is it possible to download it from somewhere now?</p>
</blockquote>
<p>no, it's proprietary to ip.access and only made available to customers<br />with active support contracts, from what I know/heard.</p> OsmoBSC - Bug #3707: nanoBTS fails to starthttps://projects.osmocom.org/issues/3707?journal_id=130702019-01-14T15:32:19Zlaforge
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Closed</i></li></ul>