Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-03-22T07:59:15ZOpen Source Mobile Communications
Redmine OsmoMSC - Bug #6414 (Resolved): ttcn3-msc-test: TC_ho_inter_bsc_a5_[134] are failing with io_uringhttps://projects.osmocom.org/issues/64142024-03-22T07:59:15Zfixeria
<p>Since recently, we started executing ttcn3-msc-test (among with some other testsuites) with <code>LIBOSMO_IO_BACKEND=IO_URING</code> in a separate job. Compared to the "normal" job, the IO_URING one exhibits a regression since <a href="https://jenkins.osmocom.org/jenkins/view/TTCN3-io_uring/job/ttcn3-msc-test-io_uring/5/" class="external">build 5</a> (Mar 15, 2024):</p>
<ul>
<li>TC_ho_inter_bsc_a5_3 is failing "reliably",</li>
<li>TC_ho_inter_bsc_a5_<sup><a href="#fn14">14</a></sup> are alternating between pass and fail.</li>
</ul>
<p>I was unable to reproduce the problem, neither locally on my machine nor on the dedicated build server in Docker env.</p> 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> 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> 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> Cellular Network Infrastructure - Bug #6352 (Stalled): ttcn3-bts-test[-latest] is broken since Fe...https://projects.osmocom.org/issues/63522024-02-05T09:25:36Zfixeria
<p>ttcn3-bts-test[-latest] is failing for a few days already:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/</a></p>
<p>The console log (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console</a>) tells us about problems with the virtphy:</p>
<pre>
+ docker kill jenkins-ttcn3-bts-test-2293-virtphy
Error response from daemon: Cannot kill container: jenkins-ttcn3-bts-test-2293-virtphy: No such container: jenkins-ttcn3-bts-test-2293-virtphy
</pre>
<p>Here is the related logging (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log</a>):</p>
<pre>
0: starting: osmo-bts-virtual -c /data/osmo-bts.gen.cfg
((*))
|
/ \ OsmoBTS
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853486 DLGLOBAL NOTICE Setting up GSMTAP Um forwarding '(null)->'172.18.29.10:4729' (main.c:363)
20240201061853486 DLCTRL NOTICE CTRL at 0.0.0.0 4238 (control_if.c:1014)
20240201061853487 DL1C NOTICE Unimplemented bts_model_ctrl_cmds_install (bts_model.c:222)
20240201061853487 DLGLOBAL NOTICE Available via telnet 0.0.0.0 4241 (telnet_interface.c:88)
20240201061853487 DPCU INFO Started listening on PCU socket (PCU IF v12): /data/unix/pcu_sock (pcu_sock.c:1237)
20240201061853487 DOSMUX INFO Osmux socket listening on 172.18.29.20:1984 (osmux.c:352)
20240201061853487 DABIS NOTICE A-bis connection establishment to BSC (127.0.0.11) in progress... (abis.c:161)
20240201061853487 DLINP NOTICE enabling ipaccess BTS mode, OML connecting to 127.0.0.11:3002 (ipaccess.c:1098)
20240201061853487 DL1C INFO phy0: PHY link state change shutdown -> connecting (phy_link.c:58)
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
20240201061853487 DL1C INFO phy0: PHY link state change connecting -> shutdown (phy_link.c:58)
unable to open PHY link(s)
0: stopped pid 8 with status 2
</pre>
<p>The virtphy container (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log</a>) fails to start:</p>
<pre>
Thu Feb 1 06:18:53 2024 DVIRPHY virtphy.c:248 Virtual physical layer starting up...
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
Segmentation fault (core dumped)
</pre> Cellular Network Infrastructure - Bug #6349 (Feedback): example configs missing in release tarballshttps://projects.osmocom.org/issues/63492024-01-28T15:42:07Zfixeria
<p>Today I created a release <code>osmo-bts v1.7.2</code> package for Arch Linux:</p>
<p><a class="external" href="https://aur.archlinux.org/packages/osmo-bts">https://aur.archlinux.org/packages/osmo-bts</a><br /><a class="external" href="https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=osmo-bts">https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=osmo-bts</a></p>
<p>which downloads, unpacks, and builds the latest release tarball:</p>
<p><a class="external" href="https://downloads.osmocom.org/releases/osmo-bts/osmo-bts-1.7.2.tar.bz2">https://downloads.osmocom.org/releases/osmo-bts/osmo-bts-1.7.2.tar.bz2</a></p>
<p>Unfortunately, I am hitting a build error when running <code>makepkg</code>:</p>
<pre>
Making all in doc
make[2]: Entering directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc'
Making all in examples
make[3]: Entering directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc/examples'
make[3]: *** No rule to make target 'trx/osmo-bts-trx.cfg', needed by 'all-am'. Stop.
make[3]: Leaving directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc/examples'
make[2]: *** [Makefile:387: all-recursive] Error 1
make[2]: Leaving directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2/doc'
make[1]: *** [Makefile:446: all-recursive] Error 1
make[1]: Leaving directory '/home/fixeria/projects/archlinux/osmo-bts/src/osmo-bts-1.7.2'
make: *** [Makefile:378: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...
</pre>
<p>The problem can be reproduced by downloading and building the tarball manually (make sure to build with <code>--enable-trx</code>).</p>
<p>Surprisingly, <code>trx/osmo-bts-trx.cfg</code> is not present in the release tarball:</p>
<pre>
$ tar -tvf osmo-bts-1.7.2.tar.bz2 | grep doc/examples
drwxr-xr-x 1000/1000 0 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/
-rw-r--r-- 1000/1000 23617 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/Makefile.in
drwxr-xr-x 1000/1000 0 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/virtual/
-rw-r--r-- 1000/1000 1271 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/virtual/osmo-bts-virtual.cfg
-rw-r--r-- 1000/1000 1501 2023-12-15 12:19 osmo-bts-1.7.2/doc/examples/Makefile.am
</pre>
<p>I believe the problem is that in <code>doc/examples/Makefile.am</code> we add config files to <code>EXTRA_DIST</code> conditionally:</p>
<pre><code class="shell syntaxhl"><span class="k">if </span>ENABLE_TRX
doc_trxdir <span class="o">=</span> <span class="si">$(</span>docdir<span class="si">)</span>/examples/osmo-bts-trx
doc_trx_DATA <span class="o">=</span> <span class="se">\</span>
trx/osmo-bts-trx.cfg <span class="se">\</span>
trx/osmo-bts-trx-calypso.cfg
EXTRA_DIST +<span class="o">=</span> <span class="si">$(</span>doc_trx_DATA<span class="si">)</span>
OSMOCONF_FILES +<span class="o">=</span> trx/osmo-bts-trx.cfg
endif
</code></pre>
<p>So if the project is configured without <code>--enable-foo</code>, then <code>make dist-bzip2</code> will produce a tarball without those files added conditionally.</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> OsmoMSC - Bug #6330 (New): Incorrect handling of V.120 data callshttps://projects.osmocom.org/issues/63302024-01-18T15:02:29Zfixeria
<p>Current osmo-msc (8236184ef05e5b10505bbb3189357d2050bbdc5d) fails to connect a V.120 data call, see the attached PCAP.</p>
<p>How to reproduce:</p>
<ul>
<li>find phone(s)/modem(s) supporting V.120 data calls
<ul>
<li>the result of <code>AT+CBST=?</code> should contain one of V.120 rates: 39, 43, 47, 48</li>
<li>most Sony Ericsson phones/modems can do V.120: <code>+CBST: (0,7,12,14-17,39,43,47-51,71,75,79-84),(0,4),(1)</code></li>
</ul>
</li>
<li>configure phone(s)/modem(s) to use V.120, for example: <code>AT+CBST=39,0,1</code> for 9600 bps</li>
<li>initiate a data call, for example: <code>ATD15843</code></li>
</ul>
<p>In my case (using SE K800), the call is aborted due to Assignment Failure, because osmo-msc sends weird Assignment Command:</p>
<pre>
GSM A-I/F BSSMAP - Assignment Request
Message Type Assignment Request
Channel Type - (Data)
Element ID: 0x0b
Length: 3
0000 .... = Spare bit(s): 0x00
.... 0010 = Speech/Data Indicator: Data (2)
.000 1010 = Channel rate and type: Full or Half rate TCH channel, Full rate preferred, changes allowed also after first channel allocation as a result of the request (10)
0... .... = Extension: Last Octet
.0.. .... = Service: Transparent
..01 0010 = Rate: 2.4kbit/s
...
</pre>
<p><code>2.4kbit/s</code> / <code>Transparent</code> is definitely not what the calling phone requested, it should be <code>9.6kbit/s</code> / <code>Non-transparent</code>.</p>
<p>Below is how the Bearer Capability looks like for <code>AT+CBST=39,0,1</code>:</p>
<pre>
Bearer Capability 1 - (Full rate support only MS)
Element ID: 0x04
Length: 12
Octet 3
1... .... = Extension: No Extension
.01. .... = Radio channel requirement: Full rate support only MS
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .001 = Information transfer capability: Unrestricted digital information (0x1)
Octet 4
1... .... = Extension: No Extension
.1.. .... = Compression: Allowed
..00 .... = Structure: Service data unit integrity (0)
.... 1... = Duplex mode: Full
.... .0.. = Configuration: Point-to-point
.... ..0. = NIRR: No meaning is associated with this value
.... ...0 = Establishment: Demand
Octet 5
0... .... = Extension: Extended
.00. .... = Access Identity: Octet identifier (0)
...1 1... = Rate Adaption: Other rate adaption (see octet 5a) (3)
.... .001 = Signalling Access Protocol: According to ITU-T Rec. Q.920 and ITU-T Rec. Q.930 (1)
Octet 5a
0... .... = Extension: Extended
.00. .... = Other ITC: Restricted digital information (0)
...0 0... = Other Rate Adaption: According to ITU-T Rec. V.120 (0)
.... .000 = Spare bit(s): 0
Octet 5b
1... .... = Extension: No Extension
.1.. .... = Rate Adaption Header: Included
..1. .... = Multiple frame establishment support in data link: Supported
...1 .... = Mode of operation: Protocol sensitive
.... 0... = Logical link identifier negotiation: Default, LLI=256 only
.... .0.. = Assignor/Assignee: Message originator is default assignee
.... ..0. = In band/Out of band negotiation: Negotiation is done in-band using logical link zero
.... ...0 = Spare bit(s): 0
Octet 6
0... .... = Extension: Extended
.01. .... = Layer 1 Identity: Octet identifier
...0 000. = User information layer 1 protocol: Default layer 1 protocol
.... ...1 = Synchronous/asynchronous: Asynchronous
Octet 6a
0... .... = Extension: Extended
.0.. .... = Number of Stop Bits: 1
..0. .... = Negotiation: In-band negotiation not possible
...1 .... = Number of data bits excluding parity bit if present: 8
.... 0101 = User rate: 9.6 kbit/s (according to ITU-T Rec. X.1 and ITU-T Rec. V.110)
Octet 6b
0... .... = Extension: Extended
.11. .... = V.110/X.30 rate adaptation Intermediate rate: 16 kbit/s (3)
...0 .... = Network independent clock (NIC) on transmission (Tx): does not require to send data with network independent clock
.... 0... = Network independent clock (NIC) on reception (Rx): cannot accept data with network independent clock
.... .011 = Parity information: None (3)
Octet 6c
0... .... = Extension: Extended
.01. .... = Connection element: Non transparent (RLP) (1)
...0 0000 = Modem type: None
Octet 6d
0... .... = Extension: Extended
.00. .... = Other modem type: No other modem type specified in this field (0)
...0 0001 = Fixed network user rate: 9.6 kbit/s (according to ITU-T Rec. X.1 and ITU-T Rec. V.110)
Octet 6e
0... .... = Extension: Extended
.1.. .... = Acceptable channel codings (TCH/F14.4): Acceptable
..0. .... = Acceptable channel codings (Spare): False
...1 .... = Acceptable channel codings (TCH/F9.6): Acceptable
.... 0... = Acceptable channel codings (TCH/F4.8): Not Acceptable
.... .001 = Maximum number of traffic channels: 1 TCH
Octet 6f
1... .... = Extension: No Extension
.000 .... = UIMI, User initiated modification indication: not allowed/required/applicable (0)
.... 0001 = Wanted air interface user rate: 9.6 kbit/s (1)
</pre> 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> Cellular Network Infrastructure - Bug #6325 (Resolved): ttcn3-msc-test: MSC_Tests_ASCI.TC_complet...https://projects.osmocom.org/issues/63252024-01-09T14:24:27Zfixeria
<p>First of all, I found out that testcases from <code>MSC_Tests_ASCI</code> are not being executed on Jenkins:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/docker-playground/+/35521">https://gerrit.osmocom.org/c/docker-playground/+/35521</a> ttcn3-msc-test: also execute ASCI (VBS/VGCS) testcases</p>
<p>thanks to the config file duplication between osmo-ttcn3-hacks.git and docker-playground.git :(</p>
<p>I noticed this while running ttcn3-msc-test locally and seeing that the following testcases fail:</p>
<ul>
<li>NEW: FAIL MSC_Tests_ASCI.TC_complete_vgcs</li>
<li>NEW: FAIL MSC_Tests_ASCI.TC_complete_vbs</li>
</ul>
<p>The failure verdicts vary between consecutive test runs, here is what I saw last time:</p>
<pre>
TC_complete_vgcs0(13)@LEGION: setverdict(fail): none -> fail reason: "Got unexpected message on control connection.", new component reason: "Got unexpected message on control connection."
TC_complete_vgcs0(13)@LEGION: Final verdict of PTC: fail reason: "Got unexpected message on control connection."
MTC@LEGION: setverdict(fail): none -> fail reason: "Timeout waiting for Test result", new component reason: "Timeout waiting for Test result"
MTC@LEGION: Dynamic test case error: Port COORD_control has neither connections nor mappings. Message cannot be sent on it.
MTC@LEGION: setverdict(error): fail -> error
MTC@LEGION: Test case TC_complete_vbs finished. Verdict: fail reason: Couldn't find Expect for incoming connection { calledAddress := { addressIndicator := { pointCodeIndic := '1'B, ssnIndicator := '1'B, globalTitleIndic := '0000'B, routingIndicator := '1'B }, signPointCode := '00000011000001'B, subsystemNumber := 254, globalTitle := omit }, callingAddress := { addressIndicator := { pointCodeIndic := '1'B, ssnIndicator := '1'B, globalTitleIndic := '0000'B, routingIndicator := '1'B }, signPointCode := '00000010111001'B, subsystemNumber := 254, globalTitle := omit }, qualityOfService := omit, userData := { discriminator := '0'B, spare := '0000000'B, dlci := omit, lengthIndicator := 36, pdu := { bssmap := { vGCS_VBSAssignmentRequest := { messageType := '07'O ("\a"), channelType := { elementIdentifier := '0B'O ("\v"), lengthIndicator := 3, speechOrDataIndicator := '0001'B, spare1_4 := '0000'B, channelRateAndType := '08'O ("\b"), speechId_DataIndicator := '01'O }, assignmentRequirement := { elementIdentifier := '33'O ("3"), assignmentRequirement := '01'O }, cellIdentifier := { elementIdentifier := '05'O, lengthIndicator := 3, cellIdentifierDiscriminator := '0010'B, spare1_4 := '0000'B, cellIdentification := { cI_CI := '002A'O } }, groupCallReference := { elementIdentifier := '37'O ("7"), lengthIndicator := 5, descrGroupbroadcastCallRef := '00001A0000'O }, priority := omit, circuitIdentityCode := omit, downLinkDTX_Flag := omit, encryptionInformation := omit, vSTK_RAND := omit, vSTK := omit, cellIdentifierListSegment := omit, aoIPTransportLayer := { elementIdentifier := '7C'O ("|"), lengthIndicator := 6, ipAddress := { ipv4 := '01010101'O }, uDPPortValue := 10000 }, callIdentifier := { elementIdentifier := '7F'O, callIdentifierInfo := '01000000'O }, codecList := { elementIdentifier := '7D'O ("}"), lengthIndicator := 1, codecElements := { { codecType := GSM_FR (0), tF := '0'B, pT := '0'B, pI := '0'B, fI := '1'B, extendedCodecType := omit, s0_7 := omit, s8_15 := omit } } } } } } }, connectionId := 16002295, importance := omit }
</pre>
<p>Please find the respective PCAP files attached.</p>
<p>libosmocore.git 85554db38d45c3f2e72b5b9c37a5c1c7b9ecc009<br />osmo-msc.git 4fa6c2f636261927a70677963109c569920e473f</p> OsmoPCU - Bug #6310 (Resolved): ttcn3-pcu-test: TITAN error "Buffer too large for requested CS! e...https://projects.osmocom.org/issues/63102023-12-15T09:15:35Zfixeria
<p>I am getting this error when running ttcn3-pcu-test using TITAN v10.0.0:</p>
<pre>
MTC@LEGION: Rx DL block USF 0 vs exp USF 0
Buffer too large for requested CS! encode_trailing_padding_spb (RLCMAC_EncDec.cc:456)
Error: Unexpected end of MTC connection from 192.168.1.231 [192.168.1.231].
MC@LEGION: The control connection to MTC is lost. Destroying all PTC connections.
MC@LEGION: MTC terminated.
ttcn3_start: error: the MTC terminated unexpectedly
exit
MC@LEGION: Shutting down session.
MC@LEGION: Shutdown complete.
Dynamic test case error: Sending data on the control connection to MC failed.Dynamic test case error: Control connection was closed unexpectedly by MC.
Dynamic test case error: Control connection was closed unexpectedly by MC.Dynamic test case error: Control connection was closed unexpectedly by MC.Dynamic test case error: Control connection was closed unexpectedly by MC.
</pre>
<p>As a result, the testsuite aborts early and does not execute pending tests.</p>
<p>I can reliably reproduce this by running <code>PCU_Tests.TC_ul_data_toolong_fills_padding</code>.</p> OsmoBTS - Bug #6309 (Resolved): ttcn3-bts-test: TC_rll_est_ind failing since Dec 12https://projects.osmocom.org/issues/63092023-12-14T07:44:51Zfixeria
<p>This testcase is failing starting from Dec 12:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2242/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2242/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-bts-test/1314/">https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-bts-test/1314/</a></p>
<pre>
"BTS_Tests.ttcn:7242 : Timeout waiting for EST IND"
BTS_Tests.ttcn:9375 BTS_Tests control part
BTS_Tests.ttcn:7267 TC_rll_est_ind testcase
</pre>
<p>The -latest release is not affected:</p>
<p><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><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-bts-test-latest/">https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-bts-test-latest/</a></p>
<p>The testcase consists of several sub-cases:</p>
<pre><code class="javascript syntaxhl"><span class="mi">7253</span> <span class="nx">testcase</span> <span class="nx">TC_rll_est_ind</span><span class="p">()</span> <span class="nx">runs</span> <span class="nx">on</span> <span class="nx">test_CT</span> <span class="p">{</span>
<span class="mi">7254</span> <span class="kd">var</span> <span class="nx">RllTestCases</span> <span class="nx">tcs</span> <span class="p">:</span><span class="o">=</span> <span class="p">{</span>
<span class="mi">7255</span> <span class="cm">/* SAPI0 establishment (contention resolution) */</span>
<span class="mi">7256</span> <span class="nx">valueof</span><span class="p">(</span><span class="nx">t_EITC</span><span class="p">(</span><span class="mi">0</span><span class="p">,</span> <span class="nx">ts_RslLinkID_DCCH</span><span class="p">(</span><span class="mi">0</span><span class="p">),</span> <span class="dl">'</span><span class="s1">01020304</span><span class="dl">'</span><span class="nx">O</span><span class="p">,</span> <span class="kc">true</span><span class="p">)),</span>
<span class="mi">7257</span> <span class="cm">/* normal SAPI0 establishment */</span>
<span class="mi">7258</span> <span class="nx">valueof</span><span class="p">(</span><span class="nx">t_EITC</span><span class="p">(</span><span class="mi">0</span><span class="p">,</span> <span class="nx">ts_RslLinkID_DCCH</span><span class="p">(</span><span class="mi">0</span><span class="p">),</span> <span class="dl">''</span><span class="nx">O</span><span class="p">,</span> <span class="kc">true</span><span class="p">)),</span> <span class="c1">// <----- this one is failing</span>
<span class="mi">7259</span> <span class="cm">/* SAPI 3 doesn't support contention resolution */</span>
<span class="mi">7260</span> <span class="nx">valueof</span><span class="p">(</span><span class="nx">t_EITC</span><span class="p">(</span><span class="mi">3</span><span class="p">,</span> <span class="nx">ts_RslLinkID_DCCH</span><span class="p">(</span><span class="mi">3</span><span class="p">),</span> <span class="dl">'</span><span class="s1">01020304</span><span class="dl">'</span><span class="nx">O</span><span class="p">,</span> <span class="kc">false</span><span class="p">)),</span>
<span class="mi">7261</span> <span class="nx">valueof</span><span class="p">(</span><span class="nx">t_EITC</span><span class="p">(</span><span class="mi">3</span><span class="p">,</span> <span class="nx">ts_RslLinkID_SACCH</span><span class="p">(</span><span class="mi">3</span><span class="p">),</span> <span class="dl">'</span><span class="s1">01020304</span><span class="dl">'</span><span class="nx">O</span><span class="p">,</span> <span class="kc">false</span><span class="p">)),</span>
<span class="mi">7262</span> <span class="cm">/* normal SAPI3 establishment on main DCCH */</span>
<span class="mi">7263</span> <span class="nx">valueof</span><span class="p">(</span><span class="nx">t_EITC</span><span class="p">(</span><span class="mi">3</span><span class="p">,</span> <span class="nx">ts_RslLinkID_DCCH</span><span class="p">(</span><span class="mi">3</span><span class="p">),</span> <span class="dl">''</span><span class="nx">O</span><span class="p">,</span> <span class="kc">true</span><span class="p">)),</span>
<span class="mi">7264</span> <span class="cm">/* normal SAPI3 establishment on SACCH */</span>
<span class="mi">7265</span> <span class="nx">valueof</span><span class="p">(</span><span class="nx">t_EITC</span><span class="p">(</span><span class="mi">3</span><span class="p">,</span> <span class="nx">ts_RslLinkID_SACCH</span><span class="p">(</span><span class="mi">3</span><span class="p">),</span> <span class="dl">''</span><span class="nx">O</span><span class="p">,</span> <span class="kc">true</span><span class="p">))</span>
<span class="mi">7266</span> <span class="p">};</span>
<span class="mi">7267</span> <span class="nx">f_rll_testmatrix</span><span class="p">(</span><span class="nx">tcs</span><span class="p">,</span> <span class="nx">refers</span><span class="p">(</span><span class="nx">f_TC_rll_est_ind</span><span class="p">));</span>
<span class="mi">7268</span> <span class="p">}</span>
</code></pre>
<p>I am seeing this error in the logging:</p>
<pre>
20231214142417312 DRSL ERROR (bts=0,trx=0,ts=1,ss=0) RLL EST IND without contention resolution. (rsl.c:3843)
</pre>
<p>so assuming it's related to a recently merged patch:</p>
<p><a class="external" href="https://cgit.osmocom.org/osmo-bts/commit/?id=647b8d09782a57504e2ab760456f81623601f312">https://cgit.osmocom.org/osmo-bts/commit/?id=647b8d09782a57504e2ab760456f81623601f312</a></p>
<pre>
commit 647b8d09782a57504e2ab760456f81623601f312
Author: Andreas Eversberg <jolly@eversberg.eu>
Date: Tue Nov 21 14:26:43 2023 +0100
LAPDm: Reject (release) establishment on DCCH, SAPI 0 without L3 payload
</pre> OsmoGSMTester - Bug #6304 (Resolved): osmo-gsm-tester_virtual is broken since build 7424https://projects.osmocom.org/issues/63042023-12-12T16:19:59Zfixeria
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_virtual/7424/">https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_virtual/7424/</a> -- was aborted by <a class="user active" href="https://projects.osmocom.org/users/301771">osmith</a> because it was executing too long (for 3 days 11 hr!)<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_virtual/7425/">https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_virtual/7425/</a> -- broken, executed on Dec 11, took 9 min 11 sec<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_virtual/7426/">https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_virtual/7426/</a> -- broken, executed on Dec 11, took 4 min 46 sec</p>
<p>The last two builds are failing with the following verdicts, respectively:</p>
<pre>
FAIL: netreg_mass (fail: 1)
FAIL: register_default_mass.py (141.8 sec) Exception: Completion ratio of 26.000000% lower than threshold.
FAIL: netreg_mass (fail: 1)
FAIL: register_default_mass.py (141.5 sec) Exception: Completion ratio of 18.000000% lower than threshold.
</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> OsmocomBB - Bug #6280 (Resolved): mobile: issues with RR Measurement Reporthttps://projects.osmocom.org/issues/62802023-12-02T17:58:24Zfixeria
<p>Since recently (maybe one or even two months ago) when using osmocom-bb/mobile I started seeing these warnings printed by osmo-bsc:</p>
<pre>
DRSL DEBUG abis_rsl.c:1519 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=5 meas_rep_last_seen_nr=4
DRR ERROR gsm_04_08_rr.c:1005 Invalid BCCH channel list index 0 in measurement report
DRSL DEBUG abis_rsl.c:1519 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=6 meas_rep_last_seen_nr=5
DRR ERROR gsm_04_08_rr.c:1005 Invalid BCCH channel list index 0 in measurement report
DRSL DEBUG abis_rsl.c:1519 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=7 meas_rep_last_seen_nr=6
DRR ERROR gsm_04_08_rr.c:1005 Invalid BCCH channel list index 0 in measurement report
DRSL DEBUG abis_rsl.c:1519 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=8 meas_rep_last_seen_nr=7
DRR ERROR gsm_04_08_rr.c:1005 Invalid BCCH channel list index 0 in measurement report
DRSL DEBUG abis_rsl.c:1519 (bts=0,trx=0,ts=1,ss=0): meas_rep_count++=9 meas_rep_last_seen_nr=8
DRR ERROR gsm_04_08_rr.c:1005 Invalid BCCH channel list index 0 in measurement report
</pre>
<p>Please find a PCAP file attached. Here is one of the measurement reports as decoded by wireshark:</p>
<pre>
GSM A-I/F DTAP - Measurement Report
Protocol Discriminator: Radio Resources Management messages (6)
DTAP Radio Resources Management Message Type: Measurement Report (0x15)
Measurement Results
1... .... = BA-USED: 1
.0.. .... = DTX-USED: DTX was not used
..11 1111 = RXLEV-FULL-SERVING-CELL: >= -48 dBm (63)
0... .... = 3G-BA-USED: 0
.0.. .... = MEAS-VALID: The measurement results are valid
..11 1111 = RXLEV-SUB-SERVING-CELL: >= -48 dBm (63)
0... .... = SI23_BA_USED: 0
.000 .... = RXQUAL-FULL-SERVING-CELL: BER < 0.2%, Mean value 0.14% (0)
.... 000. = RXQUAL-SUB-SERVING-CELL: BER < 0.2%, Mean value 0.14% (0)
.... ...1 10.. .... = NO-NCELL-M: 6 neighbour cell measurement result (6)
..10 1110 = RXLEV-NCELL: 46
0000 0... = BCCH-FREQ-NCELL: 0
.... .000 000. .... = BSIC-NCELL: 0
...1 0111 0... .... = RXLEV-NCELL: 46
.000 00.. = BCCH-FREQ-NCELL: 0
.... ..00 0000 .... = BSIC-NCELL: 0
.... 1011 10.. .... = RXLEV-NCELL: 46
..00 000. = BCCH-FREQ-NCELL: 0
.... ...0 0000 0... = BSIC-NCELL: 0
.... .101 110. .... = RXLEV-NCELL: 46
...0 0000 = BCCH-FREQ-NCELL: 0
0000 00.. = BSIC-NCELL: 0
.... ..10 1110 .... = RXLEV-NCELL: 46
.... 0000 0... .... = BCCH-FREQ-NCELL: 0
.000 000. = BSIC-NCELL: 0
.... ...1 0111 0... = RXLEV-NCELL: 46
.... .000 00.. .... = BCCH-FREQ-NCELL: 0
..00 0000 = BSIC-NCELL: 0
No space for padding bits
</pre>
<p>I am running my own network with only one BCCH carrier, no neighbors. Looks like a regression is the mobile app to me.</p> OsmoPCU - Bug #6275 (Resolved): ttcn3-pcu-test-sns regressionshttps://projects.osmocom.org/issues/62752023-11-26T14:42:18Zfixeria
<p>ttcn3-pcu-test-sns looks unhealthy since recently:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-pcu-test-sns/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-pcu-test-sns/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-pcu-test-sns/">https://jenkins.osmocom.org/jenkins/view/TTCN3-centos/job/TTCN3-centos-pcu-test-sns/</a></p>
<p>Note that the -latest is not affected. Also note a core file in the artifacts.</p>
<p>The logging suggests there is a version mismatch?</p>
<pre>
PCU interface version number of BTS/BSC (11) is different (12).
Please use a BTS/BSC with a compatble interface!
0: stopped pid 8 with status 255
</pre> OsmoTRX - Bug #6247 (Rejected): osmo-trx-uhd: segfault with libuhd v4.5.0.0https://projects.osmocom.org/issues/62472023-11-06T17:19:09Zfixeria
<p>I just recompiled osmo-trx-uhd (992a49e586279e422f03b3766b3b4cd1aef409b8) due to a libuhd package update:</p>
<pre>
ноя 06 23:25:51 LEGION osmo-trx-uhd[336498]: /opt/osmocom/bin/osmo-trx-uhd: error while loading shared libraries: libuhd.so.4.4.0: cannot open shared object file: No such file or directory
</pre>
<p>and now it's crashing on POWERON from osmo-bts-trx:</p>
<pre>
fixeria@LEGION:~$ osmo-trx-uhd -C /etc/osmocom/osmo-trx-uhd.cfg
DLGLOBAL NOTICE telnet_interface.c:88 Available via telnet 127.0.0.1 4237
DLCTRL NOTICE control_if.c:1014 CTRL at 127.0.0.1 4236
DMAIN INFO osmo-trx.cpp:515 SSE3 support compiled in and supported by CPU
DMAIN INFO osmo-trx.cpp:527 SSE4.1 support compiled in and supported by CPU
DMAIN INFO osmo-trx.cpp:583 Config Settings
Log Level............... 0
Device args............. type=b200
TRX Base Port........... 5700
TRX Address............. 127.0.101.1
GSM BTS Address......... 127.0.101.1
Channels................ 1
Tx Samples-per-Symbol... 4
Rx Samples-per-Symbol... 4
EDGE support............ 0
Extended RACH support... 0
Reference............... 0
Filler Burst Type....... Empty bursts
Filler Burst TSC........ 0
Filler Burst RACH Delay. 0
Multi-Carrier........... 0
LO freq. offset......... 0
RSSI to dBm offset...... 45
Swap channels........... 0
Tx Antennas............. 'TX/RX'
Rx Antennas............. 'RX2'
[INFO] [UHD] linux; GNU C++ version 13.2.1 20230801; Boost_108300; UHD_4.5.0.0-0-unknown
DDEV INFO UHDDevice.cpp:521 Using discovered UHD device type=b200,name=MyB210,serial=30AC26A,product=B210
DDEVDRV INFO b200_impl.cpp:421 [B200] Detected Device: B210
DDEVDRV INFO b200_impl.cpp:468 [B200] Operating over USB 3.
DDEVDRV INFO b200_impl.cpp:619 [B200] Initialize CODEC control...
DDEVDRV INFO b200_impl.cpp:688 [B200] Initialize Radio control...
DDEVDRV INFO b200_impl.cpp:1099 [B200] Performing register loopback test...
DDEVDRV INFO b200_impl.cpp:1108 [B200] Register loopback test passed
DDEVDRV INFO b200_impl.cpp:1099 [B200] Performing register loopback test...
DDEVDRV INFO b200_impl.cpp:1108 [B200] Register loopback test passed
DDEVDRV INFO b200_impl.cpp:814 [B200] Setting master clock rate selection to 'automatic'.
DDEVDRV INFO b200_impl.cpp:1149 [B200] Asking for clock rate 16.000000 MHz...
DDEVDRV INFO b200_impl.cpp:1162 [B200] Actually got clock rate 16.000000 MHz.
DMAIN INFO UHDDevice.cpp:225 Antennas configured successfully
DDEV INFO UHDDevice.cpp:575 Waiting for clock reference lock (max 15s)...
DDEV INFO UHDDevice.cpp:584 Selected clock source is internal
DDEVDRV INFO multi_usrp.cpp:382 [MULTI_USRP] Setting master clock rate selection to 'manual'.
DDEVDRV INFO b200_impl.cpp:1149 [B200] Asking for clock rate 26.000000 MHz...
DDEVDRV INFO b200_impl.cpp:1162 [B200] Actually got clock rate 26.000000 MHz.
DDEV INFO UHDDevice.cpp:288 Rates configured for B210 4 SPS
DDEV INFO UHDDevice.cpp:248 Supported Tx gain range [0; 89.75]
DDEV INFO UHDDevice.cpp:253 Supported Rx gain range [0; 76]
DDEV INFO UHDDevice.cpp:257 Default setting Tx gain for channel 0 to 44.875
DDEV INFO UHDDevice.cpp:264 Default setting Rx gain for channel 0 to 38
DDEV INFO UHDDevice.cpp:633 Device configuration: Single USRP:
Device: B-Series Device
Mboard 0: B210
RX Channel: 0
RX DSP: 0
RX Dboard: A
RX Subdev: FE-RX2
TX Channel: 0
TX DSP: 0
TX Dboard: A
TX Subdev: FE-TX2
DMAIN NOTICE osmo-trx.cpp:621 -- Transceiver active with 1 channel(s)
DLSTATS NOTICE stats.c:169 Stats timer expire_count=4: We missed 3 timers
DLGLOBAL NOTICE rate_ctr.c:350 Stats timer expire_count=16: We missed 15 timers
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'POWEROFF'
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP POWEROFF 0'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'RFMUTE 1'
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP RFMUTE 0 1'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'RFMUTE 0'
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP RFMUTE 0 0'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'SETFORMAT 2'
DTRXCTRL INFO Transceiver.cpp:1054 [chan=0] BTS requests TRXD version switch: 2
DTRXCTRL INFO Transceiver.cpp:1056 [chan=0] rejecting TRXD version 2 in favor of 1
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP SETFORMAT 1 2'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'SETFORMAT 1'
DTRXCTRL INFO Transceiver.cpp:1054 [chan=0] BTS requests TRXD version switch: 1
DTRXCTRL NOTICE Transceiver.cpp:1060 [chan=0] switching to TRXD version 1
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP SETFORMAT 1 1'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'RXTUNE 904800'
DDEV ERROR UHDDevice.cpp:65 No Tx Power measurements exist for device N2XX 1 SPS on band GSM900, using fallback..
DDEV INFO UHDDevice.cpp:1028 [chan=0] set_freq(9.048e+08, Rx): Tune Result:
Target RF Freq: 904.800000 (MHz)
Actual RF Freq: 904.799999 (MHz)
Target DSP Freq: -0.000001 (MHz)
Actual DSP Freq: -0.000001 (MHz)
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP RXTUNE 0 904800'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'TXTUNE 949800'
DDEV INFO UHDDevice.cpp:1028 [chan=0] set_freq(9.498e+08, Tx): Tune Result:
Target RF Freq: 949.800000 (MHz)
Actual RF Freq: 949.800000 (MHz)
Target DSP Freq: 0.000000 (MHz)
Actual DSP Freq: 0.000000 (MHz)
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP TXTUNE 0 949800'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'SETTSC 7'
DTRXCTRL NOTICE Transceiver.cpp:1033 Changing TSC from 0 to 7
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP SETTSC 0 7'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'NOHANDOVER 0 4'
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP NOHANDOVER 0 0 4'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'NOMTXPOWER'
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP NOMTXPOWER 0 13'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'POWERON'
DMAIN NOTICE Transceiver.cpp:287 Starting the transceiver
DMAIN INFO radioInterface.cpp:187 Starting radio device
DDEV INFO UHDDevice.cpp:730 Starting USRP...
DMAIN INFO Threads.cpp:52 Thread 139641902577344 (task 486804) set name: UHDAsyncEvent
DDEV INFO UHDDevice.cpp:705 Initial timestamp 49667006
DDEV INFO UHDDevice.cpp:747 The current time is 45.8486 seconds
DMAIN INFO radioInterface.cpp:208 Radio started
DMAIN INFO Threads.cpp:52 Thread 139641936148160 (task 486805) set name: TxLower
DMAIN INFO Threads.cpp:52 Thread 139641927755456 (task 486806) set name: RxLower
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP POWERON 0'
DMAIN INFO Threads.cpp:52 Thread 139641919362752 (task 486807) set name: RxUpper0
DMAIN INFO Threads.cpp:52 Thread 139641910970048 (task 486808) set name: TxUpper0
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'SETSLOT 0 4'
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP SETSLOT 0 0 4'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'SETSLOT 1 7'
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP SETSLOT 0 1 7'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'SETSLOT 2 1'
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP SETSLOT 0 2 1'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'SETSLOT 3 1'
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP SETSLOT 0 3 1'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'SETSLOT 4 1'
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP SETSLOT 0 4 1'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'SETSLOT 5 1'
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP SETSLOT 0 5 1'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'SETSLOT 6 3'
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP SETSLOT 0 6 3'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'SETSLOT 7 13'
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP SETSLOT 0 7 13'
LLDTRXCLK NOTICE Transceiver.cpp:1199 Sending CLOCK indications
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'SETPOWER 5'
DDEV INFO UHDDevice.cpp:369 Set TX gain to 84.75dB, ~8.3 dBm (asked for 84.75 dB, ~8.3 dBm)
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP SETPOWER 0 5'
DTRXCTRL INFO Transceiver.cpp:928 [chan=0] command is 'SETPOWER 4'
DDEV INFO UHDDevice.cpp:369 Set TX gain to 85.75dB, ~9.3 dBm (asked for 85.75 dB, ~9.3 dBm)
DTRXCTRL INFO Transceiver.cpp:1082 [chan=0] response is 'RSP SETPOWER 0 4'
DDEV ERROR UHDDevice.cpp:780 No packet received, implementation timed-out
DDEV FATAL UHDDevice.cpp:784 UHD: Receive timed out
DMAIN FATAL radioInterface.cpp:340 Receive error 0
DTRXDUL FATAL Transceiver.cpp:1360 Something went wrong in thread RxLower, requesting stop
DMAIN NOTICE osmo-trx.cpp:588 Shutting down transceiver...
DMAIN NOTICE Transceiver.cpp:345 Stopping the transceiver
DMAIN INFO Transceiver.cpp:358 Stopping the device
terminate called after throwing an instance of 'uhd::assertion_error'
what(): AssertionError: accum_timeout < _timeout
in wait_for_ack
at /usr/src/debug/libuhd/uhd-4.5.0.0/host/lib/usrp/b200/b200_radio_ctrl_core.cpp:227
Aborted (core dumped)
</pre>
<p>Here is a backtrace:</p>
<pre>
(gdb) bt
#0 0x00007f00f1eac83c in ?? () from /usr/lib/libc.so.6
#1 0x00007f00f1e5c668 in raise () from /usr/lib/libc.so.6
#2 0x00007f00f1e44542 in abort () from /usr/lib/libc.so.6
#3 0x00007f00f209ca6f in __gnu_cxx::__verbose_terminate_handler () at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/vterminate.cc:95
#4 0x00007f00f20b011c in __cxxabiv1::__terminate (handler=<optimized out>) at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/eh_terminate.cc:48
#5 0x00007f00f20af0aa in __cxa_call_terminate (ue_header=0x557ffd404190) at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/eh_call.cc:54
#6 0x00007f00f20af82a in __cxxabiv1::__gxx_personality_v0 (version=<optimized out>, actions=6, exception_class=5138137972254386944, ue_header=<optimized out>, context=0x7fffa5796680)
at /usr/src/debug/gcc/gcc/libstdc++-v3/libsupc++/eh_personality.cc:688
#7 0x00007f00f38a452a in _Unwind_RaiseException_Phase2 (exc=exc@entry=0x557ffd404190, context=context@entry=0x7fffa5796680, frames_p=frames_p@entry=0x7fffa5796588) at /usr/src/debug/gcc/gcc/libgcc/unwind.inc:64
#8 0x00007f00f38a502d in _Unwind_Resume (exc=exc@entry=0x557ffd404190) at /usr/src/debug/gcc/gcc/libgcc/unwind.inc:242
#9 0x0000557ffcf1b115 in __gthread_mutex_unlock (__mutex=<optimized out>) at /usr/include/c++/13.2.1/x86_64-pc-linux-gnu/bits/gthr-default.h:779
#10 __gthread_recursive_mutex_unlock (__mutex=<optimized out>) at /usr/include/c++/13.2.1/x86_64-pc-linux-gnu/bits/gthr-default.h:832
#11 std::recursive_mutex::unlock (this=<optimized out>) at /usr/include/c++/13.2.1/mutex:139
#12 Mutex::unlock (this=<optimized out>) at ../../../src/osmo-trx/CommonLibs/Threads.h:62
#13 ScopedLock::~ScopedLock (this=<optimized out>, __in_chrg=<optimized out>) at ../../../src/osmo-trx/CommonLibs/Threads.h:76
#14 Transceiver::stop (this=0x557ffd3e0c50) at ../../../src/osmo-trx/Transceiver52M/Transceiver.cpp:372
#15 0x0000557ffcf3be59 in Transceiver::~Transceiver (this=0x557ffd3e0c50, __in_chrg=<optimized out>) at ../../../src/osmo-trx/Transceiver52M/Transceiver.cpp:158
#16 0x0000557ffcf22bf4 in trx_stop () at ../../../src/osmo-trx/Transceiver52M/osmo-trx.cpp:590
#17 0x0000557ffcf1fb96 in main (argc=<optimized out>, argv=<optimized out>) at ../../../src/osmo-trx/Transceiver52M/osmo-trx.cpp:713
</pre>
<p>Looks like it's crashing during <code>Transceiver::stop()</code>, so the backtrace is not very useful.</p> OsmoMSC - Bug #6217 (Feedback): Bearer Capability mismatch in MT SETUPhttps://projects.osmocom.org/issues/62172023-10-10T13:13:58Zfixeria
<p>While investigating <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: mobile: MT calls not working anymore (Resolved)" href="https://projects.osmocom.org/issues/6216">#6216</a>, I noticed that the Bearer Capability in MT SETUP looks weird and does not match such in the MO SETUP.</p>
<p>[frame 9] MO Setup (from SE K800):</p>
<pre>
Bearer Capability 1 - (MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1)
Element ID: 0x04
Length: 6
Octet 3
0... .... = Extension: Extended
.11. .... = Radio channel requirement: MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .000 = Information transfer capability: Speech (0x0)
Octets 3a - Speech Versions
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0010 = Speech version indication: GSM full rate speech version 2(GSM EFR) (0x2)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0000 = Speech version indication: GSM full rate speech version 1(GSM FR) (0x0)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5)
1... .... = Extension: No Extension
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0001 = Speech version indication: GSM half rate speech version 1(GSM HR) (0x1)
</pre>
<p>[frame 22] MT Setup (from osmo-msc):</p>
<pre>
Bearer Capability 1 - (MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1)
Element ID: 0x04
Length: 5
Octet 3
0... .... = Extension: Extended
.11. .... = Radio channel requirement: MS supports at least full rate speech version 1 and half rate speech version 1. MS has a greater preference for full rate speech version 1 than for half rate speech version 1
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .000 = Information transfer capability: Speech (0x0)
Octets 3a - Speech Versions
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0100 = Speech version indication: GSM full rate speech version 3(FR AMR) (0x4)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0101 = Speech version indication: GSM half rate speech version 3(HR AMR) (0x5)
0... .... = Extension: Extended
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 1011 = Speech version indication: GSM half rate speech version 6(OHR AMR) (0xb)
1... .... = Extension: No Extension
.0.. .... = Coding: octet used for extension of information transfer capability
..00 .... = Spare bit(s): 0
.... 0000 = Speech version indication: GSM full rate speech version 1(GSM FR) (0x0)
</pre>
<p>osmo-msc.git 1792ba92c1f939fb232e25ae1124eda7bb11983f (1.11.1)<br />libosmocore.git 435856be518c9d3531ae5b8cbadac1474d521f3a</p> OsmocomBB - Bug #6216 (Resolved): mobile: MT calls not working anymorehttps://projects.osmocom.org/issues/62162023-10-09T19:59:06Zfixeria
<p>With recent osmocom-bb (22e79a87faaa8137e559908d4f90037603fb377a) mobile originating calls work, but mobile terminated do not.</p>
<p>From what I can see, the mobile fails to send CC messages, likely due to "Message unhandled at this state" errors:</p>
<pre>
DMNCC INFO mnccms.c:114 half rate v3 not supported
DMNCC INFO mnccms.c:127 net suggests unknown speech version 11
DMNCC INFO mnccms.c:104 net suggests full rate v1
DMNCC INFO mnccms.c:439 only supported full rate codec is given, using it
DMNCC INFO mnccms.c:455 Incoming call (from 15843 callref 80000001)
DMNCC INFO mnccms.c:149 support TCH/F only
DCC INFO gsm48_cc.c:894 sending CALL CONFIRMED (proceeding)
DCC DEBUG gsm48_cc.c:237 new state CALL_PRESENT -> MO_TERM_CALL_CONF
DCC INFO gsm48_cc.c:176 Sending 'CALL_CONF' using MMCC_DATA_REQ (callref=80000001, transaction_id=8)
DMM INFO gsm48_mm.c:4424 (ms 1) Received 'MMCC_DATA_REQ' event in state MM connection active
DMM INFO gsm48_mm.c:4430 -> callref 80000001, transaction_id 8
DRR INFO gsm48_rr.c:6899 (ms 1) Message 'RR_DATA_REQ' received in state dedicated (sapi 96)
DRR NOTICE gsm48_rr.c:6925 Message unhandled at this state. <-- (!)
DMNCC INFO mnccms.c:476 Ring!
DCC INFO gsm48_cc.c:925 sending ALERTING
DCC DEBUG gsm48_cc.c:237 new state MO_TERM_CALL_CONF -> CALL_RECEIVED
DCC INFO gsm48_cc.c:176 Sending 'ALERTING' using MMCC_DATA_REQ (callref=80000001, transaction_id=8)
DMM INFO gsm48_mm.c:4424 (ms 1) Received 'MMCC_DATA_REQ' event in state MM connection active
DMM INFO gsm48_mm.c:4430 -> callref 80000001, transaction_id 8
DRR INFO gsm48_rr.c:6899 (ms 1) Message 'RR_DATA_REQ' received in state dedicated (sapi 96)
DRR NOTICE gsm48_rr.c:6925 Message unhandled at this state. <-- (!)
</pre>
<p>Same happens when I try to answer the call:</p>
<pre>
DCC INFO gsm48_cc.c:956 sending CONNECT
DCC INFO gsm48_cc.c:340 starting timer T313 with 30 seconds
DCC DEBUG gsm48_cc.c:237 new state CALL_RECEIVED -> CONNECT_REQUEST
DCC INFO gsm48_cc.c:176 Sending 'CONNECT' using MMCC_DATA_REQ (callref=80000001, transaction_id=8)
DMM INFO gsm48_mm.c:4424 (ms 1) Received 'MMCC_DATA_REQ' event in state MM connection active
DMM INFO gsm48_mm.c:4430 -> callref 80000001, transaction_id 8
DRR INFO gsm48_rr.c:6899 (ms 1) Message 'RR_DATA_REQ' received in state dedicated (sapi 96)
DRR NOTICE gsm48_rr.c:6925 Message unhandled at this state. <-- (!)
</pre>
<p>Please find a PCAP (with GSMTAP logging) attached.</p> OsmocomBB - Bug #6209 (Resolved): modem: no response to ICMP Echo Req (ping to MS) with mssdr-mshttps://projects.osmocom.org/issues/62092023-10-05T18:21:39Zfixeria
<p>I am trying to ping the MS from the BTS side, but seeing lots of errors and almost no Echo Rsp.</p>
<p>trxcon logs errors about GPRS UL BLOCK.req without prior TBF CFG.req:</p>
<pre>
20231005180900657 DSCH NOTICE trxcon(0)[0x5572f10900]: Reset scheduler (sched_trx.c:190)
20231005180900657 DSCH NOTICE trxcon(0)[0x5572f10900]: Delete TDMA timeslot #0 (sched_trx.c:226)
20231005180900657 DSCH NOTICE trxcon(0)[0x5572f10900]: Add a new TDMA timeslot #3 (sched_trx.c:207)
20231005180900657 DSCH NOTICE trxcon(0)[0x5572f10900]: (Re)configure TDMA timeslot #3 as PDCH (sched_trx.c:276)
20231005180900657 DSCH NOTICE trxcon(0)[0x5572f10900]: TS3-PDTCH activating (sched_trx.c:476)
20231005180900657 DSCH NOTICE trxcon(0)[0x5572f10900]: TS3-PTCCH activating (sched_trx.c:476)
20231005180900843 DSCH NOTICE trxcon(0)[0x5572f10900]: Delete TDMA timeslot #3 (sched_trx.c:226)
20231005180900843 DGPRS ERROR trxcon(0)[0x5572f10900]: (PDCH-3) Rx UL BLOCK.req (fn=2003126, len=34), but this PDCH has no configured TBFs (l1gprs.c:643)
20231005180900871 DL1C NOTICE trxcon(0)[0x5572f10900]{PACKET_DATA}: Received reset request (FULL) (l1ctl.c:439)
20231005180900871 DSCH NOTICE trxcon(0)[0x5572f10900]: Reset scheduler and clock counter (sched_trx.c:190)
20231005180900872 DL1C NOTICE trxcon(0)[0x5572f10900]{RESET}: Received FBSB request (GSM900 979, timeout 100 TDMA FNs) (l1ctl.c:380)
20231005180900872 DSCH NOTICE trxcon(0)[0x5572f10900]: Add a new TDMA timeslot #0 (sched_trx.c:207)
20231005180900872 DSCH NOTICE trxcon(0)[0x5572f10900]: (Re)configure TDMA timeslot #0 as BCCH+CCCH+SDCCH/4+SACCH/4 (sched_trx.c:276)
20231005180900872 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-SCH activating (sched_trx.c:476)
20231005180900872 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-BCCH activating (sched_trx.c:476)
20231005180900872 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-RACH activating (sched_trx.c:476)
20231005180900872 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-CCCH activating (sched_trx.c:476)
20231005180900890 DAPP ERROR trxcon(0)[0x5572f10900]{FBSB_SEARCH}: Event TRXCON_EV_RX_DATA_IND not permitted (trxcon_shim.c:93)
20231005180901644 DL1C NOTICE trxcon(0)[0x5572f10900]{BCCH_CCCH}: Received 8-bit RACH request (offset=0, ra=0x78) (l1ctl.c:542)
20231005180901646 DSCHD NOTICE trxcon(0)[0x5572f10900]: TS0-RACH Scheduled 8-bit RACH (TS0: GSM, GMSK) at fn=2003300 (sched_lchan_rach.c:130)
20231005180901834 DL1C NOTICE trxcon(0)[0x5572f10900]{BCCH_CCCH}: Received L1CTL_DM_EST_REQ (tn=4, chan_nr=0xc4, tsc=7, tch_mode=SIGNALLING) (l1ctl.c:630)
20231005180901834 DL1C NOTICE trxcon(0)[0x5572f10900]{BCCH_CCCH}: L1CTL_DM_EST_REQ indicates single ARFCN GSM900 979 (l1ctl.c:572)
20231005180901834 DSCH NOTICE trxcon(0)[0x5572f10900]: Reset scheduler (sched_trx.c:190)
20231005180901834 DSCH NOTICE trxcon(0)[0x5572f10900]: Delete TDMA timeslot #0 (sched_trx.c:226)
20231005180901834 DSCH NOTICE trxcon(0)[0x5572f10900]: Add a new TDMA timeslot #4 (sched_trx.c:207)
20231005180901834 DSCH NOTICE trxcon(0)[0x5572f10900]: (Re)configure TDMA timeslot #4 as PDCH (sched_trx.c:276)
20231005180901834 DSCH NOTICE trxcon(0)[0x5572f10900]: TS4-PDTCH activating (sched_trx.c:476)
20231005180901834 DSCH NOTICE trxcon(0)[0x5572f10900]: TS4-PTCCH activating (sched_trx.c:476)
20231005180902026 DSCH NOTICE trxcon(0)[0x5572f10900]: Delete TDMA timeslot #4 (sched_trx.c:226)
20231005180902026 DGPRS ERROR trxcon(0)[0x5572f10900]: (PDCH-4) Rx UL BLOCK.req (fn=2003382, len=34), but this PDCH has no configured TBFs (l1gprs.c:643)
20231005180902054 DL1C NOTICE trxcon(0)[0x5572f10900]{PACKET_DATA}: Received reset request (FULL) (l1ctl.c:439)
20231005180902054 DSCH NOTICE trxcon(0)[0x5572f10900]: Reset scheduler and clock counter (sched_trx.c:190)
20231005180902055 DL1C NOTICE trxcon(0)[0x5572f10900]{RESET}: Received FBSB request (GSM900 979, timeout 100 TDMA FNs) (l1ctl.c:380)
20231005180902055 DSCH NOTICE trxcon(0)[0x5572f10900]: Add a new TDMA timeslot #0 (sched_trx.c:207)
20231005180902055 DSCH NOTICE trxcon(0)[0x5572f10900]: (Re)configure TDMA timeslot #0 as BCCH+CCCH+SDCCH/4+SACCH/4 (sched_trx.c:276)
20231005180902055 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-SCH activating (sched_trx.c:476)
20231005180902055 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-BCCH activating (sched_trx.c:476)
20231005180902055 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-RACH activating (sched_trx.c:476)
20231005180902055 DSCH NOTICE trxcon(0)[0x5572f10900]: TS0-CCCH activating (sched_trx.c:476)
20231005180902511 DL1D NOTICE trxcon(0)[0x5572f10900]: L1CTL connection error: read() failed (rc=0): Resource temporarily unavailable (l1ctl_server.c:55)
20231005180902511 DL1C NOTICE trxcon(0)[0x5572f10900]: Closing L1CTL connection (l1ctl_server.c:203)
20231005180902511 DSCH NOTICE trxcon(0)[0x5572f10900]: Shutdown scheduler (sched_trx.c:173)
20231005180902511 DSCH NOTICE trxcon(0)[0x5572f10900]: Delete TDMA timeslot #0 (sched_trx.c:226)
<pre>
Please find the PCAPs (MS side + BTS side) attached.</pre> OsmocomBB - Bug #6208 (Resolved): modem: "UL_TBF[0x55a5d78de0]{ASSIGN}: Event RX_UL_ACK_NACK not ...https://projects.osmocom.org/issues/62082023-10-05T17:40:52Zfixeria
<p>I am observing this error while testing on the mssdr-ms host:</p>
<pre>
20231005173418051 DLLC DEBUG llc.c:145 modem_llc_prim_down_cb(): Rx GRR-UNITDATA.request ll=[01 c0 09 08 16 08 09 10 10 00 00 00 10 10 2e d7 b8 ]
20231005173418051 DRLCMAC INFO rlcmac_prim.c:522 Rx from upper layers: GRR-UNITDATA.request
20231005173418092 DRLCMAC INFO fsm.c:456 UL_TBF[0x55a5d72f00]{NEW}: Allocated
20231005173418092 DRLCMAC INFO fsm.c:456 UL_TBF_ASS[0x55a5d725d0]{IDLE}: Allocated
20231005173418092 DRLCMAC INFO tbf_ul_ass_fsm.c:711 UL_TBF_ASS[0x55a5d725d0]{IDLE}: Received Event START_FROM_DL_TBF
20231005173418092 DRLCMAC INFO tbf_ul_ass_fsm.c:301 UL_TBF[0x55a5d72f00]{NEW}: Received Event UL_ASS_START
20231005173418092 DRLCMAC INFO tbf_ul_fsm.c:148 UL_TBF[0x55a5d72f00]{NEW}: state_chg to ASSIGN
20231005173418092 DRLCMAC INFO tbf_ul_ass_fsm.c:303 UL_TBF_ASS[0x55a5d725d0]{IDLE}: state_chg to WAIT_PKT_UL_ASS
20231005173418188 DRLCMAC INFO rlcmac.c:793 TS=3 FN=1551883 Rx Pkt UL ACK/NACK
20231005173418189 DRLCMAC INFO tbf_ul.c:317 UL_TBF[0x55a5d72f00]{ASSIGN}: Received Event RX_UL_ACK_NACK
20231005173418189 DRLCMAC ERROR tbf_ul.c:317 UL_TBF[0x55a5d72f00]{ASSIGN}: Event RX_UL_ACK_NACK not permitted
20231005173418189 DRLCMAC INFO tbf_ul.c:273 TBF(UL:NR-2:TLLI-91223344) Tx CS update: CS-1 -> CS-2
20231005173418230 DRLCMAC INFO rlcmac.c:793 TS=3 FN=1551892 Rx Pkt DL Dummy Ctrl Block
20231005173418231 DRLCMAC INFO fsm.c:568 UL_TBF_ASS[0x55a5d725d0]{WAIT_PKT_UL_ASS}: Deallocated
20231005173418231 DRLCMAC INFO tbf_ul_fsm.c:74 UL_TBF[0x55a5d72f00]{ASSIGN}: Send L1CTL-CFG_UL_TBF.req ul_tbf_nr=2 (release)
20231005173418231 DRLCMAC INFO fsm.c:568 UL_TBF[0x55a5d72f00]{ASSIGN}: Deallocated
</pre>
<p>Please find the PCAPs (BTS side + MS side) attached.</p> OsmocomBB - Bug #6206 (Resolved): modem: "UL_TBF_ASS[0x5570b55bf0]{IDLE}: Event CREATE_RLCMAC_MSG...https://projects.osmocom.org/issues/62062023-10-04T21:17:45Zfixeria
<p>Somehow I am unable to attach to the network anymore, most likely due to the following error:</p>
<pre>
20231004210952228 DGMM INFO gmm_prim.c:809 Rx from lower layers: LL-UNITDATA.indication
20231004210952228 DGMM INFO gmm.c:1248 GMME(IMSI-001010000000101:PTMSI-11223344:TLLI-91223344) Rx GMM IDENTITY REQUEST mi_type=IMEI force_stdby=0
20231004210952228 DGMM INFO gmm.c:571 GMME(IMSI-001010000000101:PTMSI-11223344:TLLI-91223344) Tx GMM IDENTITY RESPONSE
20231004210952228 DLLC INFO llc_prim.c:157 Rx from upper layers: LL-UNITDATA.request
20231004210952229 DLLC DEBUG llc.c:145 modem_llc_prim_down_cb(): Rx GRR-UNITDATA.request ll=[01 c0 05 08 16 08 0a 00 00 00 00 00 21 43 ba 61 ac ]
20231004210952229 DRLCMAC INFO rlcmac_prim.c:522 Rx from upper layers: GRR-UNITDATA.request
20231004210952270 DRLCMAC INFO fsm.c:456 UL_TBF[0x5570b55ac0]{NEW}: Allocated
20231004210952270 DRLCMAC INFO fsm.c:456 UL_TBF_ASS[0x5570b55bf0]{IDLE}: Allocated
20231004210952270 DRLCMAC INFO tbf_ul_ass_fsm.c:709 UL_TBF_ASS[0x5570b55bf0]{IDLE}: Received Event START_FROM_DL_TBF
20231004210952270 DRLCMAC INFO tbf_ul_ass_fsm.c:301 UL_TBF[0x5570b55ac0]{NEW}: Received Event UL_ASS_START
20231004210952270 DRLCMAC INFO tbf_ul_fsm.c:148 UL_TBF[0x5570b55ac0]{NEW}: state_chg to ASSIGN
20231004210952270 DRLCMAC INFO tbf_ul_ass_fsm.c:303 UL_TBF_ASS[0x5570b55bf0]{IDLE}: state_chg to WAIT_PKT_UL_ASS
20231004210952370 DRLCMAC INFO rlcmac.c:793 TS=3 FN=1928173 Rx Pkt UL ASS
20231004210952370 DRLCMAC INFO tbf_ul.c:343 UL_TBF_ASS[0x5570b55bf0]{WAIT_PKT_UL_ASS}: Received Event RX_PKT_UL_ASS
20231004210952370 DRLCMAC INFO tbf_ul_ass_fsm.c:426 UL_TBF_ASS[0x5570b55bf0]{WAIT_PKT_UL_ASS}: state_chg to COMPLETED
20231004210952370 DRLCMAC INFO tbf_ul_ass_fsm.c:515 UL_TBF[0x5570b55ac0]{ASSIGN}: Received Event UL_ASS_COMPL
20231004210952370 DRLCMAC INFO tbf_ul.c:130 TBF(UL:NR-1:TLLI-91223344) Send L1CTL-CFG_UL_TBF.req ul_tbf_nr=1 ul_slotmask=0x08 tbf_starting_time(present=0 fn=0)
20231004210952371 DRLCMAC INFO tbf_ul_fsm.c:162 UL_TBF[0x5570b55ac0]{ASSIGN}: state_chg to FLOW
20231004210952371 DRLCMAC INFO tbf_ul_ass_fsm.c:517 UL_TBF_ASS[0x5570b55bf0]{COMPLETED}: state_chg to IDLE
20231004210952389 DRLCMAC INFO rlcmac.c:793 TS=3 FN=1928177 Rx Pkt DL Dummy Ctrl Block
20231004210952408 DRLCMAC INFO rlcmac.c:793 TS=3 FN=1928181 Rx Pkt DL Dummy Ctrl Block
20231004210952408 DRLCMAC INFO tbf_ul_ass_fsm.c:798 UL_TBF_ASS[0x5570b55bf0]{IDLE}: Received Event CREATE_RLCMAC_MSG
20231004210952408 DRLCMAC ERROR tbf_ul_ass_fsm.c:798 UL_TBF_ASS[0x5570b55bf0]{IDLE}: Event CREATE_RLCMAC_MSG not permitted
</pre>
<p>AFAICS, the PCU allocates us an Uplink TBF and we're trying to ACK it, but failing to do so (<code>CREATE_RLCMAC_MSG not permitted</code>).</p>
<p>osmocom-bb.git 615a88f69b52e786abab2001cb442329439711dc<br />libosmo-gprs.git 5162449b71c4285e6c032fb0df39e8c1ba86835d</p>
<p>100% (5/5 times) reproduceable on the mssdr-ms host.</p>
<p>It should be noted that I have disabled osmo-pcu's power saving mode by hacking the code (needed for debugging <a class="issue tracker-1 status-1 priority-3 priority-high3" title="Bug: osmo-trx-ms: lots of @Received bad frame (rc=-1, ber=444/444)@ (New)" href="https://projects.osmocom.org/issues/6200">#6200</a>).</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> OsmoSGSN - Bug #6197 (Feedback): "Cannot handle SM for unknown MM CTX"https://projects.osmocom.org/issues/61972023-09-28T14:32:29Zfixeria
<p>I am observing relatively long PDP Context activation with Sony Ericsson K800i and recent osmo-sgsn:</p>
<p>osmo-sgsn 1.11.0<br />osmo-pcu 1.3.1.1-c1b0</p>
<p>I don't remember if this was the case before, most likely not.</p>
<p>As can be seen from the attached PCAP, the MS orders a PDP Context activation right after completing the Attach (frame 259):</p>
<pre>
130 16.160906108 127.0.0.1 → 127.0.0.1 GPRS-LLC 107 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Attach Request
156 16.161190149 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Identity Request
157 16.797408334 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 1(DTAP) (GMM) Identity Response
173 16.797533278 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 1(DTAP) (GMM) Identity Request
181 17.200282825 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 2(DTAP) (GMM) Identity Response
226 17.225222456 127.0.0.1 → 127.0.0.1 GPRS-LLC 113 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 2(DTAP) (GMM) Attach Accept
239 17.697504097 127.0.0.1 → 127.0.0.1 GPRS-LLC 77 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 3(DTAP) (GMM) Attach Complete
259 17.739056217 127.0.0.1 → 127.0.0.1 GPRS-LLC 136 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 4(DTAP) (SM) Activate PDP Context Request <-- (!)
274 17.739270297 127.0.0.1 → 127.0.0.1 GPRS-LLC 76 SAPI: LLGMM, U, XID
275 17.739280476 127.0.0.1 → 127.0.0.1 GPRS-LLC 75 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Detach Request <-- (!)
</pre>
<p>The SGSN is responding with GMM Detach Request (frame 275), here is the related logging:</p>
<pre>
259 17.739056217 127.0.0.1 → 127.0.0.1 GPRS-LLC 136 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 4(DTAP) (SM) Activate PDP Context Request
260 17.739109847 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Rx NS-UNITDATA
261 17.739128332 127.0.0.1 → 127.0.5.1 GSMTAP 263 GPRS-NS2-VC(UDP-NSE00101-NSVC00101-0_0_0_0:23000-127_0_0_1:23023)[0x55e69ba253d0]{UNBLOCKED}: Received Event RX-UNITDATA
262 17.739139873 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Rx NS-UNITDATA
263 17.739148439 127.0.0.1 → 127.0.5.1 GSMTAP 183 BSSGP TLLI=0x85c79efb Rx UPLINK-UNITDATA
264 17.739181411 127.0.0.1 → 127.0.5.1 GSMTAP 236 LLME(ffffffff/85c79efb){UNASSIGNED} LLC RX: unknown TLLI 0x85c79efb, creating LLME on the fly
265 17.739188394 127.0.0.1 → 127.0.5.1 GSMTAP 193 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x3ef88c
266 17.739193033 127.0.0.1 → 127.0.5.1 GSMTAP 149 CMD=UI
267 17.739196720 127.0.0.1 → 127.0.5.1 GSMTAP 147 DATA
268 17.739200627 127.0.0.1 → 127.0.5.1 GSMTAP 143
269 17.739212048 127.0.0.1 → 127.0.5.1 GSMTAP 214 LLME(ffffffff/85c79efb){UNASSIGNED} Cannot handle SM for unknown MM CTX
270 17.739224792 127.0.0.1 → 127.0.5.1 GSMTAP 198 LLME(ffffffff/85c79efb){UNASSIGNED} LLGM Reset (SAPI=1)
271 17.739243207 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Tx NS-UNITDATA
272 17.739252294 127.0.0.1 → 127.0.5.1 GSMTAP 215 <- GMM DETACH REQ (type: re-attach required, cause: Implicitly detached)
273 17.739257293 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Tx NS-UNITDATA
274 17.739270297 127.0.0.1 → 127.0.0.1 GPRS-LLC 76 SAPI: LLGMM, U, XID
275 17.739280476 127.0.0.1 → 127.0.0.1 GPRS-LLC 75 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Detach Request
</pre>
<p>The MS repeats the request again (frame 517) 30 seconds after the first attempt, and finally gets a PDP Context activated.<br />The key difference between frames 259 (first attempt) and 517 (second attempt) is TLLI indicated in the BSSGP header.</p>