Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-02-28T08:48:26ZOpen Source Mobile Communications
Redmine libosmo-abis - Bug #6379 (Resolved): ttcn3-{msc,sgsn}-test regressions (IUT SIGSEGV)https://projects.osmocom.org/issues/63792024-02-28T08:48:26Zfixeria
<p>Both testsuites exhibit massive regressions since a few days ago:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/2308/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/2308/</a> +213 failures<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sgsn-test/2264/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sgsn-test/2264/</a> +70 failures</p>
<p>The artifacts generated while running those testsuites contain core dump files, so the IUT is crashing.</p>
<p>I managed to reproduce the problem by running ttcn3-msc-test against the most recent version of osmo-msc:</p>
<pre>
20240228153930783 DLGSUP NOTICE GSUP connecting to 127.0.0.1:4222 (gsup_client.c:74)
20240228153930783 DLINP NOTICE 127.0.0.1:4222 connection done (ipa.c:143)
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7c02274 in ipaccess_bts_handle_ccm (link=link@entry=0x55555584bef0, dev=0x55555584a920, msg=msg@entry=0x555555889b10) at ../../../src/libosmo-abis/src/input/ipaccess.c:897
897 LOGPIL(line, DLINP, LOGL_NOTICE, "received ID_GET for unit ID %u/%u/%u\n",
(gdb) bt
#0 0x00007ffff7c02274 in ipaccess_bts_handle_ccm (link=link@entry=0x55555584bef0, dev=0x55555584a920, msg=msg@entry=0x555555889b10) at ../../../src/libosmo-abis/src/input/ipaccess.c:897
#1 0x00007ffff7c1aa7a in gsup_client_read_cb (link=0x55555584bef0, msg=0x555555889b10) at ../../../../src/osmo-hlr/src/gsupclient/gsup_client.c:209
#2 0x00007ffff7bfd0df in ipa_client_read (link=0x55555584bef0) at ../../../src/libosmo-abis/src/input/ipa.c:77
#3 ipa_client_fd_cb (ofd=<optimized out>, what=1) at ../../../src/libosmo-abis/src/input/ipa.c:151
#4 0x00007ffff7aefc2f in poll_disp_fds (n_fd=<optimized out>) at ../../../../src/libosmocore/src/core/select.c:419
#5 _osmo_select_main (polling=polling@entry=0) at ../../../../src/libosmocore/src/core/select.c:457
#6 0x00007ffff7aefd5e in osmo_select_main_ctx (polling=polling@entry=0) at ../../../../src/libosmocore/src/core/select.c:513
#7 0x000055555556971d in main (argc=<optimized out>, argv=<optimized out>) at ../../../../src/osmo-msc/src/osmo-msc/msc_main.c:846
</pre> OsmoHNBGW - Bug #6302 (Resolved): ttcn3-hnbgw-test-latest regression (IUT segmentation fault)https://projects.osmocom.org/issues/63022023-12-12T12:31:45Zfixeria
<p>Starting from December 5th, we're seeing regressions in ttcn3-hnbgw-test <strong>latest</strong>:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-hnbgw-test-latest/535/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-hnbgw-test-latest/535/</a> (+28 failures)</p>
<p>All affected testcases fail due to a DTE:</p>
<pre>
MTC@6005ed7d57b8: setverdict(fail): none -> fail reason: ""VTY Timeout for prompt: enable"", new component reason: ""VTY Timeout for prompt: enable""
</pre>
<p>We can also see a coredump file in the artifacts:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-hnbgw-test-latest/535/artifact/logs/hnbgw/core">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-hnbgw-test-latest/535/artifact/logs/hnbgw/core</a></p>
<p>I managed to reproduce the problem locally and examined the coredump in gdb:</p>
<pre>
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f75debf1489 in on_success (data=<optimized out>, ci=0x562ca9a8f690) at ./src/libosmo-mgcp-client/mgcp_client_endpoint_fsm.c:539
539 ./src/libosmo-mgcp-client/mgcp_client_endpoint_fsm.c: No such file or directory.
(gdb) bt
#0 0x00007f75debf1489 in on_success (data=<optimized out>, ci=0x562ca9a8f690) at ./src/libosmo-mgcp-client/mgcp_client_endpoint_fsm.c:539
#1 osmo_mgcpc_ep_fsm_handle_ci_events (fi=<optimized out>, event=<optimized out>, data=<optimized out>) at ./src/libosmo-mgcp-client/mgcp_client_endpoint_fsm.c:957
#2 0x00007f75deaf2ef0 in _osmo_fsm_inst_dispatch (fi=0x562ca9a8be50, event=0, data=0x562ca9a9603c, file=0x7f75debf5ba3 "mgcp_client_fsm.c", line=446) at ./src/core/fsm.c:875
#3 0x00007f75deaf2ef0 in _osmo_fsm_inst_dispatch (fi=0x562ca9a95c10, event=3, data=0x562ca9a95d40, file=0x7f75debf5ba3 "mgcp_client_fsm.c", line=429) at ./src/core/fsm.c:875
#4 0x00007f75debe2817 in mgcp_client_handle_response (mgcp=0x562ca9a7d970, pending=0x562ca9a8b840, response=<optimized out>) at ./src/libosmo-mgcp-client/mgcp_client.c:246
#5 0x00007f75debe2dc4 in mgcp_client_rx (mgcp=mgcp@entry=0x562ca9a7d970, msg=msg@entry=0x562ca9a96380) at ./src/libosmo-mgcp-client/mgcp_client.c:741
#6 0x00007f75debe3da7 in mgcp_do_read (fd=0x562ca9a7ddb0) at ./src/libosmo-mgcp-client/mgcp_client.c:771
#7 0x00007f75deb0f241 in osmo_wqueue_bfd_cb (fd=0x562ca9a7ddb0, what=1) at ./src/core/write_queue.c:47
#8 0x00007f75deb00a94 in poll_disp_fds (n_fd=<optimized out>) at ./src/core/select.c:419
#9 _osmo_select_main (polling=polling@entry=0) at ./src/core/select.c:457
#10 0x00007f75deb00ba6 in osmo_select_main_ctx (polling=polling@entry=0) at ./src/core/select.c:513
#11 0x0000562ca98dc6e2 in main (argc=3, argv=0x7ffc2bf14318) at ./src/osmo-hnbgw/osmo_hnbgw_main.c:317
</pre>
<p>Looks like the problem is actually in libosmo-mgcp-client rather than in osmo-hnbgw?</p>
<pre>
ii libosmo-mgcp-client12:amd64 1.12.1 amd64 libosmo-mgcp-client: Osmocom's Media Gateway Control Protocol client utilities
ii libosmocore 1.9.2 amd64 Open Source MObile COMmunications CORE library (metapackage)
ii osmo-hnbgw 1.5.0 amd64 OsmoHNBGW: Osmocom Home Node B Gateway
</pre> libosmocore - Bug #6299 (Resolved): logging: segmentation fault in _output_buf()https://projects.osmocom.org/issues/62992023-12-10T07:48:08Zfixeria
<p>ttcn3-bts-test is broken for a few days. The Console Output indicates that something is wrong with the virtphy container:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2240/console">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2240/console</a></p>
<pre>
Error response from daemon: Cannot kill container: jenkins-ttcn3-bts-test-2240-virtphy: No such container: jenkins-ttcn3-bts-test-2240-virtphy
</pre>
<p>The artifacts contain a core file:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2240/artifact/logs/virtphy/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2240/artifact/logs/virtphy/</a></p>
<p>I can reproduce the problem locally, virtphy crashes immediately after being started:</p>
<pre>
(gdb) r
Starting program: /home/fixeria/projects/osmocom/bb/src/host/virt_phy/src/virtphy
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7d31468 in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7d31468 in ?? () from /usr/lib/libc.so.6
#1 0x00007ffff7d0be16 in snprintf () from /usr/lib/libc.so.6
#2 0x00007ffff7d799c7 in ?? () from /usr/lib/libc.so.6
#3 0x00007ffff7d79b2f in ctime_r () from /usr/lib/libc.so.6
#4 0x00007ffff7f67037 in _output_buf (buf=buf@entry=0x7fffffffcc90 "", buf_len=buf_len@entry=4096, target=target@entry=0x555555588140, subsys=subsys@entry=2, level=level@entry=3, file=file@entry=0x5555555643ce "virtphy.c",
line=248, cont=0, format=0x5555555643e0 "Virtual physical layer starting up...\n", ap=0x7fffffffdd00) at ../../../../src/libosmocore/src/core/logging.c:520
#5 0x00007ffff7f675de in _output (target=target@entry=0x555555588140, subsys=subsys@entry=2, level=level@entry=3, file=file@entry=0x5555555643ce "virtphy.c", line=line@entry=248, cont=cont@entry=0,
format=0x5555555643e0 "Virtual physical layer starting up...\n", ap=0x7fffffffdd00) at ../../../../src/libosmocore/src/core/logging.c:606
#6 0x00007ffff7f678ee in osmo_vlogp (subsys=<optimized out>, level=3, file=0x5555555643ce "virtphy.c", line=248, cont=0, format=0x5555555643e0 "Virtual physical layer starting up...\n", ap=0x7fffffffdd70)
at ../../../../src/libosmocore/src/core/logging.c:698
#7 0x00007ffff7f67adf in logp2 (subsys=<optimized out>, level=<optimized out>, file=<optimized out>, line=<optimized out>, cont=<optimized out>, format=<optimized out>) at ../../../../src/libosmocore/src/core/logging.c:734
#8 0x0000555555557bd8 in main (argc=1, argv=0x7fffffffdf78) at virtphy.c:248
</pre> Cellular Network Infrastructure - Bug #5635 (Resolved): ttcn3-bts-test: TC_rsl_ms_pwr_dyn_{ass_up...https://projects.osmocom.org/issues/56352022-07-27T00:24:18Zfixeria
<p>After the recent changes in osmocom-bb.git/trxcon, we started to see some new regressions. Some of them caused by the problem explained in <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Separate TDMA scheduler into a library (libtdmasched) (Resolved)" href="https://projects.osmocom.org/issues/3761">#3761</a>:</p>
<blockquote>
<ul>
<li>Sending L1 SACCH header = { 0x00, 0x00 } in cached SACCH PDUs.
<ul>
<li>You'll see "FIXME: no direct access to trx->{tx_power,ta}" during compilation.</li>
<li>Makes <code>TC_rsl_ms_pwr_dyn_{ass_updown,max}</code> and <code>TC_ms_pwr_ctrl_{constant,pf_ewma}</code> fail.</li>
</ul></li>
</ul>
</blockquote>
<p>The problem is likely in the testsuite itself, because generally we should not rely on cached measurements.</p> OsmoBTS - Bug #5518 (Rejected): osmo-bts-trx: Downlink FACCH/H scheduling is not working properlyhttps://projects.osmocom.org/issues/55182022-04-09T15:12:31Zfixeria
<p>It was reported by a customer that no voice can be heard during the emergency calls, while the normal MO/MT calls are working fine. The MS originating an emergency call indicates RxQual=7 in the RR Measurement Reports, whereas the Uplink measurements generated by the BTS indicate RxQual=0. This problem is specific to TCH/H, full rate channels are not affected.</p>
<p>The key difference from normal calls is that emergency calls are established via the <strong>early assignment</strong>: a traffic channel gets activated in signalling mode and after the call establishment it gets modified to one of the speech modes. Also, the same problem with no voice can be reproduced in a setup with no SDCCH channels - this would force the BSC to use early assignment even for the normal calls.</p>
<p>After several hours of experiments with USRP B210 and after reading the source code, I found out that scheduling of the <strong>Downlink</strong> FACCH on TCH/H is completely broken. Attached you can find a PCAP file containing A-bis/RSL traces and GSMTAP Um frames showing the problem. One can see LAPDm errors and retransmissions during the call establishment. I tried downgrading osmo-bts down to 1.2.0 (Jan 2020) without any luck.</p>
<p>A reasonable question is why didn't ttcn3-bts-test catch this? Because we use trxcon as the MS side scheduler, which was written by looking at osmo-bts-trx as the reference implementation. There can be similar bugs in there, so in this regard we're testing the implementation against itself. Most likely it needs to be fixed too.</p> Cellular Network Infrastructure - Bug #5366 (Resolved): ttcn3-{bsc,msc,sgsn,smlc,sccp}-test regre...https://projects.osmocom.org/issues/53662021-12-21T14:20:00Zfixeria
<p>Since Dec 17 2021 we started to see massive regressions in the recent test results on Jenkins:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1594/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1594/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1500/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test/1500/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sccp-test/707/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sccp-test/707/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sgsn-test/1457/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sgsn-test/1457/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-smlc-test/431/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-smlc-test/431/</a></p>
<p>Interestingly enough, -latest is generally not affected, except ttcn3-msc-test:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/1167/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/1167/</a> (+151 failures)<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/1168/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/1168/</a> (-152 failures, back to normal)<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/1169/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-msc-test-latest/1169/</a> (+152 failures)</p> OsmoBSC - Bug #5344 (Resolved): ttcn3-bsc-test: handover regressionshttps://projects.osmocom.org/issues/53442021-12-08T15:54:35Zfixeria
<p>Since recently, the following test cases constantly fail on Jenkins:</p>
<pre>
BSC_Tests.TC_srvcc_eutran_to_geran_ho_out
BSC_Tests.TC_srvcc_eutran_to_geran_ho_out_forbid_fast_return
BSC_Tests.TC_ho_out_of_this_bsc
</pre>
<p>Below are the related test reports, in which they started to fail (Nov 25):</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1572/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1572/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-latest/1151/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-latest/1151/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-bsc-test/556/">https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-bsc-test/556/</a></p>
<p>I believe this patch is somehow related to:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/26354">https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/26354</a></p>
<p>because it was merged on Nov 24, just before the tests started to fail.</p>
<p>Interestingly enough, I cannot reproduce the failures by running test cases on my machine.</p> OsmoBTS - Bug #5251 (Resolved): VAMOS: CHANnel ACTIVation on shadow timeslots is brokenhttps://projects.osmocom.org/issues/52512021-10-08T20:05:15Zfixeria
<p>Starting from <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/1432/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/1432/</a>, we see new regressions affecting all VAMOS related test cases. The problem is that osmo-bts started to NACK CHANnel ACTIVaction messages for lchans on the shadow timeslots:</p>
<pre>
(bts=0,trx=0,ts=1,shadow,pchan=TCH/F) rx chan activ but TS not in nm_state oper=ENABLED avail=OK, nack!
</pre>
<p>because they do not reflect the OML states of primary timeslots:</p>
<pre><code class="c syntaxhl"><span class="k">if</span> <span class="p">(</span><span class="n">ts</span><span class="o">-></span><span class="n">mo</span><span class="p">.</span><span class="n">nm_state</span><span class="p">.</span><span class="n">operational</span> <span class="o">!=</span> <span class="n">NM_OPSTATE_ENABLED</span> <span class="o">||</span>
<span class="n">ts</span><span class="o">-></span><span class="n">mo</span><span class="p">.</span><span class="n">nm_state</span><span class="p">.</span><span class="n">availability</span> <span class="o">!=</span> <span class="n">NM_AVSTATE_OK</span><span class="p">)</span> <span class="p">{</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DRSL</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="s">"%s rx chan activ but TS not in nm_state oper=ENABLED avail=OK, nack!</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span>
<span class="n">gsm_ts_and_pchan_name</span><span class="p">(</span><span class="n">ts</span><span class="p">));</span>
<span class="k">return</span> <span class="n">rsl_tx_chan_act_nack</span><span class="p">(</span><span class="n">lchan</span><span class="p">,</span> <span class="n">RSL_ERR_RR_UNAVAIL</span><span class="p">);</span>
<span class="p">}</span>
<span class="n">and</span> <span class="n">all</span> <span class="n">members</span> <span class="n">of</span> <span class="n">ts</span><span class="o">-></span><span class="n">mo</span><span class="p">.</span><span class="n">nm_state</span> <span class="n">are</span> <span class="n">zero</span><span class="o">-</span><span class="n">initialized</span><span class="p">.</span>
</code></pre> OsmoBTS - Bug #5248 (Resolved): Memory leaks across A-bis/RSL connectionhttps://projects.osmocom.org/issues/52482021-10-06T08:29:15Zfixeria
<p>While working on ttcn3-bts-test, I left osmo-bts running for a while and ran out of memory. Below are the biggest talloc chunks:</p>
<pre>
OsmoBTS# show talloc-context application full tree 0x608000000380
full talloc report on 'OsmoBTS context' (total 25932818 bytes in 2379 blocks)
abis contains 197460 bytes in 1481 blocks (ref 0) 0x608000000380
unixsocket contains 1 bytes in 1 blocks (ref 0) 0x60b00014f060
ipa contains 1213 bytes in 13 blocks (ref 0) 0x60b00014efb0
struct ipa_client_conn contains 202 bytes in 2 blocks (ref 0) 0x6120000501a0
127.0.1.1 contains 10 bytes in 1 blocks (ref 0) 0x60b000190350
struct ipa_client_conn contains 202 bytes in 2 blocks (ref 0) 0x6120000405a0
127.0.2.1 contains 10 bytes in 1 blocks (ref 0) 0x60b00018b0d0
struct ipa_client_conn contains 202 bytes in 2 blocks (ref 0) 0x61200003bda0
127.0.1.1 contains 10 bytes in 1 blocks (ref 0) 0x60b00018a1b0
struct ipa_client_conn contains 202 bytes in 2 blocks (ref 0) 0x61200000e920
127.0.1.1 contains 10 bytes in 1 blocks (ref 0) 0x60b000184170
struct ipa_client_conn contains 202 bytes in 2 blocks (ref 0) 0x612000029620
127.0.1.1 contains 10 bytes in 1 blocks (ref 0) 0x60b00017d6e0
struct ipa_client_conn contains 202 bytes in 2 blocks (ref 0) 0x612000018220
127.0.1.1 contains 10 bytes in 1 blocks (ref 0) 0x60b000176620
...
OsmoBTS# show talloc-context application 2 tree 0x627000000160
talloc report on 'OsmoBTS context' (total 598284656 bytes in 48753 blocks)
struct gsm_bts contains 598181420 bytes in 48417 blocks (ref 0) 0x627000000160
struct tlv_parsed contains 4131 bytes in 16 blocks (ref 0) 0x6210016a4560
struct tlv_parsed contains 4106 bytes in 3 blocks (ref 0) 0x6210016a3160
struct tlv_parsed contains 4117 bytes in 7 blocks (ref 0) 0x6210016a1d60
struct tlv_parsed contains 4116 bytes in 4 blocks (ref 0) 0x6210016a0960
struct tlv_parsed contains 4098 bytes in 3 blocks (ref 0) 0x62100169f560
...
struct gsm_bts_trx contains 111271976 bytes in 8983 blocks (ref 0) 0x7fcd7df16860
struct gsm_bts_trx contains 111271976 bytes in 8983 blocks (ref 0) 0x7fcd7e116860
struct gsm_bts_trx contains 111271976 bytes in 8983 blocks (ref 0) 0x7fcd7e316860
struct gsm_bts_trx contains 111271976 bytes in 8983 blocks (ref 0) 0x7fcd7e816860
</pre>
<a name="How-to-reproduce"></a>
<h2 >How to reproduce?<a href="#How-to-reproduce" class="wiki-anchor">¶</a></h2>
<p>In ttcn3-bts-test environment start everything except the testsuite, so that osmo-bts can establish A-bis/OML connections, but not the A-bis/RSL.</p>
<a name="Software-versions"></a>
<h2 >Software versions<a href="#Software-versions" class="wiki-anchor">¶</a></h2>
<pre>
libosmocore ca5ce0d84966c998e353b606a7054f8bc8366cae
libosmo-abis d2d28d83a437f7478a4dfff0c6cae5305801b881
osmo-bts 93fbcdfb39674eb3b5b7768919e14fbc8c455fc4
</pre> OsmoBSC - Bug #5172 (Resolved): Uplink is broken: wrong TSC is sent in RSL CHANnel ACTIVationhttps://projects.osmocom.org/issues/51722021-06-04T12:30:17Zfixeria
<p>With the recent master (<a class="external" href="https://git.osmocom.org/osmo-bsc/commit/?id=3512e3cf1b7fd16dbb476d5abf2eb9c13dcc876e">https://git.osmocom.org/osmo-bsc/commit/?id=3512e3cf1b7fd16dbb476d5abf2eb9c13dcc876e</a>) none of my phones can perform Location Updating. Access Burst still triggers SDCCH activation, but after that I see no RSL DATA.ind at all. The Uplink measurements (performed by BTS) indicate that the MS does transmit on allocated resource.</p>
<pre>
DRSL INFO abis_rsl.c:1547 (bts=0) CHAN RQD: reason: Location updating (ra=0x05, neci=0x01, chreq_reason=0x03)
DRLL DEBUG lchan_select.c:91 looking for lchan SDCCH8: (bts=0,trx=0,ts=1,pchan=SDCCH8,state=UNUSED) ss=0 is available
DRLL DEBUG lchan_select.c:269 (bts=0) lchan_select_by_type(SDCCH)
DRSL DEBUG abis_rsl.c:517 (bts=0,trx=0,ts=1,pchan=SDCCH8,state=IN_USE) Tx RSL Channel Activate with act_type=INITIAL
DRSL DEBUG abis_rsl.c:1169 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=1 meas_rep_last_seen_nr=0
DRSL DEBUG abis_rsl.c:1169 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=2 meas_rep_last_seen_nr=1
DRSL DEBUG abis_rsl.c:1169 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=3 meas_rep_last_seen_nr=2
DRSL DEBUG abis_rsl.c:1169 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=4 meas_rep_last_seen_nr=3
DRSL DEBUG abis_rsl.c:1169 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=5 meas_rep_last_seen_nr=4
DRLL DEBUG chan_alloc.c:231 (bts=0) channel load average is 3.03%
DRLL DEBUG chan_alloc.c:245 (bts=0) T3122 wait indicator set to 10 seconds
DRSL DEBUG abis_rsl.c:1169 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=6 meas_rep_last_seen_nr=5
DCHAN ERROR lchan_fsm.c:1649 lchan(0-0-1-SDCCH8-0)[0x55c95c66b480]{WAIT_RLL_RTP_ESTABLISH}: (type=SDCCH) lchan allocation failed in state WAIT_RLL_RTP_ESTABLISH: Timeout
</pre> Cellular Network Infrastructure - Bug #5112 (Resolved): osmo-gsm-manuals: build verification is b...https://projects.osmocom.org/issues/51122021-04-10T01:57:24Zfixeria
<p>Today I submitted a set of patches for osmo-gsm-manuals:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/23687">https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/23687</a> TRXD: generalze description of the 'RFU' ('PAD') field<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/23688">https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/23688</a> TRXD: clarify modulation specific length of Soft-/Hard-bits<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/22867">https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/22867</a> TRXD: add documentation for TRXDv2 protocol</p>
<p>and all of them did not pass the build verification. <a class="user active" href="https://projects.osmocom.org/users/1741">lynxis</a> also faced this problem with his:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/23393">https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/23393</a> common/chapters: extend gb/ns2 chapters</p>
<p>The build logs contain a very cryptic failure reason:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-gsm-manuals/559/a1=default,a2=default,a3=default,a4=default,label=osmocom-gerrit-debian9/console">https://jenkins.osmocom.org/jenkins/job/gerrit-osmo-gsm-manuals/559/a1=default,a2=default,a3=default,a4=default,label=osmocom-gerrit-debian9/console</a></p>
<pre>
# Do print the WARNING output but return error if any was found
# (grep -v would omit the WARNING output from the log).
asciidoc: WARNING: mgcp_extension_osmux.adoc: line 2: section title out of sequence: expected level 1, got level 2
../build/Makefile.asciidoc.inc:90: recipe for target 'test-usermanual.check' failed
make[3]: Leaving directory '/build/tests'
make[3]: *** [test-usermanual.check] Error 1
../build/Makefile.asciidoc.inc:80: recipe for target 'check' failed
</pre> Cellular Network Infrastructure - Bug #4957 (Closed): ttcn3-sip-test is broken since 15 Dec 2020https://projects.osmocom.org/issues/49572021-01-19T14:35:56Zfixeria
<p>All test cases fail under both Debian and CentOS:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test/1051/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test/1051/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-sip-test/238/">https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-sip-test/238/</a></p>
<p>Although, the 'latest' is relatively stable:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test-latest/828/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sip-test-latest/828/</a></p>
<p>I spent a few hours trying to investigate what's going on. Here are some intermediate results:</p>
<ul>
<li>Q: Did sofia-sip change?
<ul>
<li>A: No. All test cases on my machine also fail with v1.12.11 that I installed back in 2019.</li>
</ul>
</li>
<li>Q: Did the test suite change?
<ul>
<li>A: I could not find any changes that would affect the test suite behavior directly:
<ul>
<li><a class="external" href="https://gerrit.osmocom.org/q/Ib4399aa488afd917e3eda5e79d56ea3797ef7c78">https://gerrit.osmocom.org/q/Ib4399aa488afd917e3eda5e79d56ea3797ef7c78</a> - only expected-results.xml was changed,</li>
<li><a class="external" href="https://gerrit.osmocom.org/q/I37db9962f51baf2c63bd58ec47ec89f773d7a255">https://gerrit.osmocom.org/q/I37db9962f51baf2c63bd58ec47ec89f773d7a255</a> - changing code that is commended out.</li>
</ul>
</li>
</ul>
</li>
<li>Q: Did osmo-sip-connector's code change?
<ul>
<li>A: Yes, some new commits have been merged recently:
<ul>
<li><a class="external" href="https://gerrit.osmocom.org/q/Ia156010194c1f4334a4966d01aadfd02fa7097a8">https://gerrit.osmocom.org/q/Ia156010194c1f4334a4966d01aadfd02fa7097a8</a></li>
<li><a class="external" href="https://gerrit.osmocom.org/q/Ic926d192c238ef84fb3ad2be27e507e010b0e93f">https://gerrit.osmocom.org/q/Ic926d192c238ef84fb3ad2be27e507e010b0e93f</a></li>
<li><a class="external" href="https://gerrit.osmocom.org/q/Ia84602955b913a3bb13de7a6a92048799f2e1955">https://gerrit.osmocom.org/q/Ia84602955b913a3bb13de7a6a92048799f2e1955</a></li>
<li><a class="external" href="https://gerrit.osmocom.org/q/I870c16d7ee5e5424304f3c1c9fb78af418ae2577">https://gerrit.osmocom.org/q/I870c16d7ee5e5424304f3c1c9fb78af418ae2577</a></li>
</ul>
</li>
<li>... downgrading before them does not change anything though :/
<ul>
<li>tried I17e1adac40ac01daee0dd83da0a6aaebd78ea0dc and I3b1bebbcc9e36be43d8d055c8d28cbb38ff21b37</li>
</ul>
</li>
</ul>
</li>
<li>Q: Did libosmocore's code change?
<ul>
<li>A: Needs to be investigated.
<ul>
<li>I tried downgrading to I781ab838bd02ac1b13d384ce3f4259e26cedb61e => nothing changed.</li>
</ul></li>
</ul></li>
</ul>
<p>The test cases fail due to DTEs listed below:</p>
<ul>
<li>"MNCC_CodecPort.ttcn:19 Dynamic test case error: Initializing a variable of enumerated type @MNCC_Types.MNCC_MsgType with invalid numeric value 346140544. (No such file or directory)" </li>
<li>"Dynamic test case error: SIP Test Port: syntax error "v" -> unexpected character at character position 1." </li>
<li>"MNCC_Emulation.ttcn:348 Dynamic test case error: Write error (Broken pipe)"</li>
</ul>
<p>Sometimes it's one reason, sometimes another. Sometimes there is no DTE but "timeout of Tguard". Weird.</p> OsmoBTS - Bug #4709 (Resolved): osmo-bts-trx (latest version 1.2.1) crashes in ttcn3-bts-test-latesthttps://projects.osmocom.org/issues/47092020-08-13T07:34:38Zfixeria
<p>Looking at the build artifacts of <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/</a>, I noticed that almost all of them (at least since build#647, Jul 15, 2020) contain cordumps of osmo-bts-trx.</p>
<pre>
(gdb) bt
#0 e1inp_line_put (line=0x0) at e1_input.c:430
#1 0x00007f88e0342d95 in e1inp_sign_link_destroy (link=0x563a8c4be690) at e1_input.c:570
#2 0x0000563a8b6a02fe in sign_link_down (line=<optimized out>) at abis.c:165
#3 0x00007f88e0346dd8 in ipa_client_read (link=<optimized out>) at input/ipa.c:68
#4 ipa_client_fd_cb (ofd=<optimized out>, what=<optimized out>) at input/ipa.c:136
#5 0x00007f88dfa8b0bf in osmo_fd_disp_fds (_eset=<optimized out>, _wset=<optimized out>, _rset=<optimized out>) at select.c:227
#6 _osmo_select_main (polling=polling@entry=0) at select.c:265
#7 0x00007f88dfa8b736 in osmo_select_main (polling=polling@entry=0) at select.c:274
#8 0x0000563a8b69e884 in bts_main (argc=5, argv=0x7ffcc3a7a428) at main.c:354
#9 0x00007f88df2df2e1 in __libc_start_main (main=0x563a8b675d00 <main>, argc=5, argv=0x7ffcc3a7a428, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7ffcc3a7a418) at ../csu/libc-start.c:291
#10 0x0000563a8b675d3a in _start ()
</pre>
<p>Package versions:</p>
<pre>
Package: libosmocore-dev
Version: 1.3.2
Package: libosmo-abis-dev
Version: 0.8.1
Package: osmo-bts
Version: 0.4.0-2
</pre>
<p>I assume it has been fixed in the recent master, as we don't see any coredumps in ttcn3-bts-test (master).</p> Cellular Network Infrastructure - Bug #4662 (Resolved): ttcn3-bts-test: both TC_si_sched_13_2bis_...https://projects.osmocom.org/issues/46622020-07-10T17:58:38Zfixeria
<p>Both test cases are broken since build#949 [1][2]:</p>
<pre>
Dynamic test case error: While RAW-decoding type '@GSM_SystemInformation.SystemInformation':
There is not enough bits in the buffer to decode type @GSM_RestOctets.UTRAN_GPRSMeasParamsDescOpt.presence.
</pre>
<p>I think this regression is caused by [3]. The problem is that in ttcn3-bts-test, SI2quater contains a list of UTRAN neighbor cells, that is currently not implemented in <em>SI2quaterRestOctets</em>. The coding of this list is quite complex (more complex than the E-ARFCN list), and would probably require us to implement some parts in C++. As a quick work around, we could avoid calling <em>dec_SystemInformation()</em> on SI2quater in f_l1_sample_si().</p>
<p>[1] <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/</a><br />[2] <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/artifact/logs/bts-tester/BTS_Tests.TC_si_sched_13_2bis_2ter_2quater.merged">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/artifact/logs/bts-tester/BTS_Tests.TC_si_sched_13_2bis_2ter_2quater.merged</a><br />[3] <a class="external" href="https://gerrit.osmocom.org/q/I879c37eb51ece55d79346c6bf1a4951c3f11c77e">https://gerrit.osmocom.org/q/I879c37eb51ece55d79346c6bf1a4951c3f11c77e</a></p> OsmoBSC - Bug #4624 (Resolved): osmo-bsc leaks memoryhttps://projects.osmocom.org/issues/46242020-06-19T19:23:32Zfixeria
<p>While investigating <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: ttcn3-bsc-test: all LCLS test cases broken since build #987 (Resolved)" href="https://projects.osmocom.org/issues/4619">#4619</a>, I noticed that osmo-bsc (or libosmo-abis?) leaks memory.</p>
<p>Before running LCLS test cases:</p>
<pre>
OsmoBSC# show talloc-context application brief
talloc report on 'osmo-bsc' (total 914581 bytes in 584 blocks)
telnet_connection contains 89 bytes in 2 blocks (ref 0) 0x561a66e7a910
0.0.0.0 contains 8 bytes in 1 blocks (ref 0) 0x561a66e9a420
struct osmo_ss7_instance contains 3452 bytes in 28 blocks (ref 0) 0x561a66e7b6a0
struct cmd_element contains 122 bytes in 2 blocks (ref 0) 0x561a66e3c3a0
struct cmd_element contains 123 bytes in 2 blocks (ref 0) 0x561a66e3b410
struct cmd_element contains 121 bytes in 2 blocks (ref 0) 0x561a66e38860
../../../../src/libosmocore/src/vty/utils.c:353 contains 168 bytes in 1 blocks (ref 0) 0x561a66c6fd10
../../../../src/libosmocore/src/vty/utils.c:353 contains 56 bytes in 1 blocks (ref 0) 0x561a66c6fc70
../../../../src/libosmocore/src/vty/utils.c:353 contains 495 bytes in 1 blocks (ref 0) 0x561a66c6fa10
../../../../src/libosmocore/src/vty/utils.c:353 contains 130 bytes in 1 blocks (ref 0) 0x561a66c5a120
abis contains 193781 bytes in 24 blocks (ref 0) 0x561a66c54630 // <--- check
struct gsm_network contains 709584 bytes in 488 blocks (ref 0) 0x561a66c53080
logging contains 5971 bytes in 11 blocks (ref 0) 0x561a66c52880
counter contains 0 bytes in 1 blocks (ref 0) 0x561a66c52810
subch_txq_entry contains 0 bytes in 1 blocks (ref 0) 0x561a66c527a0
bs11_file_list_entry contains 0 bytes in 1 blocks (ref 0) 0x561a66c52730
paging_request contains 0 bytes in 1 blocks (ref 0) 0x561a66c526c0
xua_msg contains 0 bytes in 1 blocks (ref 0) 0x561a66c52650
osmo_signal contains 480 bytes in 13 blocks (ref 0) 0x561a66c525e0
msgb contains 0 bytes in 1 blocks (ref 0) 0x561a66c52570
</pre>
<p>After running LCLS test cases:</p>
<pre>
OsmoBSC# show talloc-context application brief
talloc report on 'osmo-bsc' (total 1659989 bytes in 723 blocks)
telnet_connection contains 89 bytes in 2 blocks (ref 0) 0x560e7f96c910
0.0.0.0 contains 8 bytes in 1 blocks (ref 0) 0x560e7f98dcc0
struct osmo_ss7_instance contains 5326 bytes in 36 blocks (ref 0) 0x560e7f97af50
struct cmd_element contains 122 bytes in 2 blocks (ref 0) 0x560e7f92e3a0
struct cmd_element contains 123 bytes in 2 blocks (ref 0) 0x560e7f92d410
struct cmd_element contains 121 bytes in 2 blocks (ref 0) 0x560e7f92a860
../../../../src/libosmocore/src/vty/utils.c:353 contains 168 bytes in 1 blocks (ref 0) 0x560e7f761d10
../../../../src/libosmocore/src/vty/utils.c:353 contains 56 bytes in 1 blocks (ref 0) 0x560e7f761c70
../../../../src/libosmocore/src/vty/utils.c:353 contains 495 bytes in 1 blocks (ref 0) 0x560e7f761a10
../../../../src/libosmocore/src/vty/utils.c:353 contains 130 bytes in 1 blocks (ref 0) 0x560e7f74c120
abis contains 869141 bytes in 66 blocks (ref 0) 0x560e7f746630 // <--- check
struct gsm_network contains 777226 bytes in 570 blocks (ref 0) 0x560e7f745080
logging contains 6503 bytes in 18 blocks (ref 0) 0x560e7f744880
counter contains 0 bytes in 1 blocks (ref 0) 0x560e7f744810
subch_txq_entry contains 0 bytes in 1 blocks (ref 0) 0x560e7f7447a0
bs11_file_list_entry contains 0 bytes in 1 blocks (ref 0) 0x560e7f744730
paging_request contains 0 bytes in 1 blocks (ref 0) 0x560e7f7446c0
xua_msg contains 0 bytes in 1 blocks (ref 0) 0x560e7f744650
osmo_signal contains 480 bytes in 13 blocks (ref 0) 0x560e7f7445e0
msgb contains 0 bytes in 1 blocks (ref 0) 0x560e7f744570
</pre>
<p>Here is a full report on the 'abis' chink:</p>
<pre>
OsmoBSC# show talloc-context application full tree 0x560e7f746630
full talloc report on 'osmo-bsc' (total 1659989 bytes in 723 blocks)
abis contains 869141 bytes in 66 blocks (ref 0) 0x560e7f746630
unixsocket contains 1 bytes in 1 blocks (ref 0) 0x560e7f746880
ipa contains 820273 bytes in 56 blocks (ref 0) 0x560e7f746810
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa80dc0
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa73d20
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa68040
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa5c360
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa50680
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa449a0
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa38cc0
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa2bc20
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa1ff40
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa14260
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7fa08580
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7f9f6500
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7f9ea820
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7f9deb40
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7f9c9550
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7f9b26b0
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct e1inp_line contains 48240 bytes in 3 blocks (ref 0) 0x560e7f9a3380
reference to: struct ipaccess_line
reference to: ../../../src/libosmocore/src/rate_ctr.c:234
struct ipa_server_link contains 96 bytes in 2 blocks (ref 0) 0x560e7f97bb30
0.0.0.0 contains 8 bytes in 1 blocks (ref 0) 0x560e7f99fb90
struct ipa_server_link contains 96 bytes in 2 blocks (ref 0) 0x560e7f97ba70
0.0.0.0 contains 8 bytes in 1 blocks (ref 0) 0x560e7f985340
e1inp contains 48867 bytes in 8 blocks (ref 0) 0x560e7f7466a0
struct e1inp_line contains 48673 bytes in 3 blocks (ref 0) 0x560e7f96f050
struct ipaccess_line contains 1 bytes in 1 blocks (ref 17) 0x560e7f96d020
../../../src/libosmocore/src/rate_ctr.c:234 contains 432 bytes in 1 blocks (ref 17) 0x560e7f97ad30
e1inp_sign_link contains 193 bytes in 4 blocks (ref 0) 0x560e7f746710
struct e1inp_sign_link contains 64 bytes in 1 blocks (ref 0) 0x560e7f9c8520
struct e1inp_sign_link contains 64 bytes in 1 blocks (ref 0) 0x560e7f97b6a0
struct e1inp_sign_link contains 64 bytes in 1 blocks (ref 0) 0x560e7f97b7d0
</pre>
<p>Assigning to <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> (as discussed) since he was been working on reference counting recently.<br />Please see a capture file (containing GSMTAP logs, all debug) attached.</p> Cellular Network Infrastructure - Bug #4619 (Resolved): ttcn3-bsc-test: all LCLS test cases broke...https://projects.osmocom.org/issues/46192020-06-17T09:14:40Zfixeria
<p>Check out <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/test_results_analyzer/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/test_results_analyzer/</a>.</p>
<p>This is probably related to my recent IPA/RSL emulation refactoring changes:</p>
<blockquote>
<p>Changes<br />1. centos-repo-install-test: new image (detail)<br />2. debian-repo-install-test: move scripts to osmo-ci (detail)<br />3. ttcn3-bts-test: enable 3 additional transceivers for BTS#0 (detail)</p>
</blockquote>
<p>Here is an extract from the build artifacts of build#987:</p>
<pre>
06:26:01.572279 921 RSL_Emulation.ttcn:556 Matching on port IPA_PT succeeded: matched
06:26:01.572304 921 RSL_Emulation.ttcn:556 Receive operation on port IPA_PT succeeded, message from IPA0-RSL-IPA(920): @IPA_Emulation.ASP_RSL_Unitdata : { conn_id := 1,
streamId := IPAC_PROTO_RSL_TRX0 (0), rsl := { msg_disc := { msg_group := RSL_MDISC_IPACCESS (63), transparent := false }, msg_type := RSL_MT_IPAC_CRCX (112), ies := { {
iei := RSL_IE_CHAN_NR (1), body := { chan_nr := { u := { ch0 := RSL_CHAN_NR_Bm_ACCH (1) }, tn := 2 } } }, { iei := RSL_IE_IPAC_SPEECH_MODE (244), body := { ipa_speech_mo
de := { reserved := '00'B, mode := RSL_IPA_SPM_RECVONLY (1), codec := RSL_IPA_CODEC_FR (0) } } }, { iei := RSL_IE_IPAC_RTP_PAYLOAD (242), body := { ipa_rtp_pt := 3 } } }
} } id 27
06:26:01.572325 921 RSL_Emulation.ttcn:556 Message with id 27 was extracted from the queue of IPA_PT.
06:26:01.572351 921 RSL_Emulation.ttcn:199 No Dchan handler for 0{ u := { ch0 := RSL_CHAN_NR_Bm_ACCH (1) }, tn := 2 }
06:26:01.572469 923 MSC_ConnectionHandler.ttcn:784 dec_PDU_ML3_NW_MS(): Decoded @MobileL3_Types.PDU_ML3_NW_MS: { discriminator := '0110'B, tiOrSkip := { skipIndicator :=
'0000'B }, msgs := { rrm := { assignmentCommand := { messageType := '00101110'B, descrOf1stChAfterTime := { timeslotNumber := '010'B, channelTypeandTDMAOffset := '00001
'B, octet3 := '43'O ("C"), octet4 := '67'O ("g") }, PowerCommand := { powerlevel := '00111'B, fPC_EP := '0'B, ePC_Mode := '0'B, spare_1 := '0'B }, frequencyList_at := om
it, cellChannelDescr := omit, descrMultislotAllocation := omit, modeOf1stChannel := { elementIdentifier := '63'O ("c"), mode := '01'O }, channelSet2 := omit, channelSet3
:= omit, channelSet4 := omit, channelSet5 := omit, channelSet6 := omit, channelSet7 := omit, channelSet8 := omit, descrOf2ndChAfterTime := omit, modeOf2ndChannel := omi
t, mobileAllocation_at := omit, startingTime := omit, frequencyList_bt := omit, descrOf1stCh_bt := omit, descrOf2ndCh_bt := omit, frequencyChannelSequence := omit, mobil
eAllocation_bt := omit, cipherModeSetting := omit, vGCS_TargetModeIndication := omit, multiRateConfiguration := omit, vGCS_Ciphering_Parameters := omit, extendedTSCSet_a
fterTime := omit, extendedTSCSet_beforeTime := omit } } } }
06:26:01.572471 921 RSL_Emulation.ttcn:563 setverdict(fail): none -> fail reason: "RSL for unknown Dchan", new component reason: "RSL for unknown Dchan"
06:26:01.572505 921 RSL_Emulation.ttcn:564 Stopping MTC. The current test case will be terminated.
06:26:01.572526 921 RSL_Emulation.ttcn:564 Stopping test component execution.
</pre>
<p>Note that ttcn3-bsc-test-latest is not affected.</p> OsmoBTS - Bug #4501 (Resolved): osmo-bts-{sysmo,oc2g,litecell15}: Packet Control Ack (in form of ...https://projects.osmocom.org/issues/45012020-04-18T11:13:42Zfixeria
<p>As was reported by <a class="user active" href="https://projects.osmocom.org/users/4282">keith</a> (originally in <a class="issue tracker-2 status-7 priority-2 priority-default" title="Feature: Acquire/update timing advance (TA) (Stalled)" href="https://projects.osmocom.org/issues/1526">#1526</a>), with 'gprs control-ack-type-rach' enabled in the BSC, osmo-pcu logs:</p>
<pre>
DL1IF <0001> ../../git/src/osmo-bts-sysmo/sysmo_l1_if.c:251 Rx PH-RA.ind for unknown L1 SAPI PRACH
</pre>
<p>this is a regression introduced in I482d60a46b9d253dfe0b16140eac9fea6420b30c:</p>
<pre>
Parent: 17954da5 (pcuif_proto.h: extend RACH.ind with TRX / TS numbers)
Author: Vadim Yanitskiy <axilirator@gmail.com>
AuthorDate: 2019-10-05 23:45:31 +0700
Commit: Vadim Yanitskiy <axilirator@gmail.com>
CommitDate: 2019-11-23 17:42:45 +0700
PTCCH: properly handle RACH.ind for PCU_IF_SAPI_PTCCH
Change-Id: I482d60a46b9d253dfe0b16140eac9fea6420b30c
Related: OS#1545
</pre>
<p>I would expect <strong>Packet Control Ack</strong> on <em>GsmL1_Sapi_Pdtch</em> or rather on <em>GsmL1_Sapi_Pacch</em>, but apparently (for some magic reason) it arrives on <em>GsmL1_Sapi_Prach</em>.</p>
<p>According to 3GPP TS 45.002, section 3.3.3.2.1:</p>
<ul>
<li>PRACH stands for Packet Random Access CHannel,</li>
<li>used to request assignment of one or several PDTCHs,</li>
<li>belongs to Packet Common Control Channel (PCCCH)!</li>
</ul>
<p>Therefore the Packet Control Ack has nothing to do with PRACH. Neither we support PCCCH (it has been deprecated by the specifications).</p>
<pre><code class="c syntaxhl"><span class="n">GsmL1_LogChComb_XIII</span> <span class="c1">///< PDTCH/F + PACCH/F + PTCCH/F</span>
</code></pre>
<p>This odd behaviour seems to be caused by the following code (see <a class="issue tracker-1 status-7 priority-2 priority-default" title="Bug: osmo-bts-{sysmo,oc2g,litecell15}: PTCCH/U is not enabled on PDCH timeslots (Stalled)" href="https://projects.osmocom.org/issues/4500">#4500</a>):</p>
<pre><code class="c syntaxhl"><span class="k">static</span> <span class="k">const</span> <span class="k">struct</span> <span class="n">sapi_dir</span> <span class="n">pdtch_sapis</span><span class="p">[]</span> <span class="o">=</span> <span class="p">{</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Pdtch</span><span class="p">,</span> <span class="n">GsmL1_Dir_TxDownlink</span> <span class="p">},</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Pdtch</span><span class="p">,</span> <span class="n">GsmL1_Dir_RxUplink</span> <span class="p">},</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Ptcch</span><span class="p">,</span> <span class="n">GsmL1_Dir_TxDownlink</span> <span class="p">},</span>
<span class="p">{</span> <span class="n">GsmL1_Sapi_Prach</span><span class="p">,</span> <span class="n">GsmL1_Dir_RxUplink</span> <span class="p">},</span> <span class="c1">// <-- ?!?</span>
<span class="c">#if 0
{ GsmL1_Sapi_Ptcch, GsmL1_Dir_RxUplink },
{ GsmL1_Sapi_Pacch, GsmL1_Dir_TxDownlink }, // <-- ?!?
#endif
</span><span class="p">};</span>
</code></pre>
<p>where we enable <em>GsmL1_Sapi_Prach</em> on <em>GsmL1_LogChComb_XIII</em> (again, there is no PRACH in XIII). I guess we should enable <em>GsmL1_Sapi_Pacch</em> on direction <em>GsmL1_Dir_RxUplink</em> instead.</p>
<p>For now I submitted a blind fix: <a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/17669">https://gerrit.osmocom.org/c/osmo-pcu/+/17669</a>. Let's keep it WIP for now.</p> libosmocore - Bug #4388 (Resolved): bitvec: bitvec_read_field() can never return negative value o...https://projects.osmocom.org/issues/43882020-02-04T20:53:58Zfixeria
<p>The doxygen documentation of bitvec_read_field() tells us that it can return a negative on error:</p>
<pre><code class="c syntaxhl"><span class="cm">/*! read part of the vector
* \param[in] bv The boolean vector to work on
* \param[in,out] read_index Where reading supposed to start in the vector
* \param[in] len How many bits to read from vector
* \returns read bits or *negative value on error*
*/</span>
<span class="kt">uint64_t</span> <span class="nf">bitvec_read_field</span><span class="p">(</span><span class="k">struct</span> <span class="n">bitvec</span> <span class="o">*</span><span class="n">bv</span><span class="p">,</span> <span class="kt">unsigned</span> <span class="kt">int</span> <span class="o">*</span><span class="n">read_index</span><span class="p">,</span> <span class="kt">unsigned</span> <span class="kt">int</span> <span class="n">len</span><span class="p">)</span> <span class="p">{</span> <span class="p">...</span> <span class="p">}</span>
</code></pre>
<p>However, as can be seen its return value is unsigned - uint64_t. So actually it returns a huge number on error.</p>
<p>This can be seen in the logs of OsmoPCU:</p>
<pre>| Padding = 22|86|86|86|86|18446744073709551594|</pre>
<p>where 18446744073709551594 is basically a negative number casted to uint64_t.</p> OsmoMSC - Bug #4340 (Resolved): Malformed MM Identity Response crashes OsmoMSChttps://projects.osmocom.org/issues/43402019-12-27T22:19:57Zfixeria
<p>From time to time we receive a MM Identity Response that crashes OsmoMSC:</p>
<pre>
(gdb) bt
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f8ec198c5fe in __GI_abort () at abort.c:100
#2 0x00007f8ec2016210 in osmo_panic_default (args=0x7ffe75e09f88, fmt=0x558dc6301189 "Assert failed %s %s:%d\n") at ../../../src/libosmocore/src/panic.c:49
#3 osmo_panic (fmt=fmt@entry=0x558dc6301189 "Assert failed %s %s:%d\n") at ../../../src/libosmocore/src/panic.c:84
#4 0x0000558dc62f9181 in vlr_subscr_rx_id_resp (vsub=vsub@entry=0x558dc81738e0, mi=mi@entry=0x558dc811f196 "\377\377\377\377\377\377\377\377", mi_len=mi_len@entry=8)
at ../../../../src/osmo-msc/src/libvlr/vlr.c:1189
#5 0x0000558dc62ea90e in mm_rx_id_resp (msg=<optimized out>, msc_a=<optimized out>) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08.c:197
#6 gsm0408_rcv_mm (msc_a=<optimized out>, msg=<optimized out>) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08.c:1086
#7 0x0000558dc62c31cc in msc_a_ran_dec_from_msc_i (msc_a=msc_a@entry=0x558dc8130060, d=d@entry=0x7ffe75e0ace0) at ../../../../src/osmo-msc/src/libmsc/msc_a.c:1484
#8 0x0000558dc62c3cde in msc_a_ran_decode_cb (msc_a_fi=<optimized out>, data=0x7ffe75e0ace0, msg=0x7ffe75e0a750) at ../../../../src/osmo-msc/src/libmsc/msc_a.c:1643
#9 0x0000558dc62d0dde in ran_a_decode_l3 (ran_dec=<optimized out>, l3=<optimized out>) at ../../../../src/osmo-msc/src/libmsc/ran_msg_a.c:884
#10 0x0000558dc62c09d6 in msc_role_ran_decode (fi=0x558dc8127cb0, an_apdu=an_apdu@entry=0x7ffe75e0b370, decode_cb=decode_cb@entry=0x558dc62c3be0 <msc_a_ran_decode_cb>,
decode_cb_data=decode_cb_data@entry=0x7ffe75e0ace0) at ../../../../src/osmo-msc/src/libmsc/msub.c:589
#11 0x0000558dc62c179a in msc_a_ran_dec (msc_a=0x558dc8130060, an_apdu=0x7ffe75e0b370, from_role=<optimized out>) at ../../../../src/osmo-msc/src/libmsc/msc_a.c:184
#12 0x00007f8ec200eaf9 in _osmo_fsm_inst_dispatch (fi=0x558dc8127cb0, event=9, data=0x7ffe75e0b370, file=0x558dc630de00 "../../../../src/osmo-msc/src/libmsc/msc_i.c",
line=85) at ../../../src/libosmocore/src/fsm.c:877
#13 0x0000558dc62d0dde in ran_a_decode_l3 (ran_dec=<optimized out>, l3=<optimized out>) at ../../../../src/osmo-msc/src/libmsc/ran_msg_a.c:884
#14 0x0000558dc62c09d6 in msc_role_ran_decode (fi=0x558dc81268a0, an_apdu=0x7ffe75e0b370, decode_cb=<optimized out>, decode_cb_data=<optimized out>)
at ../../../../src/osmo-msc/src/libmsc/msub.c:589
--Type <RET> for more, q to quit, c to continue without paging--
#15 0x00007f8ec200eaf9 in _osmo_fsm_inst_dispatch (fi=0x558dc81268a0, event=event@entry=9, data=data@entry=0x7ffe75e0b370,
file=file@entry=0x558dc63129b8 "../../../../src/osmo-msc/src/libmsc/ran_peer.c", line=line@entry=412) at ../../../src/libosmocore/src/fsm.c:877
#16 0x0000558dc62d5bcd in ran_peer_st_ready (fi=<optimized out>, event=2, data=0x7ffe75e0b430) at ../../../../src/osmo-msc/src/libmsc/ran_peer.c:412
#17 0x00007f8ec200eaf9 in _osmo_fsm_inst_dispatch (fi=0x558dc8118ad0, event=2, data=data@entry=0x7ffe75e0b430,
file=file@entry=0x558dc63129b8 "../../../../src/osmo-msc/src/libmsc/ran_peer.c", line=line@entry=596) at ../../../src/libosmocore/src/fsm.c:877
#18 0x0000558dc62d69b5 in ran_peer_up_l2 (sri=0x558dc8114750, calling_addr=0x0, co=<optimized out>, conn_id=<optimized out>, l2=<optimized out>)
at ../../../../src/osmo-msc/src/libmsc/ran_peer.c:596
#19 0x0000558dc62ad606 in sccp_ran_sap_up (oph=0x558dc811f088, _scu=<optimized out>) at ../../../../src/osmo-msc/src/libmsc/sccp_ran.c:110
#20 0x00007f8ec200eaf9 in _osmo_fsm_inst_dispatch (fi=0x558dc817e4f0, event=11, data=data@entry=0x558dc8122a90,
file=file@entry=0x7f8ec1da6e08 "../../../src/libosmo-sccp/src/sccp_scoc.c", line=line@entry=1677) at ../../../src/libosmocore/src/fsm.c:877
#21 0x00007f8ec1d950bc in sccp_scoc_rx_from_scrc (inst=inst@entry=0x558dc8118310, xua=xua@entry=0x558dc8122a90) at ../../../src/libosmo-sccp/src/sccp_scoc.c:1677
#22 0x00007f8ec1d92b1e in scrc_rx_mtp_xfer_ind_xua (inst=inst@entry=0x558dc8118310, xua=0x558dc8122a90) at ../../../src/libosmo-sccp/src/sccp_scrc.c:457
#23 0x00007f8ec1d95ccd in mtp_user_prim_cb (oph=0x558dc8180a98, ctx=0x558dc8118310) at ../../../src/libosmo-sccp/src/sccp_user.c:176
#24 0x00007f8ec1d8d62d in m3ua_rx_xfer (xua=0x558dc81824b0, asp=0x558dc811eb00) at ../../../src/libosmo-sccp/src/m3ua.c:586
#25 m3ua_rx_msg (asp=asp@entry=0x558dc811eb00, msg=msg@entry=0x558dc817fd20) at ../../../src/libosmo-sccp/src/m3ua.c:739
#26 0x00007f8ec1d9cc83 in xua_cli_read_cb (conn=0x558dc811c130) at ../../../src/libosmo-sccp/src/osmo_ss7.c:1701
#27 0x00007f8ec1fd5d93 in osmo_stream_cli_read (cli=0x558dc811c130) at ../../../src/libosmo-netif/src/stream.c:222
#28 osmo_stream_cli_fd_cb (ofd=<optimized out>, what=1) at ../../../src/libosmo-netif/src/stream.c:311
#29 0x00007f8ec200a25a in osmo_fd_disp_fds (_eset=<optimized out>, _wset=<optimized out>, _rset=<optimized out>) at ../../../src/libosmocore/src/select.c:227
#30 _osmo_select_main (polling=<optimized out>) at ../../../src/libosmocore/src/select.c:265
#31 0x00007f8ec200a826 in osmo_select_main_ctx (polling=<optimized out>) at ../../../src/libosmocore/src/select.c:291
#32 0x0000558dc62abfe3 in main (argc=<optimized out>, argv=0x7ffe75e0ba48) at ../../../../src/osmo-msc/src/osmo-msc/msc_main.c:729
</pre>
<p>the message contains invalid Mobile Identity:</p>
<pre>
(gdb) p mi_len
$8 = 8
(gdb) x/2 mi
0x558dc811f196: 0xffffffff 0xffffffff
</pre>
<p>basically all bytes are 0xff.</p> libosmocore - Bug #4025 (Resolved): gsm48_decode_bcd_number2(): incorrect output buffer truncationhttps://projects.osmocom.org/issues/40252019-05-25T13:23:27Zfixeria
<p>For some reason, OsmoMSC truncates 15-digit long MSISDNs to 14 digits.</p>
<a name="How-to-reproduce"></a>
<h2 >How to reproduce?<a href="#How-to-reproduce" class="wiki-anchor">¶</a></h2>
<ul>
<li>Create a subscriber with a 15-digit long MSISDN (e.g. 123456789012345)</li>
<li>Perform Location Update</li>
</ul>
<pre>
DRR DEBUG ran_peer.c:596 ran_peer(GERAN-A:RI-SSN_PC:PC-0-23-3:SSN-BSSAP)[0x18c5680]{READY}: Received Event RAN_PEER_EV_MSG_UP_CO_INITIAL
DRLL DEBUG msc_a.c:1165 msc_a(unknown:GERAN-A-4:NONE)[0x18dfb30]{MSC_A_ST_VALIDATE_L3}: Dispatching 04.08 message: MM GSM48_MT_MM_LOC_UPD_REQUEST
DMM DEBUG gsm_04_08.c:337 msc_a(IMSI-262073993158656:GERAN-A-4:LU)[0x18dfb30]{MSC_A_ST_VALIDATE_L3}: LOCATION UPDATING REQUEST: MI=IMSI-262073993158656 LU-type=NORMAL
DMM DEBUG gsm_04_08.c:380 msc_a(IMSI-262073993158656:GERAN-A-4:LU)[0x18dfb30]{MSC_A_ST_VALIDATE_L3}: USIM: old LAI: 262-07-0
DVLR DEBUG fsm.c:423 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: Allocated
DVLR DEBUG fsm.c:453 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: is child of msc_a(IMSI-262073993158656:GERAN-A-4:LU)[0x18dfb30]
DVLR DEBUG vlr_lu_fsm.c:1525 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: rev=GSM net=GERAN (no Auth)
DVLR DEBUG vlr_lu_fsm.c:1531 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: Received Event VLR_ULA_E_UPDATE_LA
DVLR DEBUG vlr.c:435 set IMSI on subscriber; IMSI=262073993158656 id=262073993158656
DVLR INFO vlr.c:386 New subscr, IMSI: 262073993158656
DVLR DEBUG vlr_lu_fsm.c:933 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: vlr_loc_upd_node1_pre()
DVLR DEBUG vlr_lu_fsm.c:910 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: vlr_loc_upd_node1()
DVLR DEBUG vlr_lu_fsm.c:864 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: vlr_loc_upd_post_auth()
DVLR DEBUG vlr_lu_fsm.c:831 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: vlr_loc_upd_post_ciph()
DVLR DEBUG vlr_lu_fsm.c:792 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: vlr_loc_upd_node_4()
DVLR DEBUG vlr_lu_fsm.c:801 vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_IDLE}: State change to VLR_ULA_S_WAIT_HLR_UPD (T0, 30s)
DVLR DEBUG fsm.c:423 upd_hlr_vlr_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e1c20]{UPD_HLR_VLR_S_INIT}: Allocated
DVLR DEBUG fsm.c:453 upd_hlr_vlr_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e1c20]{UPD_HLR_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e18d0]
DVLR DEBUG vlr_lu_fsm.c:176 upd_hlr_vlr_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e1c20]{UPD_HLR_VLR_S_INIT}: Received Event UPD_HLR_VLR_E_START
DVLR DEBUG vlr_lu_fsm.c:87 upd_hlr_vlr_fsm(IMSI-262073993158656:GERAN-A-4:LU)[0x18e1c20]{UPD_HLR_VLR_S_INIT}: State change to UPD_HLR_VLR_S_WAIT_FOR_DATA (T0, 30s)
DVLR DEBUG vlr.c:778 IMSI:262073993158656 has MSISDN:12345678901234
DVLR NOTICE gsm_04_08.c:1364 SUBSCR(IMSI-262073993158656:MSISDN-12345678901234) VLR: update for IMSI=262073993158656 (MSISDN=12345678901234)
DVLR DEBUG vlr.c:879 vlr_lu_fsm(IMSI-262073993158656:MSISDN-12345678901234:GERAN-A-4:LU)[0x18e18d0]{VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_HLR_LU_RES
</pre>
<ul>
<li>Perform USSD: *#100#</li>
</ul>
<pre>
OsmocomBB# service 1 *#100#
% (MS 1)
% Service response: Your extension is 123456789012345
</pre>
<a name="Whats-happening"></a>
<h2 >What's happening?<a href="#Whats-happening" class="wiki-anchor">¶</a></h2>
<p>As can be seen, the USSD response has the correct 15-digit long MSISDN, while the logs of OsmoMSC indicate a truncated one. I also checked GSUP message flow in Wireshark:</p>
<pre>
GSUP InsertSubscriberData Request, IMSI: 262073993158656, MSISDN: 123456789012345
Message Type: InsertSubscriberData Request (16)
IE: IMSI, 262073993158656
Information Element Identifier: IMSI (1)
Information Element Length: 8
IMSI: 262073993158656
Mobile Country Code (MCC): Germany (262)
Mobile Network Code (MNC): Telefonica Germany GmbH & Co. oHG (07)
IE: MSISDN, 123456789012345
Information Element Identifier: MSISDN (8)
Information Element Length: 9
E.164 number (MSISDN): 123456789012345
Country Code: Americas (1)
IE: CN Domain
Information Element Identifier: CN Domain (40)
Information Element Length: 1
CN Domain Indicator: CS (2)
</pre>
<p>Just to be sure, I had a closer look at the encoded OSMO_GSUP_MSISDN_IE, and parsed in myself manually:</p>
<pre>
RAW payload: 08090821436587092143f5
08 - T: OSMO_GSUP_MSISDN_IE
09 - L: 0x09 == 9 octets
08 - L: 0x08 == 8 octets
21436587092143f5 - V: Encoded MSISDN
</pre>
<p>MSISDN seems to be encoded correctly, so most likely OsmoHLR is not the one to blame. Most likely, the problem is somewhere in OsmoMSC.</p> OsmoBTS - Bug #3938 (Resolved): Get Attribute Response parsing is broken: NM_ATT_SW_DESCR is ignoredhttps://projects.osmocom.org/issues/39382019-04-18T08:48:15Zfixeria
<p>For some reason, OsmoBSC doesn't parse the attribute 'NM_ATT_SW_DESCR' from 'Get Attributes Response':</p>
<pre>
DNM DEBUG <0004> abis_nm.c:1716 Get Attr (bts=0,trx=255)
DNM DEBUG <0004> abis_nm.c:1716 Get Attr (bts=0,trx=0)
...
DNM DEBUG <0004> abis_nm.c:621 OC=BTS(01) INST=(00,ff,ff): Get Attributes Response for BTS0
DNM DEBUG <0004> abis_nm.c:489 BTS0 Get Attributes Response Info: 70 bytes total with 0 unreported attributes
DNM NOTICE <0004> abis_nm.c:538 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix.
DNM NOTICE <0004> abis_nm.c:538 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix.
DNM NOTICE <0004> abis_nm.c:538 BTS0 feature 'CBCH' reported via OML does not match statically set feature: 1 != 0. Please fix.
DNM NOTICE <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix.
DNM NOTICE <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech V1' reported via OML does not match statically set feature: 1 != 0. Please fix.
DNM NOTICE <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech EFR' reported via OML does not match statically set feature: 1 != 0. Please fix.
DNM NOTICE <0004> abis_nm.c:538 BTS0 feature 'Fullrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix.
DNM NOTICE <0004> abis_nm.c:538 BTS0 feature 'Halfrate speech AMR' reported via OML does not match statically set feature: 1 != 0. Please fix.
DNM DEBUG <0004> abis_nm.c:621 OC=BTS(01) INST=(00,ff,ff): Get Attributes Response for BTS0
DNM DEBUG <0004> abis_nm.c:489 BTS0 Get Attributes Response Info: 32 bytes total with 1 unreported attributes
DNM ERROR <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is unreported
</pre>
<p>while the old OpenBSC does:</p>
<pre>
DNM DEBUG <0005> abis_nm.c:1601 Get Attr (bts=0)
DNM DEBUG <0005> abis_nm.c:1601 Get Attr (bts=0)
...
DNM DEBUG <0005> abis_nm.c:550 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response for BTS0
DNM DEBUG <0005> abis_nm.c:463 BTS0 Get Attributes Response Info: 70 bytes total with 0 unreported attributes
DNM NOTICE <0005> abis_nm.c:507 BTS0 feature 'EGPRS' reported via OML does not match statically set feature: 0 != 1. Please fix.
DNM NOTICE <0005> abis_nm.c:507 BTS0 feature 'OML Alerts' reported via OML does not match statically set feature: 1 != 0. Please fix.
DNM NOTICE <0005> abis_nm.c:507 BTS0 feature 'CBCH' reported via OML does not match statically set feature: 1 != 0. Please fix.
DNM NOTICE <0005> abis_nm.c:573 BTS0: ARI reported sw[0/2]: osmobts is 0.8.1.255-7209
DNM NOTICE <0005> abis_nm.c:446 BTS0 reported variant: omso-bts-trx
DNM DEBUG <0005> abis_nm.c:550 OC=BTS(01) INST=(00,ff,ff) Get Attributes Response for BTS0
DNM DEBUG <0005> abis_nm.c:463 BTS0 Get Attributes Response Info: 32 bytes total with 1 unreported attributes
DNM ERROR <0005> abis_nm.c:468 BTS0 Attribute Manufacturer Dependent State is unreported
DNM NOTICE <0005> abis_nm.c:573 BTS0: ARI reported sw[0/1]: TRX_PHY_VERSION is Unknown
</pre>
<p>Observed with the recent osmo-bts-trx 0.8.1.255-7209.</p>
<p>Please find the OML captures for both cases attached. I could't find any difference in both pairs of 'Get Attributes' / 'Get Attributes Response' messages. The following is my hand-parsed representation of these messages:</p>
<pre>
OML BTS(ff,ff,ff) Get Attributes
RAW: 1e41
OML BTS(00,ff,ff) Get Attributes Response
RAW (len=70): 001e000242fc421200076f736d6f62747313000e302e382e312e3235352d37323039421200104254535f545950455f56415249414e5413000c6f6d736f2d6274732d74727800
0000 00 1e 00 02 42 fc 42 12 00 07 6f 73 6d 6f 62 74 ....B.B. ..osmobt
0010 73 13 00 0e 30 2e 38 2e 31 2e 32 35 35 2d 37 32 s...0.8. 1.255-72
0020 30 39 42 12 00 10 42 54 53 5f 54 59 50 45 5f 56 09B...BT S_TYPE_V
0030 41 52 49 41 4e 54 13 00 0c 6f 6d 73 6f 2d 62 74 ARIANT.. .omso-bt
0040 73 2d 74 72 78 00 s-trx.
00 - the amount of unreported attributes
1e - NM_ATT_MANUF_ID
0002 - 2 octets
42fc - BTS supported features
42 - NM_ATT_SW_DESCR
12 - NM_ATT_FILE_ID
0007 - 7 octets
6f736d6f627473 - "osmobts"
13 - NM_ATT_FILE_VERSION
000e - 14 octets
302e382e312e3235352d37323039 - "0.8.1.255-7209"
42 - NM_ATT_SW_DESCR
12 - NM_ATT_FILE_ID
0010 - 16 octets
4254535f545950455f56415249414e54 - "BTS_TYPE_VARIANT"
13 - NM_ATT_FILE_VERSION
000c - 13 octets
6f6d736f2d6274732d74727800 - "osmo-bts-trx" + \0
OML Baseband Transceiver(00,00,ff) Get Attributes
RAW: 1c41
OML BTS(00,ff,ff) Get Attributes Response
RAW (len=32): 011c4212000f5452585f5048595f56455253494f4e130007556e6b6e6f776e00
0000 01 1c 42 12 00 0f 54 52 58 5f 50 48 59 5f 56 45 ..B...TR X_PHY_VE
0010 52 53 49 4f 4e 13 00 07 55 6e 6b 6e 6f 77 6e 00 RSION... Unknown.
01 - the amount of unreported attributes
1c - NM_ATT_MANUF_STATE
42 - NM_ATT_SW_DESCR
12 - NM_ATT_FILE_ID
000f - 15 octets
5452585f5048595f56455253494f4e - "TRX_PHY_VERSION"
13 - NM_ATT_FILE_VERSION
0007 - 7 octets (WTF?!? \0 is not accounted)
556e6b6e6f776e00 - "Unknown" + \0
</pre>
<p>I am not familiar with OML, though I found some things odd:</p>
<ul>
<li>In the first 'Get Attributes' message we ask for 0x1e - NM_ATT_MANUF_ID and 0x41 - NM_ATT_SW_CONFIG. However, instead of 0x41 - NM_ATT_SW_CONFIG we receive 0x42 - NM_ATT_SW_DESCR in the response. Same problem with the second 'Get Attributes Response' message.</li>
</ul>
<ul>
<li>In the first 'Get Attributes Response' message, 'NM_ATT_SW_DESCR' tag is present twice. Is it allowed to indicate the same tag twice?</li>
</ul>
<ul>
<li>In the first 'Get Attributes Response' message, one value of 'NM_ATT_FILE_VERSION' is \0-terminated, another is not.</li>
</ul>
<ul>
<li>In the second 'Get Attributes Response' message, the value of 'NM_ATT_FILE_VERSION' is \0-terminated, but \0 is not accounted in the TLV's length.</li>
</ul>
<ul>
<li>The secound 'Get Attributes' message is for Baseband Transceiver (00,00,ff), however the response is for BTS (00,ff,ff).</li>
</ul> OsmoBTS - Feature #3906 (Resolved): Automatically adjust LAPDm timer values with 'fn-advance' par...https://projects.osmocom.org/issues/39062019-04-06T18:19:30Zfixeria
<p>Currently we use fn-advance=20 by default, so the burst scheduler is working 20 TDMA frames in advance. This advance gives the transceiver some time to receive a burst, process it (i.e. modulate), and send to the Tx buffer of SDR. As a side effect, this increases the delay between UL and DL: 20 TDMA frames => 92.3ms of delay.</p>
<p>Higher fn-advance values cause a longer delay, resulting in LAPDm frame retransmissions.<br />OsmoBTS should automatically adjust LAPDm timer values with the configured 'fn-advance' value.</p> OsmoBTS - Bug #3506 (Closed): FACCH LAPDm sequence error (state LAPD_STATE_MF_EST)https://projects.osmocom.org/issues/35062018-08-28T10:24:51Zfixeria
<p>During a voice call (either TCH/F, or TCH/H), any FACCH activity (DTMF, call hold/retrieve) causes the following messages:</p>
<pre>
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=7, V(R)=0 (dl=0x7fa23038d478 state LAPD_STATE_MF_EST) # Key press
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=0, V(R)=1 (dl=0x7fa23038d478 state LAPD_STATE_MF_EST) # Key release
...
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=3, V(R)=4 (dl=0x7fa23038d478 state LAPD_STATE_MF_EST) # Call hold
<0004> measurement.c:563 (bts=0,trx=0,ts=2,ss=0) No measurements for SUB!!!
<0004> measurement.c:563 (bts=0,trx=0,ts=2,ss=0) No measurements for SUB!!!
<0004> measurement.c:563 (bts=0,trx=0,ts=2,ss=0) No measurements for SUB!!!
<0004> measurement.c:563 (bts=0,trx=0,ts=2,ss=0) No measurements for SUB!!!
<0011> lapd_core.c:1556 N(S) sequence error: N(S)=4, V(R)=5 (dl=0x7fa23038d478 state LAPD_STATE_MF_EST) # Call retrieve
...
</pre>
<p>osmo-bts-trx 08062e6dcc8a0d1f869a1ce0b88238c8218546c3<br />Observed with both OsmocomBB and a regular phone.</p>
<p>Please see A-bis/RSL traffic capture attached to this report.</p> Cellular Network Infrastructure - Bug #3457 (Resolved): docker-playground: repository 'laforge/de...https://projects.osmocom.org/issues/34572018-08-08T19:05:57Zfixeria
<p>There is a problem appearing when building Docker images based on 'laforge/debian-jessie-build'...</p>
<p>After building, the 'debian-jessie-build' image is being tagged according to the following rule:</p>
<pre>
$(USER)/$(IMAGE) # e.g. user/debian-jessie-build
</pre>
<p>so, <strong>if the current $(USER) != 'laforge', build fails</strong>:</p>
<pre>
make[1]: Leaving directory `/home/user/osmocom/docker-playground/debian-jessie-build'
make -C osmo-stp-master
make[1]: Entering directory `/home/user/osmocom/docker-playground/osmo-stp-master'
docker build --build-arg USER=user -t docker.io/user/osmo-stp-master:latest .
Sending build context to Docker daemon 9.216kB
Step 1/16 : FROM laforge/debian-jessie-build
repository laforge/debian-jessie-build not found: does not exist or no pull access
make[1]: *** [docker-build] Error 1
make[1]: Leaving directory `/home/user/osmocom/docker-playground/osmo-stp-master'
make: *** [osmo-stp-master] Error 2
</pre>
<p>because <strong>there is no 'laforge/debian-jessie-build'</strong>, there are:</p>
<pre>
# docker image ls
REPOSITORY TAG IMAGE ID CREATED SIZE
user/debian-jessie-build latest 1f6421af8bfc 15 minutes ago 621MB
debian jessie 79f4bda91989 3 weeks ago 127MB
</pre>
<p>I started to think, may we parametrize the 'FROM laforge/debian-jessie-build' somehow?<br />Fortunately, yes! The following header makes the trick:</p>
<pre>
ARG USER
FROM $USER/debian-jessie-build
</pre>
<p>A change will be sent soon...</p> OsmoBTS - Feature #3428 (Resolved): Implement handling of NOPE / IDLE indications from Transceiverhttps://projects.osmocom.org/issues/34282018-07-27T20:44:06Zfixeria
<p>The following output can be observed with trxcon and FakeTRX:</p>
<pre>
Too many contiguous elapsed fn, dropping 80375
<0000> ../../../src/common/rsl.c:741 (bts=0,trx=0,ts=1,pchan=SDCCH8) (ss=0) SDCCH Tx CHAN ACT ACK
Too many contiguous elapsed fn, dropping 79538
Too many contiguous elapsed fn, dropping 16
<0011> lapd_core.c:920 Store content res. (dl=0x7f9793b90d68)
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
Too many contiguous elapsed fn, dropping 48
Too many contiguous elapsed fn, dropping 29
Too many contiguous elapsed fn, dropping 16
<0000> ../../../src/common/rsl.c:720 (bts=0,trx=0,ts=1,pchan=SDCCH8) (ss=0) SDCCH Tx CHAN REL ACK
</pre>
<p>It can be also observed with OsmoTRX, but the most of such messages<br />in this case caused by false-positive detection of bursts (i.e. noise).</p> OsmoBTS - Bug #3032 (Resolved): (Wrong?) measurement of both RSSI and ToA on TCH channelshttps://projects.osmocom.org/issues/30322018-03-05T08:01:32Zfixeria
<p>Unlike xCCH and PDTCH, where we measure both RSSI and ToA values <strong>for each</strong> burst:</p>
<pre>
// ...
/* update mask + RSSI */
*mask |= (1 << bid);
*rssi_sum += rssi;
(*rssi_num)++;
*toa256_sum += toa256;
(*toa_num)++;
// ...
/* Send uplink measurement information to L2 */
l1if_process_meas_res(l1t->trx, tn, *first_fn,
trx_chan_desc[chan].chan_nr | tn, n_errors, n_bits_total,
*rssi_sum / *rssi_num, *toa256_sum / *toa_num);
ber10k = compute_ber10k(n_bits_total, n_errors);
return _sched_compose_ph_data_ind(l1t, tn, *first_fn, chan,
l2, l2_len,
*rssi_sum / *rssi_num,
4 * (*toa256_sum) / *toa_num, 0, ber10k,
PRES_INFO_UNKNOWN);
// ...
</pre>
<p>both TCH/F and TCH/H are currently sending the measurements <strong>for the last</strong> burst:</p>
<pre>
// ...
/* Send uplink measurement information to L2 */
l1if_process_meas_res(l1t->trx, tn, *first_fn,
trx_chan_desc[chan].chan_nr|tn, n_errors, n_bits_total,
rssi, toa256);
// ...
/* FACCH */
_sched_compose_ph_data_ind(l1t, tn,
(fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME, chan,
tch_data + amr, GSM_MACBLOCK_LEN,
rssi, 4 * toa256,
0, ber10k, PRES_INFO_UNKNOWN);
// ...
return _sched_compose_tch_ind(l1t, tn,
(fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME,
chan, tch_data, rc);
</pre>
<p>Moreover, in case of FACCH carried on a TCH/H channel the ToA256 is<br />for some reason devided by 64, while in case of TCH/F it's passed as is:</p>
<pre>
/* TCH/F FACCH */
_sched_compose_ph_data_ind(l1t, tn,
(fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME, chan,
tch_data + amr, GSM_MACBLOCK_LEN,
rssi, 4 * toa256,
0, ber10k, PRES_INFO_UNKNOWN);
/* TCH/H FACCH */
_sched_compose_ph_data_ind(l1t, tn,
(fn + GSM_HYPERFRAME - 10 - ((fn % 26) >= 19)) % GSM_HYPERFRAME,
chan, tch_data + amr, GSM_MACBLOCK_LEN,
rssi, toa256/64,
0, ber10k, PRES_INFO_UNKNOWN);
</pre>
<p>And finally, on TCH channels we only attach the measurements to<br />FACCH indications, while speech frames don't have such info:</p>
<pre>
/* TCH/F FACCH */
_sched_compose_ph_data_ind(l1t, tn,
(fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME, chan,
tch_data + amr, GSM_MACBLOCK_LEN,
rssi, 4 * toa256,
0, ber10k, PRES_INFO_UNKNOWN);
// ...
/* TCH/F speech frame */
return _sched_compose_tch_ind(l1t, tn,
(fn + GSM_HYPERFRAME - 7) % GSM_HYPERFRAME,
chan, tch_data, rc);
</pre>
<p>I wish I could resolve this issue myself, but I didn't find anything<br />in GSM specifications about the BTS side measurement process...</p>
<p>According to the GSM TS 05.03, a single TCH/F frame is mapped over<br />8 bursts, while a TCH/H frame is mapped over 6 bursts. This should<br />be taken into account.</p>
<p>Any ideas are welcome.</p> libosmocore - Bug #2986 (Resolved): GNU TLS fallback: segfault on gnutls_rnd()https://projects.osmocom.org/issues/29862018-02-22T18:42:08Zfixeria
<p>According to the GNU TLS documentation, prior to 3.3.0 the library has to be<br />initialized by calling gnutls_global_init():</p>
<p><a class="external" href="https://www.gnutls.org/manual/html_node/Initialization.html">https://www.gnutls.org/manual/html_node/Initialization.html</a></p>
<p>while the recent versions are being initialized on load. This causes<br />segfault on osmo_get_rand_id() if a library version is lower than 3.3.0...</p>
<p>At the same time, in the configure.am we require gnutls >= 2.12.0.</p> GSM Audio Pocket Knife - Bug #2483 (Closed): ALSA buffer overrun causes program exithttps://projects.osmocom.org/issues/24832017-09-02T12:17:41Zfixeria
<p>When a sound device is active, data is transferred continuously between the hardware and application buffers. In the case of data capture (recording), if the application does not read the data in the buffer rapidly enough, the circular buffer is overwritten with new data. The resulting data loss is known as overrun. During playback, if the application does not pass data into the buffer quickly enough, it becomes starved for data, resulting in an error called underrun. The ALSA documentation sometimes refers to both of these conditions using the term XRUN. Properly designed applications can minimize XRUN and recover if it occurs.</p>
<p>When the buffer underrun happens, GAPK stops processing with the following message:</p>
<p>[+] PQ: Adding ALSA output (dev='default', blk_len=320)<br />[!] pq_execute(): abort, item returned -1<br />[+] Processed X frames</p>
<p>The snd_pcm_prepare() should be called to recover pcm_handle from buffer underrun state.</p> OsmoBTS - Bug #2223 (Closed): common/power_control.c: strange conditionshttps://projects.osmocom.org/issues/22232017-05-04T10:11:31Zfixeria
<p>Look at the lchan_ms_pwr_ctrl():</p>
<pre>
int lchan_ms_pwr_ctrl(struct gsm_lchan *lchan,
const uint8_t ms_power, const int rxLevel)
{
int rx;
int cur_dBm, new_dBm, new_pwr;
struct gsm_bts *bts = lchan->ts->trx->bts;
struct gsm_bts_role_bts *btsb = bts_role_bts(bts);
const enum gsm_band band = bts->band;
// ...
/*
* What is the difference between what we want and received?
* Ignore a margin that is within the range of measurement
* and MS output issues.
*/
rx = btsb->ul_power_target - rxLevel;
if (rx >= 0 && rx < 1)
return 0;
if (rx < 0 && rx > -1) // Unreachable
return 0;
// ...
}
</pre>
<blockquote>
<p>if (rx < 0 && rx > -1)</p>
</blockquote>
<p>As rx has type int, it cannot be in range (-1; 0)...</p>
<blockquote>
<p>if (rx >= 0 && rx < 1)</p>
</blockquote>
<p>Again, the only possible value here is 0.</p> libosmocore - Bug #1960 (Closed): GSM 05.03 conv_test failshttps://projects.osmocom.org/issues/19602017-03-01T08:23:19Zfixeria
<pre>
Some time ago I migrated the MCS 1-9 convolutional code definitions from OsmoBTS to libosmocore.
http://git.osmocom.org/libosmocore/commit/?id=a6b5216ab4b7acfaa2b0b9d421fc72f6153fad59
Also, recently I added the GSM 05.03 specific test (based on Tom's old patch), which covers all
convolutional code definitions: https://gerrit.osmocom.org/#/c/1628/
All codes, excluding MCS, pass the test. With MCS we have the following output:
/* ... The beginning was skipped ... */
[+] Testing: gsm0503_tch_ahs_4_75
[.] Input length : ret = 89 exp = 89 -> OK
[.] Output length : ret = 212 exp = 212 -> OK
[.] Random vector checks:
[..] Encoding / Decoding cycle : OK
[..] Encoding / Decoding cycle : OK
[..] Encoding / Decoding cycle : OK
[+] Testing: gsm0503_mcs1_dl_hdr
[.] Input length : ret = 36 exp = 36 -> OK
[.] Output length : ret = 108 exp = 108 -> OK
[.] Random vector checks:
[..] Encoding / Decoding cycle : OK
[..] Encoding / Decoding cycle : OK
[..] Encoding / Decoding cycle : OK
[+] Testing: gsm0503_mcs1_ul_hdr
[.] Input length : ret = 39 exp = 39 -> OK
[.] Output length : ret = 117 exp = 117 -> OK
[.] Random vector checks:
[..] Encoding / Decoding cycle : OK
[..] Encoding / Decoding cycle : OK
[..] Encoding / Decoding cycle : OK
[+] Testing: gsm0503_mcs1
[.] Input length : ret = 190 exp = 190 -> OK
[.] Output length : ret = 588 exp = 588 -> OK
[.] Random vector checks:
*** Error in `/opt/core/tests/conv/.libs/lt-conv_gsm0503_test': free(): invalid next size (normal): 0x0000000001cde860 ***
[..] Encoding / Decoding cycle : Aborted (core dumped)
</pre>