Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-03-20T14:24:47ZOpen Source Mobile Communications
Redmine Cellular Network Infrastructure - Bug #6411 (New): ttcn3: execute testsuites with a more realisti...https://projects.osmocom.org/issues/64112024-03-20T14:24:47Zfixeria
<p>This idea by <a class="user active" href="https://projects.osmocom.org/users/7">laforge</a> originates from <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: default TCP user timeout is way too low (Resolved)" href="https://projects.osmocom.org/issues/6375">#6375</a>: we should try running at least some of our BTS / BSC tests over an Abis link with simulated latency and non-zero packet loss. I did some experiments using tc-netem, running the whole ttcn3-bts-test with a simulated delay: <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: default TCP user timeout is way too low (Resolved)" href="https://projects.osmocom.org/issues/6375#note-14">#6375#note-14</a>. Let's continue discussing this here.</p> OsmoHNBGW - Bug #6380 (New): VTY transcript tests are broken [again]https://projects.osmocom.org/issues/63802024-02-28T18:34:06Zfixeria
<p>The <a href="https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-hnbgw/" class="external">master-osmo-hnbgw</a> Jenkins job is broken since Feb 27th.</p>
<pre>
Error during transcript step 3:
[
OsmoHNBGW# show cs7 config
cs7 instance 0
point-code 0.23.5
asp asp-clnt-msc-0 2905 0 m3ua
local-ip localhost
remote-ip localhost
role asp
sctp-role client
as as-clnt-msc-0 m3ua
asp asp-clnt-msc-0
routing-key 0 0.23.5
]
Error while verifying transcript file './config//defaults.vty'
Traceback (most recent call last):
File "/usr/local/lib/python3.11/dist-packages/osmopython-0.2.1-py3.11.egg/osmopy/osmo_interact/common.py", line 357, in verify_application
interact.verify_transcript_file(transcript_file)
File "/usr/local/lib/python3.11/dist-packages/osmopython-0.2.1-py3.11.egg/osmopy/osmo_interact/common.py", line 111, in verify_transcript_file
result = self.verify_transcript(content)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/dist-packages/osmopython-0.2.1-py3.11.egg/osmopy/osmo_interact/common.py", line 199, in verify_transcript
raise Exception('Result mismatch:\n%s\n\nExpected:\n[\n%s\n]\n\nGot:\n[\n%s\n%s\n]'
Exception: Result mismatch:
Mismatch:
Expect:
' sctp-role client'
Got:
' transport-role client'
Expected:
[
OsmoHNBGW# show cs7 config
cs7 instance 0
point-code 0.23.5
asp asp-clnt-msc-0 2905 0 m3ua
local-ip localhost
remote-ip localhost
role asp
sctp-role client
as as-clnt-msc-0 m3ua
asp asp-clnt-msc-0
routing-key 0 0.23.5
]
Got:
[
OsmoHNBGW# show cs7 config
cs7 instance 0
point-code 0.23.5
asp asp-clnt-msc-0 2905 0 m3ua
local-ip localhost
remote-ip localhost
role asp
transport-role client
as as-clnt-msc-0 m3ua
asp asp-clnt-msc-0
routing-key 0 0.23.5
]
RESULTS:
FAIL: ./config//defaults.vty
</pre>
<p>This is a side effect of my patch that has been merged to libosmo-sccp.git:</p>
<p><a class="external" href="https://cgit.osmocom.org/libosmo-sccp/commit/?id=4d7e20193c264585080b9edc91eb630dd005e396">https://cgit.osmocom.org/libosmo-sccp/commit/?id=4d7e20193c264585080b9edc91eb630dd005e396</a></p>
<pre>
commit 4d7e20193c264585080b9edc91eb630dd005e396
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Thu Feb 15 05:29:14 2024 +0700
VTY: rename 'sctp-role' to 'transport-role', add an alias
</pre> libosmocore - Bug #6360 (New): libosmovty fails to parse commands like "test (foo|bar) [(one|two|...https://projects.osmocom.org/issues/63602024-02-14T21:25:23Zfixeria
<p>Support for the <code>[(one|two|three)]</code> syntax was added back in 2019:</p>
<pre>
commit b55f4d2df21b966c3953264d8961f259814f4650
Author: Neels Hofmeyr <neels@hofmeyr.de>
Date: Thu Jan 31 08:13:31 2019 +0100
vty: enable optional-multi-choice syntax: [(one|two)]
</pre>
<p><a class="external" href="https://cgit.osmocom.org/libosmocore/commit/?id=b55f4d2df21b966c3953264d8961f259814f4650">https://cgit.osmocom.org/libosmocore/commit/?id=b55f4d2df21b966c3953264d8961f259814f4650</a></p>
<p>However the VTY parser still hits an assertion if the command has a non-optional choice preceding an optional one:</p>
<pre>
test (foo|bar) [(one|two|three)]
</pre>
<p>Here is a patch extending the existing testing coverage and reproducing the problem:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/35961">https://gerrit.osmocom.org/c/libosmocore/+/35961</a></p>
<pre>
$ gdb ./tests/vty/vty_transcript_test
(gdb) r
Program received signal SIGABRT, Aborted.
0x00007ffff7d8b83c in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7d8b83c in ?? () from /usr/lib/libc.so.6
#1 0x00007ffff7d3b668 in raise () from /usr/lib/libc.so.6
#2 0x00007ffff7d234b8 in abort () from /usr/lib/libc.so.6
#3 0x00007ffff7f3d511 in osmo_panic_default (fmt=0x7ffff7fb112c "Assert failed %s %s:%d\n", args=0x7fffffffddc0) at panic.c:45
#4 0x00007ffff7f3d4c5 in osmo_panic (fmt=0x7ffff7fb112c "Assert failed %s %s:%d\n") at panic.c:80
#5 0x00007ffff7f96d83 in cmd_make_descvec (string=0x55555555734f "multi3 (foo|bar) [(one|two|three)]", descstr=0x555555557372 "multi3 test command\nfoo\nbar\n1\n2\n3\n") at command.c:439
#6 0x00007ffff7f96add in install_element (ntype=1, cmd=0x555555559388 <multi3_cmd>) at command.c:1009
#7 0x00007ffff7f9718a in install_element_ve (cmd=0x555555559388 <multi3_cmd>) at command.c:1026
#8 0x0000555555556570 in init_vty_cmds () at vty/vty_transcript_test.c:391
#9 0x0000555555556384 in main (argc=1, argv=0x7fffffffe018) at vty/vty_transcript_test.c:429
(gdb) frame 5
#5 0x00007ffff7f96d83 in cmd_make_descvec (string=0x55555555734f "multi3 (foo|bar) [(one|two|three)]", descstr=0x555555557372 "multi3 test command\nfoo\nbar\n1\n2\n3\n") at command.c:439
439 OSMO_ASSERT(multiple);
(gdb) p cp
$1 = 0x555555557365 "|two|three)]"
</pre>
<p>libosmocore.git 9d73503bd09eb164f781d488bf2c839c0822798a</p> OsmocomBB - Feature #6348 (New): virtphy: add Circuit Switched Data (CSD) supporthttps://projects.osmocom.org/issues/63482024-01-26T22:03:21Zfixeria
<p>Since recently, Calypso PHY and trxcon support data traffic channels needed for CSD:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/34694">https://gerrit.osmocom.org/c/osmocom-bb/+/34694</a> firmware/layer1: handle CSD related channel modes<br /><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/32922">https://gerrit.osmocom.org/c/osmocom-bb/+/32922</a> trxcon/l1sched: implement CSD scheduling support</p>
<p>For the sake of completeness, let's add data traffic channel support to virtphy.</p> OsmocomBB - Feature #6347 (New): mobile: support data calls @ 300 bps and 1200/75 bps (TCH/[FH]2.4)https://projects.osmocom.org/issues/63472024-01-26T21:54:56Zfixeria
<p>Currently we implement data rates starting from <code>2400 bps</code> and higher, but not <code>300 bps</code> and <code>1200/75 bps</code>.<br />The problem is that those rates are not specified in ITU-T Rec. V.110, which defines <code>600 bps</code> as the minimum synchronous data rate.</p>
<p>According to 3GPP TS 44.021, section 4.1, the <code>300 bps</code> user data signalling rate shall be adapted to a synchronous <code>600 bps</code> stream.<br />Also, "Incoming asynchronous data is padded by the addition of stop elements" -- this means that we pad bits after stop bit(s):</p>
<pre>
pad bits = ((600 / 300) - 1) * (start + data + parity + stop)
</pre>
<p>This logic most likely needs to be implemented in the soft-UART module of libosmocore.git.</p> OsmocomBB - Feature #6346 (New): mobile: support data calls @ 14400 bps (TCH/F14.4)https://projects.osmocom.org/issues/63462024-01-26T21:44:42Zfixeria
<p>Currently we implement <code>TCH/[FH]2.4</code>, <code>TCH/[FH]4.8</code>, and <code>TCH/F9.6</code>, but not <code>TCH/F14.4</code>. Calypso PHY should be capable of doing <code>TCH/F14.4</code>, as well as trxcon. However, the rate adaptation functions for <code>TCH/F14.4</code> are different from those we implemented so far. According to 3GPP TS 48.020, chapter 10, we would need to implement <code>RA1'/RAA'</code> and <code>RA1'/RAA"</code>. Other relevant specs: 3GPP TS 44.021 and 3GPP TS 48.060.</p> libosmocore - Feature #6344 (New): New TS 24.008 Bearer Capability codec APIhttps://projects.osmocom.org/issues/63442024-01-24T23:17:59Zfixeria
<p>The current implementation of <code>gsm48_{en,de}code_bearer_cap()</code> lacks support for:</p>
<ul>
<li>encoding/decoding V.34 modem type (octet 6d);</li>
<li>encoding/decoding data rates higher than 9600 bps, like 14400 bps (octets 6d, 6e);</li>
<li>encoding/decoding of other B-channel protocols like V.120 (octets 5a, 5b; see also <a class="issue tracker-1 status-1 priority-2 priority-default" title="Bug: Incorrect handling of V.120 data calls (New)" href="https://projects.osmocom.org/issues/6330">#6330</a>);</li>
<li>encoding/decoding fields of octet 4 (hard-coded to 0x88).</li>
</ul>
<p>Unfortunately, adding new fields to <code>struct gsm_mncc_bearer_cap</code> (on which these functions operate) is not an option.<br />This struct is part of the MNCC PDU, so changing it would result in modifying the protocol and thus problems with backwards compatibility.</p>
<p>This means that we need the new API, which would depend on the MNCC protocol definitions.</p> Cellular Network Infrastructure - Feature #6327 (New): Osmocom-build-tags-against-master job buil...https://projects.osmocom.org/issues/63272024-01-11T20:17:59Zfixeria
<p>The idea behind this job is to check if [a limited set of] old tagged versions of various Osmocom projects can still compile with the most recent versions of Osmocom libraries.</p>
<p>I checked the build logs and found out that it's building the default configurations for Osmocom projects (no <code>--with-foo</code> flags passed to configure scripts).<br />For instance, the default build configuration for osmo-bts does not include any models except the <code>-virtual</code>, so <code>osmo-bts-{trx,sysmo,...}</code> are not covered.<br />Same applies to osmo-trx: we build only the common code, but not the <code>-uhd/-lms</code> variants.</p>
<p>The more complete configurations we build, the more chances we have to catch various backwards compatibility problems.<br />A good example is <a class="external" href="https://cgit.osmocom.org/osmo-ci/tree/coverity/build_Osmocom.sh">https://cgit.osmocom.org/osmo-ci/tree/coverity/build_Osmocom.sh</a>, where we do enable much more features / variants.<br />Maybe this code can be generalized and re-used somehow?</p> OsmocomBB - Bug #6201 (New): modem: signal proper MS Radio Access Capabilityhttps://projects.osmocom.org/issues/62012023-10-03T17:37:39Zfixeria
<p>The modem app is currently sending hard-coded MS RACap to the PCU. It's hard-coded in libosmo-gprs-rlcmac:</p>
<pre><code class="c syntaxhl"><span class="cm">/* 11.2.16 Packet Resource Request */</span>
<span class="kt">void</span> <span class="nf">gprs_rlcmac_enc_prepare_pkt_resource_req</span><span class="p">(</span><span class="n">RlcMacUplink_t</span> <span class="o">*</span><span class="n">block</span><span class="p">,</span>
<span class="k">struct</span> <span class="n">gprs_rlcmac_ul_tbf</span> <span class="o">*</span><span class="n">ul_tbf</span><span class="p">,</span>
<span class="k">enum</span> <span class="n">gprs_rlcmac_access_type</span> <span class="n">acc_type</span><span class="p">)</span>
<span class="p">{</span>
<span class="n">Packet_Resource_Request_t</span> <span class="o">*</span><span class="n">req</span><span class="p">;</span>
<span class="k">struct</span> <span class="n">gprs_rlcmac_entity</span> <span class="o">*</span><span class="n">gre</span> <span class="o">=</span> <span class="n">ul_tbf</span><span class="o">-></span><span class="n">tbf</span><span class="p">.</span><span class="n">gre</span><span class="p">;</span>
<span class="n">memset</span><span class="p">(</span><span class="n">block</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="k">sizeof</span><span class="p">(</span><span class="o">*</span><span class="n">block</span><span class="p">));</span>
<span class="n">req</span> <span class="o">=</span> <span class="o">&</span><span class="n">block</span><span class="o">-></span><span class="n">u</span><span class="p">.</span><span class="n">Packet_Resource_Request</span><span class="p">;</span>
<span class="n">req</span><span class="o">-></span><span class="n">MESSAGE_TYPE</span> <span class="o">=</span> <span class="n">OSMO_GPRS_RLCMAC_UL_MSGT_PACKET_RESOURCE_REQUEST</span><span class="p">;</span>
<span class="cm">/* ... */</span>
<span class="n">req</span><span class="o">-></span><span class="n">ID</span><span class="p">.</span><span class="n">UnionType</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span> <span class="cm">/* Use TLLI */</span>
<span class="n">req</span><span class="o">-></span><span class="n">ID</span><span class="p">.</span><span class="n">u</span><span class="p">.</span><span class="n">TLLI</span> <span class="o">=</span> <span class="n">gre</span><span class="o">-></span><span class="n">tlli</span><span class="p">;</span> <span class="cm">/* Use TLLI */</span>
<span class="n">req</span><span class="o">-></span><span class="n">Exist_MS_Radio_Access_capability2</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="n">req</span><span class="o">-></span><span class="n">MS_Radio_Access_capability2</span><span class="p">.</span><span class="n">Count_MS_RA_capability_value</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="cm">/* TODO: fill Content_t: */</span>
<span class="cm">/* req->MS_Radio_Access_capability2.MS_RA_capability_value[0].Content.* */</span>
</code></pre>
<p>We definitely want to send something more meaningful than all zeroes.</p>
<ul>
<li>There needs to be a way (API) to "tell" libosmo-gprs-rlcmac which MS RACap to use.</li>
<li>We may also want to make some parts of the RACap configurable via the VTY.</li>
</ul> OsmocomBB - Bug #6200 (New): osmo-trx-ms: lots of @Received bad frame (rc=-1, ber=444/444)@https://projects.osmocom.org/issues/62002023-10-03T16:46:40Zfixeria
<p>Hi <a class="user active" href="https://projects.osmocom.org/users/52">Hoernchen</a>,</p>
<p>we had a debugging session with <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> today and we got the mssdr-ms side to work more or less reliably. But we noticed a weird problem:</p>
<pre>
20231003152951965 DL1C NOTICE trxcon(0)[0x5579a42900]{BCCH_CCCH}: L1CTL_DM_EST_REQ indicates single ARFCN GSM900 979 (l1ctl.c:572)
20231003152951965 DSCH NOTICE trxcon(0)[0x5579a42900]: Reset scheduler (sched_trx.c:190)
20231003152951965 DSCH NOTICE trxcon(0)[0x5579a42900]: Delete TDMA timeslot #0 (sched_trx.c:226)
20231003152951965 DSCH NOTICE trxcon(0)[0x5579a42900]: Add a new TDMA timeslot #4 (sched_trx.c:207)
20231003152951965 DSCH NOTICE trxcon(0)[0x5579a42900]: (Re)configure TDMA timeslot #4 as PDCH (sched_trx.c:276)
20231003152951966 DSCH NOTICE trxcon(0)[0x5579a42900]: TS4-PDTCH activating (sched_trx.c:476)
20231003152951966 DSCH NOTICE trxcon(0)[0x5579a42900]: TS4-PTCCH activating (sched_trx.c:476)
20231003152953364 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=86/456) at fn=513573 (sched_lchan_pdtch.c:94)
20231003152954366 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=87/456) at fn=513790 (sched_lchan_pdtch.c:94)
20231003152954804 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513885 (sched_lchan_pdtch.c:94)
20231003152954827 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513890 (sched_lchan_pdtch.c:94)
20231003152954846 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513894 (sched_lchan_pdtch.c:94)
20231003152954864 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513898 (sched_lchan_pdtch.c:94)
20231003152954887 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513903 (sched_lchan_pdtch.c:94)
20231003152954906 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513907 (sched_lchan_pdtch.c:94)
20231003152954924 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513911 (sched_lchan_pdtch.c:94)
20231003152954947 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513916 (sched_lchan_pdtch.c:94)
20231003152954966 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513920 (sched_lchan_pdtch.c:94)
20231003152954984 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513924 (sched_lchan_pdtch.c:94)
20231003152955007 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513929 (sched_lchan_pdtch.c:94)
20231003152955025 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513933 (sched_lchan_pdtch.c:94)
20231003152955044 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513937 (sched_lchan_pdtch.c:94)
20231003152955067 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513942 (sched_lchan_pdtch.c:94)
20231003152955085 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513946 (sched_lchan_pdtch.c:94)
20231003152955104 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513950 (sched_lchan_pdtch.c:94)
20231003152955127 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513955 (sched_lchan_pdtch.c:94)
20231003152955145 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513959 (sched_lchan_pdtch.c:94)
20231003152955164 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513963 (sched_lchan_pdtch.c:94)
20231003152955188 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513968 (sched_lchan_pdtch.c:94)
20231003152955205 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513972 (sched_lchan_pdtch.c:94)
20231003152955224 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513976 (sched_lchan_pdtch.c:94)
20231003152955248 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513981 (sched_lchan_pdtch.c:94)
20231003152955265 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513985 (sched_lchan_pdtch.c:94)
20231003152955284 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513989 (sched_lchan_pdtch.c:94)
20231003152955308 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513994 (sched_lchan_pdtch.c:94)
20231003152955325 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=513998 (sched_lchan_pdtch.c:94)
20231003152955344 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=514002 (sched_lchan_pdtch.c:94)
20231003152955368 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=514007 (sched_lchan_pdtch.c:94)
20231003152955385 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=514011 (sched_lchan_pdtch.c:94)
20231003152955404 DSCHD ERROR trxcon(0)[0x5579a42900]: TS4-PDTCH Received bad frame (rc=-1, ber=444/444) at fn=514015 (sched_lchan_pdtch.c:94)
</pre>
<p>It's not seen during the GMM ATTACH and SM PDP CTX ACT procedures, but only when we tried sending some data (ICMP ping) over the tun interface.<br />As can be seen, quite a lot of Downlink PDCH blocks not being decoded. The <code>BER=444/444</code> makes me think that received bursts were all 0 (neither -127 nor 127).<br />This is enlarging the ping delays significantly (from ~600ms to ~5000ms ==> ~10 times):</p>
<pre>
PING 176.16.222.1 (176.16.222.1) 56(84) bytes of data.
64 bytes from 176.16.222.1: icmp_seq=1 ttl=64 time=681 ms
64 bytes from 176.16.222.1: icmp_seq=2 ttl=64 time=803 ms
64 bytes from 176.16.222.1: icmp_seq=3 ttl=64 time=625 ms
64 bytes from 176.16.222.1: icmp_seq=4 ttl=64 time=525 ms
64 bytes from 176.16.222.1: icmp_seq=5 ttl=64 time=5646 ms
64 bytes from 176.16.222.1: icmp_seq=6 ttl=64 time=4678 ms
64 bytes from 176.16.222.1: icmp_seq=7 ttl=64 time=3911 ms
64 bytes from 176.16.222.1: icmp_seq=8 ttl=64 time=2948 ms
64 bytes from 176.16.222.1: icmp_seq=9 ttl=64 time=1984 ms
64 bytes from 176.16.222.1: icmp_seq=10 ttl=64 time=1020 ms
64 bytes from 176.16.222.1: icmp_seq=11 ttl=64 time=602 ms
64 bytes from 176.16.222.1: icmp_seq=12 ttl=64 time=742 ms
64 bytes from 176.16.222.1: icmp_seq=13 ttl=64 time=5741 ms
64 bytes from 176.16.222.1: icmp_seq=14 ttl=64 time=4769 ms
64 bytes from 176.16.222.1: icmp_seq=15 ttl=64 time=3824 ms
64 bytes from 176.16.222.1: icmp_seq=16 ttl=64 time=2860 ms
64 bytes from 176.16.222.1: icmp_seq=17 ttl=64 time=1896 ms
64 bytes from 176.16.222.1: icmp_seq=18 ttl=64 time=932 ms
64 bytes from 176.16.222.1: icmp_seq=19 ttl=64 time=813 ms
64 bytes from 176.16.222.1: icmp_seq=20 ttl=64 time=653 ms
64 bytes from 176.16.222.1: icmp_seq=21 ttl=64 time=5630 ms
64 bytes from 176.16.222.1: icmp_seq=22 ttl=64 time=4658 ms
64 bytes from 176.16.222.1: icmp_seq=23 ttl=64 time=3893 ms
64 bytes from 176.16.222.1: icmp_seq=24 ttl=64 time=2929 ms
64 bytes from 176.16.222.1: icmp_seq=25 ttl=64 time=1969 ms
64 bytes from 176.16.222.1: icmp_seq=26 ttl=64 time=1005 ms
64 bytes from 176.16.222.1: icmp_seq=27 ttl=64 time=546 ms
64 bytes from 176.16.222.1: icmp_seq=28 ttl=64 time=686 ms
</pre>
<p>This looks like a PHY problem to me, so assigning to you.</p> OsmoBTS - Feature #6167 (New): csd_v110: implement rate adaptation for TCH/F14.4https://projects.osmocom.org/issues/61672023-09-01T11:58:07Zfixeria
<p>We do implement scheduling of TCH/F14.4 in osmo-bts-trx, however the rare adaptation is missing. This is why current osmo-bts-trx would NACK CHANnel ACTIVation attempts for this data rate. The rate adaptation functions for TCH/F14.4 are different from the ones employed for TCH/F9.6, TCH/F4.8, and TCH/F2.4. According to 3GPP TS 48.020, chapter 10, we would need to implement RA1'/RAA' and RA1'/RAA". Other relevant specs: 3GPP TS 44.021 and 3GPP TS 48.060.</p> OsmoBSC - Bug #6019 (New): "PCU version PCU socket has LOST connection connected"https://projects.osmocom.org/issues/60192023-04-28T12:17:03Zfixeria
<p>This is what I see in the output of <code>show bts</code> command:</p>
<pre>
OsmoBSC> show bts 0
BTS 0 is of osmo-bts type in band GSM900, has CI 0 LAC 1, BSIC 63 (NCC=7, BCC=7) and 1 TRX
Description: (null)
ARFCNs: 85
PCU version PCU socket has LOST connection connected
...
</pre>
<p>what means that somehow <code>bts->pcu_version[]</code> contains <code>PCU socket has LOST connection</code>. I am also seeing this in logging:</p>
<pre>
апр 28 19:14:07 DELL osmo-bsc[543401]: DNM NOTICE abis_nm.c:348 OC=BTS(01) INST=(00,ff,ff): Reported connected PCU version 1.2.0.31-33a1bf3
...
апр 28 19:14:10 DELL osmo-bsc[543401]: DNM NOTICE abis_nm.c:348 OC=BTS(01) INST=(00,ff,ff): Reported connected PCU version PCU socket has LOST connection
</pre>
<p>This looks a bit confusing, maybe we should just say "PCU state"?</p> Cellular Network Infrastructure - Bug #5985 (New): tests: not all Osmocom projects have @osmoappd...https://projects.osmocom.org/issues/59852023-03-29T20:09:42Zfixeria
<p>This is a manifest file, which is used by both <code>osmotestvty.py</code> and <code>osmotestconfig.py</code> for running VTY and config tests.</p>
<p>AFAICS, only the following files have this manifest (my local repos, might be incomplete):</p>
<pre>
fixeria@DELL:~/osmo-dev/src$ find . -name osmoappdesc.py
./libosmocore/tests/gb/osmoappdesc.py
./osmo-sgsn/osmoappdesc.py
./libosmo-sccp/osmoappdesc.py
./osmo-bsc/osmoappdesc.py
./osmo-pcu/osmoappdesc.py
./osmo-smlc/osmoappdesc.py
./osmo-mgw/osmoappdesc.py
./osmo-msc/osmoappdesc.py
./osmo-pcap/osmoappdesc.py
./osmo-sip-connector/osmoappdesc.py
</pre>
<p>I am adding checkboxes for projects missing this file. Maybe something for @arehbein to work on?</p> OsmoBTS - Bug #5952 (New): ttcn3-bts-test: TC_ho_physical_info failshttps://projects.osmocom.org/issues/59522023-03-21T12:35:13Zfixeria
<p>The testcase was added by me and is failing since the very beginning:</p>
<pre>
commit 1ab332ff86117e7aa22ca973993ea16bedbf63b7
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sat Mar 12 15:31:23 2022 +0300
BTS_Tests: add new test case TC_ho_physical_info
</pre>
<p>The problem is explained in the commit message:</p>
<pre>
Currently the new test case fails for several reasons:
* osmo-bts-trx starts transmitting on DCCH before the handover
Access Burst is received, this is wong;
* trxcon immediately starts sending dummy frames on Uplink
DCCH, causing osmo-bts to stop sendig RR Physical Info.
</pre> OsmocomBB - Bug #5831 (New): SE K2x0i: built-in SIM reader is not workinghttps://projects.osmocom.org/issues/58312022-12-15T23:46:08Zfixeria
<p>Currently the mobile app fails to use built-in SIM reader of my Sony Ericsson K200i:</p>
<pre>
DMM INFO subscriber.c:596 Requesting SIM file 0x2fe2
DSIM INFO sim.c:223 got new job: SIM_JOB_READ_BINARY (handle=00000004)
DSIM INFO sim.c:712 go MF
DSIM INFO sim.c:256 SELECT (file=0x3f00)
DSIM INFO sim.c:181 sending APDU (class 0xa0, ins 0xa4)
DSIM INFO sim.c:200 Using built-in SIM reader
DSIM INFO sim.c:901 received APDU (len=0 sw1=0x00 sw2=0x00)
DSIM INFO sim.c:979 command failed
DSIM INFO sim.c:147 sending result to callback function (type=1)
</pre>
<p>This is what the firmware log looks like:</p>
<pre>
OsmocomBB Layer 1 (revision osmocon_v0.0.0-2885-g86f46edd-modified)
======================================================================
Device ID code: 0xb496
Device Version code: 0x0000
ARM ID code: 0xfff3
cDSP ID code: 0x0128
Die ID code: e515201ce51557b9
======================================================================
REG_DPLL=0x2413
CNTL_ARM_CLK=0xf0a1
CNTL_CLK=0xff91
CNTL_RST=0xfff7
CNTL_ARM_DIV=0xfff9
======================================================================
Power up simcard:
key=20 pressed
key=20 released
Checking TIFFS for the RF calibration records
...
L1CTL_RESET_REQ: FULL!
SIM Request (7): a0 a4 00 00 02 3f 00
SIM: ACK read failed
SIM Response (2): 00 00
</pre>
<p>Note the <code>key=20 pressed/released</code>, I wasn't actually pressing anything.</p> OsmocomBB - Feature #5815 (New): mobile: compose Bearer Capability IE depending on PHY capabiliti...https://projects.osmocom.org/issues/58152022-12-06T19:38:37Zfixeria
<p>This was originally proposed as a checklist item in <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: mobile: implement GAPK based audio capture / playback (via ALSA) (Resolved)" href="https://projects.osmocom.org/issues/3400">#3400</a>. The idea is to compose the <code>Bearer Capability IE</code> in Uplink <code>(CC) Setup</code> messages not only based on the VTY configuration (see below), but also based on the PHY capabilities (see <a class="issue tracker-2 status-7 priority-3 priority-high3" title="Feature: include some version information / negotiation in the L1CTL protocol (Stalled)" href="https://projects.osmocom.org/issues/1461">#1461</a>) and GAPK codec support (see <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: mobile: implement GAPK based audio capture / playback (via ALSA) (Resolved)" href="https://projects.osmocom.org/issues/3400">#3400</a>). The respective function <code>mncc_set_bearer()</code> can be found in <a class="external" href="https://cgit.osmocom.org/osmocom-bb/tree/src/host/layer23/src/mobile/mnccms.c">https://cgit.osmocom.org/osmocom-bb/tree/src/host/layer23/src/mobile/mnccms.c</a>.</p> OsmocomBB - Feature #5812 (New): mobile: missing AMR supporthttps://projects.osmocom.org/issues/58122022-12-06T15:07:50Zfixeria
<p>This was originally a checklist item in <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: mobile: implement GAPK based audio capture / playback (via ALSA) (Resolved)" href="https://projects.osmocom.org/issues/3400#note-15">#3400#note-15</a>:</p>
<pre>
The non-adaptive codecs (HR, FR, EFR) are all confirmed to work. AMR implementation is
currently incomplete in trxcon, and is completely missing in the layer1 firmware (needs DSP patches).
</pre>
<p>Initial AMR support was recently added to trxcon by <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a>:</p>
<pre>
commit a53e93fe9c81136b512697e169c5cf5ecd319163
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date: Fri Sep 2 17:02:17 2022 +0200
trxcon: Initial support for forwarding AMR
This allows TTCN3 L1CTL module (used in BTS_Tests) to transmit and
receive AMR payloads towards osmo-bts-trx.
Related: SYS#5987
Change-Id: Ia20bc96e39726a919a556c83c8be48cb31af7331
</pre>
<p>We need to investigate what needs to be done in order to support AMR calls, at least for trxcon.</p>
<p>One missing part is forwarding the AMR parameters to the L1 via L1CTL:</p>
<pre><code class="diff syntaxhl"><span class="gh">diff --git a/src/host/layer23/src/common/l1ctl.c b/src/host/layer23/src/common/l1ctl.c
index e33074af..d5204034 100644
</span><span class="gd">--- a/src/host/layer23/src/common/l1ctl.c
</span><span class="gi">+++ b/src/host/layer23/src/common/l1ctl.c
</span><span class="p">@@ -472,6 +472,7 @@</span> int l1ctl_tx_tch_mode_req(struct osmocom_ms *ms, uint8_t tch_mode,
req->tch_mode = tch_mode;
req->audio_mode = audio_mode;
req->tch_loop_mode = tch_loop_mode;
<span class="gi">+ /* TODO: Set AMR codec in req if req->tch_mode==GSM48_CMODE_SPEECH_AMR */
</span>
return osmo_send_l1(ms, msg);
}
</code></pre> Cellular Network Infrastructure - Bug #5764 (New): GCC does not check format strings in LOGPFSM m...https://projects.osmocom.org/issues/57642022-11-11T06:30:22Zfixeria
<p>Recently I submitted a patch with an error in one of the LOGPFSM statements ('%s' instead of '%d' for printing an uint16_t):</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/30054/1">https://gerrit.osmocom.org/c/osmocom-bb/+/30054/1</a><br /><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/30054/1/src/host/trxcon/src/trxcon_fsm.c#229">https://gerrit.osmocom.org/c/osmocom-bb/+/30054/1/src/host/trxcon/src/trxcon_fsm.c#229</a></p>
<p>Surprisingly, gcc does not emit any warnings and compiles obviously wrong code just fine. This is not specific to <code>osmocom-bb.git</code>, I was able to reproduce this problem in other Osmocom repositories, except <code>libosmocore.git</code> where it magically does emit <code>-Wformat</code> warnings as expected. This is most likely a bug in gcc, because clang behaves as expected.</p>
<p>I also tried to narrow down the problem to a specific macro:</p>
<pre><code class="c syntaxhl"><span class="cp">#define FMT "Test %s\n"
#define ARG 1337, "extra", -1
</span>
<span class="cm">/* GCC does emit -Wformat / -Wformat-extra-args warnings as expected */</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DAPP</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="n">FMT</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
<span class="cm">/* GCC does *not* emit any warnings, clang does */</span>
<span class="n">LOGPFSML</span><span class="p">(</span><span class="n">fi</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="n">FMT</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
<span class="n">LOGPFSMLSRC</span><span class="p">(</span><span class="n">fi</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="n">__FILE__</span><span class="p">,</span> <span class="n">__LINE__</span><span class="p">,</span> <span class="n">FMT</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
<span class="n">LOGPFSMSLSRC</span><span class="p">(</span><span class="n">fi</span><span class="p">,</span> <span class="p">(</span><span class="n">fi</span><span class="p">)</span> <span class="o">?</span> <span class="p">(</span><span class="n">fi</span><span class="p">)</span><span class="o">-></span><span class="n">fsm</span><span class="o">-></span><span class="n">log_subsys</span> <span class="o">:</span> <span class="n">DLGLOBAL</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span>
<span class="n">__FILE__</span><span class="p">,</span> <span class="n">__LINE__</span><span class="p">,</span> <span class="n">FMT</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
<span class="cm">/* GCC does emit -Wformat / -Wformat-extra-args warnings as expected */</span>
<span class="n">LOGPSRC</span><span class="p">((</span><span class="n">fi</span><span class="p">)</span><span class="o">-></span><span class="n">fsm</span><span class="o">-></span><span class="n">log_subsys</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span>
<span class="n">__FILE__</span><span class="p">,</span> <span class="n">__LINE__</span><span class="p">,</span>
<span class="s">"%s{%s}: "</span> <span class="n">FMT</span><span class="p">,</span>
<span class="n">osmo_fsm_inst_name</span><span class="p">(</span><span class="n">fi</span><span class="p">),</span>
<span class="p">(</span><span class="n">fi</span><span class="p">)</span> <span class="o">?</span> <span class="n">osmo_fsm_state_name</span><span class="p">((</span><span class="n">fi</span><span class="p">)</span><span class="o">-></span><span class="n">fsm</span><span class="p">,</span> <span class="p">(</span><span class="n">fi</span><span class="p">)</span><span class="o">-></span><span class="n">state</span><span class="p">)</span> <span class="o">:</span> <span class="s">"fi=NULL"</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
</code></pre>
<p>Running gcc with <code>-E -P</code> confirms that the preprocessor expands all <code>LOGPFSM</code> statements identical to the last <code>LOGPSRC</code>.</p> Cellular Network Infrastructure - Bug #5750 (New): contrib/jenkins.sh: build with -Wunused-macros...https://projects.osmocom.org/issues/57502022-11-08T20:07:03Zfixeria
<p>According to <code>man cpp</code>:</p>
<pre>
-Wundef
Warn if an undefined identifier is evaluated in an "#if" directive.
Such identifiers are replaced with zero.
-Wunused-macros
Warn about macros defined in the main file that are unused. A macro
is used if it is expanded or tested for existence at least once. The
preprocessor also warns if the macro has not been used at the time it
is redefined or undefined.
Built-in macros, macros defined on the command line, and macros
defined in include files are not warned about.
Note: If a macro is actually used, but only used in skipped
conditional blocks, then the preprocessor reports it as unused. To
avoid the warning in such a case, you might improve the scope of the
macro's definition by, for example, moving it into the first skipped
block. Alternatively, you could provide a dummy use with something
like:
#if defined the_macro_causing_the_warning
#endif
</pre>
<p>I think it would be good to have these options enabled during the build verification.</p>
<p>With this option enabled, I quickly found a copy-paste bug in osmo-bsc:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/30058">https://gerrit.osmocom.org/c/osmo-bsc/+/30058</a></p> Cellular Network Infrastructure - Bug #5749 (New): configure.ac: default CFLAGS, LT_INIT adds "-g...https://projects.osmocom.org/issues/57492022-11-08T18:04:34Zfixeria
<p>Today I spent quite some time trying to figure out why am I seeing <code>-g -O2</code> present in <code>CFLAGS</code> by default when building some projects. As it turned out, it's the <code>LT_INIT</code> (called in <code>configure.ac</code>) adding <code>-g -O2</code> to <code>CFLAGS</code> if they're empty. I could not find anything in documentation describing this behavior. The problem is that this behavior is inconsistent across the Osmocom projects: for some you get empty CFLAGS by default, for some you get <code>CFLAGS=-g -O2</code>. Most likely this inconsistency was introduced when we started to specify the <code>-std=gnu11</code> explicitly: in some projects (e.g. libosmocore.git, libosmo-abis.git, osmo-bsc) we set <code>CFLAGS</code> before calling the <code>LT_INIT</code>, in some (osmo-hlr, osmo-iuh, osmo-sgsn) after.</p>
<p>We need to decide on whether we want to have empty <code>CFLAGS</code> or <code>CFLAGS=-g -O2</code> set by default. Personally I prefer the former approach, because explicit is better then implicit. <a class="user active" href="https://projects.osmocom.org/users/52">Hoernchen</a> also prefers the former and does not want "magical flags out of nowhere". Either way, the default behavior should be consistent across all Osmocom projects. <a class="user active" href="https://projects.osmocom.org/users/7">laforge</a> what do you think?</p> libosmocore - Bug #5570 (New): coding: decode in-band data in AMR's special DTX frames (SID_FIRST...https://projects.osmocom.org/issues/55702022-05-21T14:21:38Zfixeria
<p>Whenever gsm0503_tch_a[fh]s_decode_dtx() detects a special AMR's DTX frame (e.g SID_FIRST, SID_UPDATE, SID_ONSET) it immediately jumps out and ignores the coded in-band data (CMI, CMC/CMR). A hard-coded default value=0 is assigned instead of the actual value(s) indicated by the MS. This basically breaks rate adaptation when DTXu is employed.</p> OsmoBTS - Bug #5517 (New): ttcn3-bts-test: new sporadic test case failureshttps://projects.osmocom.org/issues/55172022-04-07T21:37:29Zfixeria
<p>Since recently, the following testcases sporadically fail:</p>
<ul>
<li>BTS_Tests.TC_tx_power_ramp_adm_state_change,</li>
<li>BTS_Tests.TC_rsl_ms_pwr_dyn_ass_updown,</li>
<li>BTS_Tests.TC_rsl_ms_pwr_dyn_up.</li>
</ul>
<p>We should investigate why and try to fix them.</p> OsmoBTS - Feature #5025 (New): Missing TTCN-3 coverage for the Timing Advance loophttps://projects.osmocom.org/issues/50252021-02-15T16:36:08Zfixeria
<p>As we figured out in <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: Timing Advance loop is broken for SDCCH channels (Resolved)" href="https://projects.osmocom.org/issues/5024">#5024</a>, there seems to be no TTCN-3 test case(s) for continuous Timing Advance control:</p>
<p>Harald Welte wrote:</p>
<blockquote>
<p>Regarding TTCN3 tests: We also only test the correct TA usage on initial channel establishment (BTS_Tests.TC_rsl_chan_initial_ta) and no tests yet for the TA loop during an active channel.</p>
</blockquote> OsmoBTS - Bug #4082 (New): OML: Unknown/unhandled PCHAN type: 0 NONEhttps://projects.osmocom.org/issues/40822019-07-01T07:14:34Zfixeria
<p>If at least one time-slot in OsmoBSC is configured as NONE:</p>
<pre>
network
...
bts 0
...
trx 0
...
timeslot 0
phys_chan_config CCCH
hopping enabled 0
...
timeslot 7
phys_chan_config NONE
hopping enabled 0
</pre>
<p>OsmoBTS fails to start:</p>
<pre>
...
DOML DEBUG oml.c:877 OC=CHANNEL(03) INST=(00,00,06): Rx SET CHAN ATTR
DOML INFO oml.c:941 OC=CHANNEL(03) INST=(00,00,06): OC=CHANNEL INST=(00,00,06) SET CHAN ATTR (TSC=7 pchan=TCH/H)
DL1C NOTICE scheduler.c:948 Configuring multiframe with TCH/H+SACCH trx=0 ts=6
DOML DEBUG oml.c:454 OC=CHANNEL(03) INST=(00,00,06): Sending FOM ACK.
DOML DEBUG oml.c:981 OC=CHANNEL(03) INST=(00,00,06): Rx CHG ADM STATE
DOML DEBUG oml.c:144 OC=CHANNEL(03) INST=(00,00,06): Tx Change Administrative State Ack
DOML DEBUG oml.c:144 OC=CHANNEL(03) INST=(00,00,06): Tx State Changed Event Report
DOML DEBUG oml.c:954 OC=CHANNEL(03) INST=(00,00,06): Rx OPSTART
DOML DEBUG oml.c:964 OC=CHANNEL(03) INST=(00,00,06): ... automatic ACK, OP state already was Enabled
DOML DEBUG oml.c:144 OC=CHANNEL(03) INST=(00,00,06): Tx Opstart Ack
DTRX NOTICE trx_if.c:487 phy0.0: Using legacy TRXD header format version
DL1C DEBUG l1_if.c:177 phy0.0: (bts=0,trx=0,ts=6) l1if_setslot_cb(as_pchan=TCH/H), calling cb_ts_connected(rc=0)
DOML DEBUG oml.c:877 OC=CHANNEL(03) INST=(00,00,07): Rx SET CHAN ATTR
DOML ERROR oml.c:863 Unknown/unhandled PCHAN type: 0 NONE
DOML ERROR oml.c:924 OC=CHANNEL(03) INST=(00,00,07): SET CHAN ATTR: invalid Chan Comb 0xff (pchan=NONE, conf_lchans()->-14)
DOML NOTICE oml.c:446 OC=CHANNEL(03) INST=(00,00,07): Sending FOM NACK with cause Parameter value outside permitted range.
DLINP ERROR input/ipa.c:65 127.0.0.1:3002 connection closed with server
DABIS ERROR abis.c:144 Signalling link down
DABIS FATAL abis.c:158 OML link was closed early within 1 seconds. If this situation persists, please check your BTS and BSC configuration files for errors.
A common error is a mismatch between unit_id configuration parameters of BTS and BSC.
DOML NOTICE bts.c:285 Shutting down BTS 0, Reason Abis close
DL1C NOTICE scheduler.c:597 Exit scheduler for trx=0
...
</pre> OsmocomBB - Feature #3666 (New): trxcon: Introduce VTY interfacehttps://projects.osmocom.org/issues/36662018-10-24T12:16:08Zfixeria
<p>Having the VTY interface would allow one to configure various logging<br />parameters, observe some statistics, and moreover to configure<br />multiple L23 <-> TRX connections.</p>
<pre>
log stderr
logging filter all 1
logging print category 1
...
! One transceiver connection
trxcon foo
! TRX interface configuration
trx ip local 127.0.0.1
trx base-port local 5800
trx ip remote 127.0.0.1
trx base-port remote 5700
trx fn-advance 20
...
! L23 interface configuration
layer2-socket /tmp/osmocom_l2.foo
...
! Another transceiver connection
trxcon bar
...
! Another transceiver connection
trxcon zoo
...
</pre> OsmocomBB - Bug #3557 (New): trxcon: decoding errors after applying a new TCH modehttps://projects.osmocom.org/issues/35572018-09-16T09:52:18Zfixeria
<p>There are also some decoding errors after applying a new TCH mode from Channel Mode Modify:</p>
<pre>
<0005> sched_trx.c:263 (Re)configure TDMA timeslot #2 as TCH/H+SACCH
<0005> sched_trx.c:420 Activating lchan=TCH/H(0) on ts=2
<0005> sched_trx.c:420 Activating lchan=SACCH/TH(0) on ts=2
<0006> sched_lchan_xcch.c:96 Received incomplete data frame at fn=0 (0/104) for SACCH/TH(0)
<0006> sched_lchan_xcch.c:106 Received bad data frame at fn=0 (0/104) for SACCH/TH(0)
<0005> sched_clck.c:138 Clock indication: fn=22389
<0005> sched_clck.c:138 Clock indication: fn=22440
<0001> l1ctl.c:695 Received L1CTL_TCH_MODE_REQ (tch_mode=1, audio_mode=10)
<0005> sched_clck.c:138 Clock indication: fn=22491
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22513 on TCH/H(0) (rc=-1)
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22518 on TCH/H(0) (rc=-1)
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22522 on TCH/H(0) (rc=-1)
<0006> sched_lchan_tchh.c:305 Received bad TCH frame ending at fn=22526 on TCH/H(0) (rc=-1)
<0005> sched_clck.c:138 Clock indication: fn=22542
<0005> sched_clck.c:138 Clock indication: fn=22593
<0005> sched_clck.c:138 Clock indication: fn=22644
<0005> sched_clck.c:138 Clock indication: fn=22695
<0005> sched_clck.c:138 Clock indication: fn=22746
<0005> sched_clck.c:138 Clock indication: fn=22797
</pre> libosmocore - Feature #3522 (New): libosmocoding: move TCH ordering functions to libosmocodec and...https://projects.osmocom.org/issues/35222018-09-04T20:49:08Zfixeria
<p>The GSM 05.03 implementation present in libosmocoding is using the RTP speech frame format for TCH coding functions. It is implemented in a way of performing 'canonical -> RTP' bit reordering in decoding functions, and 'RTP -> canonical' bit reordering in encoding functions. At the moment, the RTP format bit reordering implementation is not exposed.</p>
<p>This API could be used by some other projects (at least by osmo-gapk), moreover libosmocoding is already being linked against libosmocodec.</p> libosmocore - Feature #3521 (New): core/utils: engineering notation helpershttps://projects.osmocom.org/issues/35212018-09-04T20:32:52Zfixeria
<p>It would be great to have some auxiliary API to parse numbers written in the engineering notation (e.g. 945.6M, -33k) to the regular numbers (float?), and, vice versa, the regular numbers to engineering notation. This is useful in the cases where a user should provide some input, such as frequency (e.g. in osmo-arfcn) or sample rate.</p>
<p>Inspired by GNU Radio: <a class="external" href="https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/python/gnuradio/eng_notation.py">https://github.com/gnuradio/gnuradio/blob/master/gnuradio-runtime/python/gnuradio/eng_notation.py</a></p>
<p>If this feature also looks useful for others, I would implement it.</p> OsmocomBB - Bug #3401 (New): target/firmware/l1ctl: both chan_nr and link_id are not set for L1CT...https://projects.osmocom.org/issues/34012018-07-16T23:56:25Zfixeria
<p>Due to a bit complicated implementation of event handling in the firmware, it's hard to pass all required parameters to an event handler. So, both chan_nr and link_id are not being set (always 0x00) for L1CTL messages of type L1CTL_DATA_CONF. At the same time link_id is checked by the higher layers at 'src/host/layer23/src/common//rx_ph_data_conf()':</p>
<pre>
/* determine LAPDm entity based on SACCH or not */
if (dl->link_id & 0x40)
le = &ms->lapdm_channel.lapdm_acch;
else
le = &ms->lapdm_channel.lapdm_dcch;
/* send it up into LAPDm */
return lapdm_phsap_up(&pp.oph, le);
</pre> GSM Audio Pocket Knife - Bug #3398 (New): build: configure fails if (optional) libalsa wasn't foundhttps://projects.osmocom.org/issues/33982018-07-16T20:45:23Zfixeria
<p>ALSA is optional dependency, which is only required for audio capture and playback.<br />We should not enforce this optional dependency as a mandatory one.</p>