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> 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> 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> 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> 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 #5951 (Resolved): ttcn3-bts-test: TC_early_immediate_assignment is failinghttps://projects.osmocom.org/issues/59512023-03-21T12:27:50Zfixeria
<p>This testcase was added by Neels back in 2021:</p>
<pre>
commit af9d6ae0eabfe8d22f55f2ea488233963a4a1d29
Author: Neels Hofmeyr <neels@hofmeyr.de>
Date: Sun Aug 15 23:18:47 2021 +0200
bts: add TC_early_immediate_assignment_pre_chan_ack
Related: SYS#5559
Related: Ie52765b238b01f22fb327fe12327fbf10abcad4c (osmo-bts)
Change-Id: Ifb2c62431a91dafa6116b5d6b9410930f00a6e18
</pre>
<p>Unfortunately it's failing for quite some time:</p>
<ul>
<li>master: since 110 days ago,</li>
<li>latest: since 112 days ago.</li>
</ul>
<pre>
"BTS_Tests.ttcn:2494 : Timeout waiting for CHAN-RQD from RACH REQ <23, 157>"
BTS_Tests.ttcn:9062 BTS_Tests control part
BTS_Tests.ttcn:8527 TC_early_immediate_assignment testcase
</pre> 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> 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> OsmoBTS - Bug #4697 (Resolved): osmo-bts-trx ramps down RF-locked transceivers [again]https://projects.osmocom.org/issues/46972020-08-06T11:21:36Zfixeria
<p>When the BSC RF-locks a transceiver, osmo-bts-trx ramps its power down as expected. After that, on receipt of SIGINT or SIGTERM, osmo-bts-trx ramps down all transceivers, <strong>including the RF-locked ones</strong>, i.e. it increases their Tx power and ramps it down again. Thanks to another bug <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: osmo-bts-trx keeps sending dummy bursts after being RF-locked (Resolved)" href="https://projects.osmocom.org/issues/4696">#4696</a>, I noticed this weird behavior on the spectrum.</p> OsmoBTS - Bug #4694 (Resolved): Radio link timeout would never expire after RF-lock (resource leak)https://projects.osmocom.org/issues/46942020-08-05T22:06:23Zfixeria
<p>I noticed that "RF-locking" a transceiver with active connections (e.g. voice calls) causes a resource leak: the BSC would continue to consider the associated logical channels occupied, so the MSC would also consider the CS connections active (if any). What's even more annoying is that the phones, that were previously connected and lost the signal, would be unable to attach again, because the MSC thinks that they still are.</p>
<pre>
23:34 < fixeria> interestingly, both BSC and MSC still consider the connection (silent call) as established
23:37 <@LaF0rge> fixeria: The BTS radio link timeout should still be counting down, which in turn should result in a channel releae after some seconds
23:37 <@LaF0rge> fixeria: if that doesn't happen, it's a bug (pleae file one)
23:38 <@LaF0rge> fixeria: so basically to the higher layers it doesn't matter why the RF connection is gone (no more signal, bad antenna/cable, broken power amplifier,
or TRX locked) - the radio link is gone and it must detect that and handle it identical
23:39 <@LaF0rge> once the BTS reports radio link failure to the BSC, the BSC will start the release procedure for the A interface SCCP connection and the MSC will
release all related resouces
23:39 < fixeria> LaF0rge: yep, looks like a resource leak
23:42 < fixeria> lol, after that osmo-msc refuses to accept a Location Update
23:43 < fixeria> "Cannot associate with VLR subscr, another connection is already active at IMSI-262423403******:MSISDN-******:TMSI-0x7CB52857:GERAN-A-2:PAGING_RESP"
23:45 < fixeria> LaF0rge: I guess the problem is that rf-locking causes osmo-bts to reset the scheduler, from what I see in the logs
23:47 < fixeria> "DL1C NOTICE scheduler.c:616 Exit scheduler for trx=0" then "DL1C NOTICE scheduler.c:591 Init scheduler for trx=0"
23:48 < fixeria> this is basically a result of trx_sched_reset() that calls trx_sched_exit() and then trx_sched_init()
23:49 < fixeria> so if we reset the scheduler, the BTS would simply "forget" all active connections and never report "radio link failure(s)"
23:59 <@LaF0rge> fixeria: I think the radio link timeout etc. are implemented above L1SAP
23:59 <@LaF0rge> fixeria: but maybe if no more events are coming up from the bts-model part, those are never triggered.
00:00 < fixeria> LaF0rge: ok, I'll open a ticket with all the findings
</pre>
<p>I think we can fix this by sending the <em>RSL Radio Link Failure</em> for all (still) active DCCHs as soon as the ramping down is completed.<br />And this seems to be what the other BTS models are doing when a transceiver gets RF-locked.</p> Cellular Network Infrastructure - Bug #4659 (Rejected): ttcn3-bts-test: sporadic test case failur...https://projects.osmocom.org/issues/46592020-07-09T09:49:29Zfixeria
<p>It was first noticed by <a class="user active" href="https://projects.osmocom.org/users/91">neels</a> that in build#945 [1] we got more failed test cases than usually. Now I see similar failures in build#949 [2]. The build aftifacts in both cases look really suspicious: it seems like <strong>osmo-bts-trx did not even try to establish any OML/RSL connections</strong> [3]. The packet captures [4] contain no A-bis traffic at all. What's even more strange is that osmo-bts-trx was scheduling Downlink bursts even without being connected to the BSC. This needs to be investigated.</p>
<p>[1] <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/945/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/945/</a><br />[2] <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 />[3] <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/artifact/logs/bts-tester/BTS_Tests.TC_pcu_act_req.merged">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/artifact/logs/bts-tester/BTS_Tests.TC_pcu_act_req.merged</a><br />[4] <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/artifact/logs/bts-tester/BTS_Tests.TC_pcu_act_req.pcap">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/949/artifact/logs/bts-tester/BTS_Tests.TC_pcu_act_req.pcap</a></p> Cellular Network Infrastructure - Bug #4617 (Resolved): ttcn3-bsc-test: sporadic TC_ho_neighbor_c...https://projects.osmocom.org/issues/46172020-06-17T08:22:45Zfixeria
<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>
<ul>
<li>TC_ho_neighbor_config_2 (see build 1000 and 1002)</li>
<li>TC_ho_neighbor_config_6 (see build 995)</li>
<li>TC_ho_neighbor_config_7 (see build 999)</li>
</ul>
<p>Here is an extract from build artifacts:</p>
<pre>
06:18:28.242981 785 RSL_Emulation.ttcn:581 Message with id 19 was extracted from the queue of IPA_PT.
06:18:28.243004 785 RSL_Emulation.ttcn:205 No Dchan handler for trx_nr=0 and chan_nr={ u := { ch0 := RSL_CHAN_NR_Bm_ACCH (1) }, tn := 1 }
06:18:28.243112 790 RSL_Emulation.ttcn:674 Called on RSL_PROC to IPA0-RSL-RSL(785) @RSL_Emulation.RSLEM_register : { trx_nr := 0, chan_nr := { u := { ch0 := RSL_CHAN_NR_Bm_ACCH (1) }, tn := 1 }, hdlr := TC_ho_neighbor_config_2(790) }
06:18:28.243156 785 RSL_Emulation.ttcn:588 setverdict(fail): none -> fail reason: "RSL for unknown Dchan", new component reason: "RSL for unknown Dchan"
06:18:28.243186 785 RSL_Emulation.ttcn:589 Stopping MTC. The current test case will be terminated.
06:18:28.243204 785 RSL_Emulation.ttcn:589 Stopping test component execution.
</pre>
<p>Note that ttcn3-bsc-test-latest is not affected. Any ideas?</p> 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 SDR PHY - Bug #3459 (Stalled): apps/grgsm_trx: AssertionError: packe t_info.packet_coun...https://projects.osmocom.org/issues/34592018-08-09T19:10:03Zfixeria
<p>Despite actual burst transmission works, I see the following messages repeated multiple times:</p>
<pre>
[i] Recv POWEROFF cmd
[i] Stopping transceiver...
[i] Setting TA value 0
[i] Recv ECHO cmd
[i] Recv SETSLOT cmd
[i] Configure timeslot filter to: drop all
[i] Recv MEASURE cmd
[i] Recv POWEROFF cmd
[i] Recv ECHO cmd
[i] Recv SETSLOT cmd
[i] Configure timeslot filter to: TS 0
[i] Recv POWERON CMD
[i] Starting transceiver...
thread[thread-per-block[15]: <block gr uhd usrp sink (8)>]: EnvironmentError: IOError: Radio ctrl (0) packet parse error - AssertionError: packe
t_info.packet_count == (seq_to_ack & 0xfff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at /build/libuhd/src/uhd-3.11.1.0/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:254
</pre>
<p>Observed within a Docker image wit the recent software:</p>
<ul>
<li>UHD_3.11.1.0-0-unknown</li>
<li>GNU Radio 3.7.11-6</li>
<li>GR-GSM TRX from fixeria/trx</li>
</ul>
<p>Could you please have a look?<br />Do you see this too?</p> OsmocomBB SDR PHY - Bug #3458 (Stalled): apps/grgsm_trx: [ERROR] [STREAMER] recv packet demuxer u...https://projects.osmocom.org/issues/34582018-08-09T18:29:31Zfixeria
<p>Sometimes, while running the following output appears:</p>
<pre>
[i] Recv ECHO cmd
[i] Recv POWEROFF cmd
[i] Recv ECHO cmd
[i] Recv SETSLOT cmd
[i] Configure timeslot filter to: TS 0
[i] Recv RXTUNE cmd
[i] Recv TXTUNE cmd
[i] Recv POWERON CMD
[i] Starting transceiver...
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x0
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x4a000f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xe0024
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x37ffe7
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1b0005
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff530020
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xcff6d
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x7ffc8
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffbeff95
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x65000f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffb20072
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x16ffc9
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff5fff1
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffc400bb
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xcffdd
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffdcffcb
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffb2fff5
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffd5ffc4
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x38fff2
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffcf0000
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xbb0069
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x12ffcc
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffb6001f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffd7001e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x14004c
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffa6ffe8
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xa002a
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff76003f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff96ffd3
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x130013
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffd5ffe3
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x4001e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff8c0075
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff0000f
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xdffee
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff40011
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1afff9
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff9aff5d
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff9afffa
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x7ffce
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffcb0008
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xfff7ffdd
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x5a005e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x38ffca
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x6ffa2
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x4ffcc
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffba00ab
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xff420029
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1effe2
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x70067
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1a001e
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x1a0016
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xb00a5
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffbe0008
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffe6001a
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffcfffc3
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0x130003
[ERROR] [STREAMER] recv packet demuxer unexpected sid 0xffceff44
</pre> Cellular Network Infrastructure - Feature #3455 (Rejected): docker-playground/debian-jessie-build...https://projects.osmocom.org/issues/34552018-08-08T15:46:44Zfixeria
<p>While building the recent 'debian-jessie-build' Docker image, I noticed that there<br />are some packages which are not common for all projects, in particular:</p>
<ul>
<li>libdbd-sqlite3</li>
<li>libdbi-dev</li>
<li>libfftw3-dev</li>
<li>libgps-dev</li>
<li>libgsm1-dev</li>
<li>libncurses5-dev</li>
<li>libortp-dev</li>
<li>lbfftw3-devibsctp-dev</li>
<li>libsofia-sip-ua-glib-dev</li>
<li>libsqlite3-dev</li>
<li>libusb-dev</li>
<li>libusb-1.0-0-dev</li>
<li>sqlite3</li>
</ul>
<p>I think they should not be common for all other images based on this one,<br />and it makes sense to specify them in the individual Dockerfiles...</p> OsmocomBB SDR PHY - Bug #3425 (Stalled): Receiver: missing AGC (Automatic Gain Control)https://projects.osmocom.org/issues/34252018-07-26T20:25:52Zfixeria
<p>When the signal becomes too strong, we need to decrease the gain to avoid saturation.<br />When the signal becomes less powerful, we need to increase the gain...</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> libosmocore - Bug #2229 (Closed): tests/kasumi/kasumi_test.c: missed check resulthttps://projects.osmocom.org/issues/22292017-05-04T16:26:58Zfixeria
<p>Have a look at test_expansion():</p>
<pre>
_kasumi_key_expand(test_key, _KLi1, _KLi2, _KOi1, _KOi2, _KOi3, _KIi1, _KIi2, _KIi3);
int passed = 1;
passed = _compare_mem((uint8_t *)_KLi1, (uint8_t *)_KLi1_r, 16);
passed = _compare_mem((uint8_t *)_KLi2, (uint8_t *)_KLi2_r, 16);
passed = _compare_mem((uint8_t *)_KOi1, (uint8_t *)_KOi1_r, 16);
passed = _compare_mem((uint8_t *)_KOi2, (uint8_t *)_KOi2_r, 16);
passed = _compare_mem((uint8_t *)_KOi3, (uint8_t *)_KOi3_r, 16);
passed = _compare_mem((uint8_t *)_KIi1, (uint8_t *)_KIi1_r, 16);
passed = _compare_mem((uint8_t *)_KIi2, (uint8_t *)_KIi2_r, 16);
passed = _compare_mem((uint8_t *)_KIi3, (uint8_t *)_KIi3_r, 16);
printf(passed ? " OK. " : "FAILED!");
</pre>
<p>Only the last check value makes sense here. Other check values<br />are being overwritten. What about:</p>
<pre>
int passed = 1;
_kasumi_key_expand(test_key, _KLi1, _KLi2, _KOi1, _KOi2, _KOi3, _KIi1, _KIi2, _KIi3);
passed &= _compare_mem((uint8_t *)_KLi1, (uint8_t *)_KLi1_r, 16);
passed &= _compare_mem((uint8_t *)_KLi2, (uint8_t *)_KLi2_r, 16);
passed &= _compare_mem((uint8_t *)_KOi1, (uint8_t *)_KOi1_r, 16);
passed &= _compare_mem((uint8_t *)_KOi2, (uint8_t *)_KOi2_r, 16);
passed &= _compare_mem((uint8_t *)_KOi3, (uint8_t *)_KOi3_r, 16);
passed &= _compare_mem((uint8_t *)_KIi1, (uint8_t *)_KIi1_r, 16);
passed &= _compare_mem((uint8_t *)_KIi2, (uint8_t *)_KIi2_r, 16);
passed &= _compare_mem((uint8_t *)_KIi3, (uint8_t *)_KIi3_r, 16);
printf(passed ? " OK. " : "FAILED!");
</pre> libosmocore - Bug #2228 (Closed): tests/fsm/fsm_test.c: unreacheable codehttps://projects.osmocom.org/issues/22282017-05-04T16:11:54Zfixeria
<pre>
static struct ctrl_cmd *exec_ctrl_cmd(const char *cmdstr)
{
struct ctrl_cmd *cmd;
return ctrl_cmd_exec_from_string(g_ctrl, cmdstr);
OSMO_ASSERT(cmd);
return cmd;
}
</pre> libosmocore - Bug #2222 (Closed): gsm/tlv.h: unreachable part of codehttps://projects.osmocom.org/issues/22222017-05-04T09:42:08Zfixeria
<p>Look at include/osmocom/gsm/tlv.h:63</p>
<pre>
/*! \brief gross length of vTvLV (tag+len+val) */
static inline uint16_t VTVLV_GAN_GROSS_LEN(uint16_t tag, uint16_t len)
{
uint16_t ret;
if (len <= TVLV_MAX_ONEBYTE)
return TLV_GROSS_LEN(len);
else
return TL16V_GROSS_LEN(len);
if (tag > TVLV_MAX_ONEBYTE)
ret += 1;
return ret;
}
</pre>
<p>Second condition is unreachable part of code.</p> OsmocomBB - Support #1639 (Closed): BCCH at TS1-7 supporthttps://projects.osmocom.org/issues/16392016-03-09T15:02:23Zfixeria
<p>The specs says it's possible to have paging channels on other time slots than 0.<br />But support for it is not implemented in Osmocom-bb...</p> OsmocomBB - Support #1627 (Stalled): DCS_8BIT and DCS_UCS2 encoding supprothttps://projects.osmocom.org/issues/16272016-02-29T03:46:52Zfixeria
<p>Currently it is impossible to send/receive SMS messages and USSD encoded in 8-bit or 16-bit alphabet.</p>