Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-20T14:24:47ZOpen Source Mobile Communications
Redmine Cellular Network Infrastructure - Bug #6411 (New): ttcn3: execute testsuites with a more realisti...https://osmocom.org/issues/64112024-03-20T14:24:47Zfixeria
<p>This idea by <a class="user active" href="https://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://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://osmocom.org/issues/6375#note-14">#6375#note-14</a>. Let's continue discussing this here.</p> Cellular Network Infrastructure - Bug #6352 (Stalled): ttcn3-bts-test[-latest] is broken since Fe...https://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://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> Cellular Network Infrastructure - Bug #6215 (New): Rebase open5gs pcrf_simple patches and submit ...https://osmocom.org/issues/62152023-10-09T10:31:09Zosmith
<p>Rebase the patches from this branch, that make mongodb optional and submit them upstream:<br /><a class="external" href="https://gitea.sysmocom.de/sysmocom/open5gs/src/branch/pcrf_simple">https://gitea.sysmocom.de/sysmocom/open5gs/src/branch/pcrf_simple</a></p> Cellular Network Infrastructure - Bug #6198 (In Progress): Patch releases for September 2023 Osmo...https://osmocom.org/issues/61982023-09-29T09:36:43Zosmith
<a name="Patches-to-include"></a>
<h3 >Patches to include<a href="#Patches-to-include" class="wiki-anchor">¶</a></h3>
osmo-bts:
<ul>
<li><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/34446">https://gerrit.osmocom.org/c/osmo-bts/+/34446</a></li>
<li><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/34540">https://gerrit.osmocom.org/c/osmo-bts/+/34540</a></li>
<li>ASCI related fixes:
<ul>
<li><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/34423">https://gerrit.osmocom.org/c/osmo-bts/+/34423</a></li>
<li><a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/34519">https://gerrit.osmocom.org/c/osmo-bts/+/34519</a></li>
</ul>
</li>
<li>Jolly is investigating lost bursts, we might need to bump the scheduler priority in the systemd service (<a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: Sporadic dropped bursts by DSP (Resolved)" href="https://osmocom.org/issues/6199">#6199</a>)
<ul>
<li>-> <a class="external" href="https://gerrit.osmocom.org/c/osmo-bts/+/34581">https://gerrit.osmocom.org/c/osmo-bts/+/34581</a></li>
</ul></li>
</ul>
osmo-pcu:
<ul>
<li><a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/34541">https://gerrit.osmocom.org/c/osmo-pcu/+/34541</a></li>
<li><a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/34690">https://gerrit.osmocom.org/c/osmo-pcu/+/34690</a></li>
<li>Fix for <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: osmo-pcu from OBS latest feeds transmits Dummy blocks a few more FNs after last TBF in TS was freed (Resolved)" href="https://osmocom.org/issues/6191">#6191</a> (still in review)
<ul>
<li><del><a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/34575">https://gerrit.osmocom.org/c/osmo-pcu/+/34575</a></del></li>
<li><del><a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/34647">https://gerrit.osmocom.org/c/osmo-pcu/+/34647</a></del></li>
<li><a class="external" href="https://gerrit.osmocom.org/c/osmo-pcu/+/35151">https://gerrit.osmocom.org/c/osmo-pcu/+/35151</a></li>
<li>(there might be more related patches that need backporting? or should we just tag a new version from current master?)</li>
</ul></li>
</ul> Cellular Network Infrastructure - Bug #6188 (New): Osmocom manuals have "draft" in debian package...https://osmocom.org/issues/61882023-09-21T16:37:08Zosmith
<p>The "draft" watermark on the first page is currently only getting removed when uploading the manuals here, for the released versions (not master):<br /><a class="external" href="https://ftp.osmocom.org/docs/">https://ftp.osmocom.org/docs/</a></p>
<p>However the debian packages still have the "draft" watermark in osmocom:latest.</p> Cellular Network Infrastructure - Bug #6122 (New): remove big endian supporthttps://osmocom.org/issues/61222023-07-31T09:46:32Zosmith
<p>Follow-up to <a class="external" href="https://lists.osmocom.org/hyperkitty/list/openbsc@lists.osmocom.org/thread/ORBO2FWVVPCHTAXSPZTQLSSM4YB76ITB/">https://lists.osmocom.org/hyperkitty/list/openbsc@lists.osmocom.org/thread/ORBO2FWVVPCHTAXSPZTQLSSM4YB76ITB/</a></p> Cellular Network Infrastructure - Bug #5985 (New): tests: not all Osmocom projects have @osmoappd...https://osmocom.org/issues/59852023-03-29T20:09:42Zfixeria
<p>This is a manifest file, which is used by both <code>osmotestvty.py</code> and <code>osmotestconfig.py</code> for running VTY and config tests.</p>
<p>AFAICS, only the following files have this manifest (my local repos, might be incomplete):</p>
<pre>
fixeria@DELL:~/osmo-dev/src$ find . -name osmoappdesc.py
./libosmocore/tests/gb/osmoappdesc.py
./osmo-sgsn/osmoappdesc.py
./libosmo-sccp/osmoappdesc.py
./osmo-bsc/osmoappdesc.py
./osmo-pcu/osmoappdesc.py
./osmo-smlc/osmoappdesc.py
./osmo-mgw/osmoappdesc.py
./osmo-msc/osmoappdesc.py
./osmo-pcap/osmoappdesc.py
./osmo-sip-connector/osmoappdesc.py
</pre>
<p>I am adding checkboxes for projects missing this file. Maybe something for @arehbein to work on?</p> Cellular Network Infrastructure - Bug #5887 (New): coverity: build everything in docker container...https://osmocom.org/issues/58872023-02-01T10:25:23Zosmith
<p>Currently the coverity scripts are not automatically tested before merging, and when they fail it is quite some effort to reproduce the errors as one has to manually install all dependencies (and missing ones only show up half-way through the build when something fails). Also libusrp requires sdcc 3, while e.g. on this system I have sdcc 4 installed.</p> Cellular Network Infrastructure - Bug #5819 (New): Gerrit/gitiles: Parent links don't workhttps://osmocom.org/issues/58192022-12-08T13:28:35Zarehbein
<p>When clicking the parent link in a Gitiles commit view, I get an error message</p>
<pre><code>Secure Connection Failed<br />An error occurred during a connection to gerrit.osmocom.org:80. SSL received a record that exceeded the maximum permissible length.<br />Error code: SSL_ERROR_RX_RECORD_TOO_LONG</code></pre>
<p>I have encountered this before and now again, for example here<br /><a class="external" href="https://gerrit.osmocom.org/plugins/gitiles/osmo-upf/+/2430533206004a8d9c29dc837cd08efe0d264dfb">https://gerrit.osmocom.org/plugins/gitiles/osmo-upf/+/2430533206004a8d9c29dc837cd08efe0d264dfb</a></p> Cellular Network Infrastructure - Bug #5809 (Feedback): applications disrespect potentially VTY-c...https://osmocom.org/issues/58092022-12-05T18:25:49Zlaforge
<p>Originally we had the <code>telnet_init()</code> function, which later on was replaced by <code>telnet_init_dynif()</code> - both requiring the application to know the TCP port (and possibly local address)</p>
<p>Later we added VTY commands for this, and there is <code>telnet_init_default()</code> which uses <code>vty_get_bind{port,addr}()</code> to make sur the VTY-configured IP/port are used.</p>
<p>The problem is that most if not all applications still use <code>telnet_init_dynif()</code> to which they pass the "normal" port like <code>OSMO_VTY_PORT_HNODEB</code>.</p>
<p>This means the user may configure a different port in the VTY, but that port won't actually be used.</p>
<p>All the osmo-* projects need to be converted to <code>telnet_init_default()</code>.</p>
<p>We should also [marc ase] deprecate the old <code>telnet_init()</code> and <code>telnet_init_dynif()</code> functions for exactly that reason.</p> Cellular Network Infrastructure - Bug #5764 (New): GCC does not check format strings in LOGPFSM m...https://osmocom.org/issues/57642022-11-11T06:30:22Zfixeria
<p>Recently I submitted a patch with an error in one of the LOGPFSM statements ('%s' instead of '%d' for printing an uint16_t):</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/30054/1">https://gerrit.osmocom.org/c/osmocom-bb/+/30054/1</a><br /><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/30054/1/src/host/trxcon/src/trxcon_fsm.c#229">https://gerrit.osmocom.org/c/osmocom-bb/+/30054/1/src/host/trxcon/src/trxcon_fsm.c#229</a></p>
<p>Surprisingly, gcc does not emit any warnings and compiles obviously wrong code just fine. This is not specific to <code>osmocom-bb.git</code>, I was able to reproduce this problem in other Osmocom repositories, except <code>libosmocore.git</code> where it magically does emit <code>-Wformat</code> warnings as expected. This is most likely a bug in gcc, because clang behaves as expected.</p>
<p>I also tried to narrow down the problem to a specific macro:</p>
<pre><code class="c syntaxhl"><span class="cp">#define FMT "Test %s\n"
#define ARG 1337, "extra", -1
</span>
<span class="cm">/* GCC does emit -Wformat / -Wformat-extra-args warnings as expected */</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DAPP</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="n">FMT</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
<span class="cm">/* GCC does *not* emit any warnings, clang does */</span>
<span class="n">LOGPFSML</span><span class="p">(</span><span class="n">fi</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="n">FMT</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
<span class="n">LOGPFSMLSRC</span><span class="p">(</span><span class="n">fi</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="n">__FILE__</span><span class="p">,</span> <span class="n">__LINE__</span><span class="p">,</span> <span class="n">FMT</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
<span class="n">LOGPFSMSLSRC</span><span class="p">(</span><span class="n">fi</span><span class="p">,</span> <span class="p">(</span><span class="n">fi</span><span class="p">)</span> <span class="o">?</span> <span class="p">(</span><span class="n">fi</span><span class="p">)</span><span class="o">-></span><span class="n">fsm</span><span class="o">-></span><span class="n">log_subsys</span> <span class="o">:</span> <span class="n">DLGLOBAL</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span>
<span class="n">__FILE__</span><span class="p">,</span> <span class="n">__LINE__</span><span class="p">,</span> <span class="n">FMT</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
<span class="cm">/* GCC does emit -Wformat / -Wformat-extra-args warnings as expected */</span>
<span class="n">LOGPSRC</span><span class="p">((</span><span class="n">fi</span><span class="p">)</span><span class="o">-></span><span class="n">fsm</span><span class="o">-></span><span class="n">log_subsys</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span>
<span class="n">__FILE__</span><span class="p">,</span> <span class="n">__LINE__</span><span class="p">,</span>
<span class="s">"%s{%s}: "</span> <span class="n">FMT</span><span class="p">,</span>
<span class="n">osmo_fsm_inst_name</span><span class="p">(</span><span class="n">fi</span><span class="p">),</span>
<span class="p">(</span><span class="n">fi</span><span class="p">)</span> <span class="o">?</span> <span class="n">osmo_fsm_state_name</span><span class="p">((</span><span class="n">fi</span><span class="p">)</span><span class="o">-></span><span class="n">fsm</span><span class="p">,</span> <span class="p">(</span><span class="n">fi</span><span class="p">)</span><span class="o">-></span><span class="n">state</span><span class="p">)</span> <span class="o">:</span> <span class="s">"fi=NULL"</span><span class="p">,</span> <span class="n">ARG</span><span class="p">);</span>
</code></pre>
<p>Running gcc with <code>-E -P</code> confirms that the preprocessor expands all <code>LOGPFSM</code> statements identical to the last <code>LOGPSRC</code>.</p> Cellular Network Infrastructure - Bug #5750 (New): contrib/jenkins.sh: build with -Wunused-macros...https://osmocom.org/issues/57502022-11-08T20:07:03Zfixeria
<p>According to <code>man cpp</code>:</p>
<pre>
-Wundef
Warn if an undefined identifier is evaluated in an "#if" directive.
Such identifiers are replaced with zero.
-Wunused-macros
Warn about macros defined in the main file that are unused. A macro
is used if it is expanded or tested for existence at least once. The
preprocessor also warns if the macro has not been used at the time it
is redefined or undefined.
Built-in macros, macros defined on the command line, and macros
defined in include files are not warned about.
Note: If a macro is actually used, but only used in skipped
conditional blocks, then the preprocessor reports it as unused. To
avoid the warning in such a case, you might improve the scope of the
macro's definition by, for example, moving it into the first skipped
block. Alternatively, you could provide a dummy use with something
like:
#if defined the_macro_causing_the_warning
#endif
</pre>
<p>I think it would be good to have these options enabled during the build verification.</p>
<p>With this option enabled, I quickly found a copy-paste bug in osmo-bsc:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmo-bsc/+/30058">https://gerrit.osmocom.org/c/osmo-bsc/+/30058</a></p> Cellular Network Infrastructure - Bug #5749 (New): configure.ac: default CFLAGS, LT_INIT adds "-g...https://osmocom.org/issues/57492022-11-08T18:04:34Zfixeria
<p>Today I spent quite some time trying to figure out why am I seeing <code>-g -O2</code> present in <code>CFLAGS</code> by default when building some projects. As it turned out, it's the <code>LT_INIT</code> (called in <code>configure.ac</code>) adding <code>-g -O2</code> to <code>CFLAGS</code> if they're empty. I could not find anything in documentation describing this behavior. The problem is that this behavior is inconsistent across the Osmocom projects: for some you get empty CFLAGS by default, for some you get <code>CFLAGS=-g -O2</code>. Most likely this inconsistency was introduced when we started to specify the <code>-std=gnu11</code> explicitly: in some projects (e.g. libosmocore.git, libosmo-abis.git, osmo-bsc) we set <code>CFLAGS</code> before calling the <code>LT_INIT</code>, in some (osmo-hlr, osmo-iuh, osmo-sgsn) after.</p>
<p>We need to decide on whether we want to have empty <code>CFLAGS</code> or <code>CFLAGS=-g -O2</code> set by default. Personally I prefer the former approach, because explicit is better then implicit. <a class="user active" href="https://osmocom.org/users/52">Hoernchen</a> also prefers the former and does not want "magical flags out of nowhere". Either way, the default behavior should be consistent across all Osmocom projects. <a class="user active" href="https://osmocom.org/users/7">laforge</a> what do you think?</p> Cellular Network Infrastructure - Bug #5685 (Feedback): Dropping debian 10 (buster)https://osmocom.org/issues/56852022-09-19T13:09:00Zosmith
<p>Debian 10 was EOL in 2022-08. It still has LTS support (<a class="external" href="https://wiki.debian.org/DebianReleases">https://wiki.debian.org/DebianReleases</a>).</p>
<a class="user active" href="https://osmocom.org/users/7">laforge</a>:
<ul>
<li>Do we want to remove it form OBS now? (after migrating all docker containers to debian 11)</li>
<li>In general, when do we want to stop supporting old Debian releases?</li>
</ul>
<p>Currently it is still in use by various docker containers:<br /><pre>
$ git grep debian-buster
debian-buster-build/Makefile:DISTRO=debian-buster
debian-buster-jenkins/Makefile:DISTRO=debian-buster
debian-buster-simtrace2/Dockerfile:FROM $USER/debian-buster-build
fpga-build/Dockerfile:FROM $USER/debian-buster-build
jenkins-common.sh: debian-buster-*) echo "debian-buster" ;;
jenkins-common.sh: debian-buster-*) echo "debian:buster" ;;
nplab-m3ua-test/jenkins.sh: "debian-buster-build" \
nplab-sua-test/jenkins.sh: "debian-buster-build" \
osmo-gsm-tester/Dockerfile:FROM $USER/debian-buster-jenkins
osmo-gsm-tester/jenkins.sh: "debian-buster-jenkins" \
sigtran-tests/Dockerfile:FROM $USER/debian-buster-build
</pre></p> Altair LTE Modems - Feature #4638 (New): Mikrotik R11e-4G mtd dumphttps://osmocom.org/issues/46382020-07-02T06:43:32Zas
<p>Hello,</p>
<p>It'd be great if you could post mtd dump under wiki, I'd love to inspect that modem in software manner.</p> Cellular Modem Information - Feature #4525 (New): MTKhttps://osmocom.org/issues/45252020-05-03T15:57:25ZRussianBird
<p><a class="external" href="https://git.rip/exconfidential/mtk/docs">https://git.rip/exconfidential/mtk/docs</a></p> BBS-Revival - Feature #4341 (New): setup for telnet access to legacy BBS software which doesn't h...https://osmocom.org/issues/43412020-01-01T14:06:50Zlaforge
There are plenty of legacy BBS software packages out there, made for DOS. They either directly interface the serial ports (COM1..COM4) or they use a FOSSIL driver to do so. Attaching those to<br />real serial ports with modems is possible, but not particularly attractive:
<ul>
<li>it requires one physical modem per node (and likely one USB/serial adapter)</li>
<li>it cannot provide direct IP (telnet/ssh) access</li>
<li>it cannot be combined with using a RAS server like our <a class="wiki-page" href="https://osmocom.org/projects/retro-bbs/wiki/Livingston_Portmaster_3">Livingston_Portmaster_3</a></li>
</ul>
<p>For some other OSs (Windows, OS/2) there are solutions like NetFoss to work around this. I've also found references to a DOS based telnet FOSS driver baesed on Ethernet cards with packet driver. No proper solution for a Linux based setup with qemu-kvm seems to be out there.</p>
Using the built-in serial port telnet server of qemu is one idea, but
<ul>
<li>it would mean each line (COM port) has a different telnet port</li>
<li>there doesn't seem to be any escaping for binary (0xFF, ...)</li>
</ul>
<p>One could build something based on <a class="external" href="https://github.com/freemed/tty0tty">https://github.com/freemed/tty0tty</a> (a virtual nullmodem device), so one side could be passed though qemu, and the other end could be served by some kind of custom telnet daemon. tty0tty has the advantage of at least handling the modem status/control lines properly - very uch opposed to any pty based approach.</p>
<p>The cleanest solution would probably be to implement something based on <a href="https://www.ietf.org/rfc/rfc2217.txt" class="external">RFC2217</a> (Telnet Com Port Control Option). This has the advantage that it fully supports modem control lines, and that it can also be used to interface any actual serial/terminal server hardware, if ever needed.</p>
<p>So either qemu would have to run a RFC2217 telnet server which would then accept e.g. up to 4 or 8 connections, and dispatching any of those to a virtual 8250 serial UART, or it would have to run one RFC2217 telnet client for each virtual 8250 UART.</p>
<p>In case of a <em>telnet server</em>, that server then would also have to implement something like AT command emulation, so the DOS applications think they're talking to a modem with RING/ATA/CONNECT/...</p>
In case of a qemu built-in <em>telnet client</em>, we would provide some kind of external program that provides two telnet servers:
<ol>
<li>one for the qemu side to connect to, and where we emulate a basic AT command interface</li>
<li>one for the actual users to connect to, either directly via IP or indirectly from dialup via the Portmaster</li>
</ol>
<p>I think the approach with qemu built-in telnet client with the external server makes most sense, as it offers greatest flexibility in terms of supported configurations. It also keeps things like AT command emulation out of qemu.</p>
<p><code>tnt</code> has implemented the qemu side in <a class="external" href="https://patchwork.kernel.org/patch/11149529/">https://patchwork.kernel.org/patch/11149529/</a> - but that patch unfortunately is still not yet merged, presumably due to a lack of tests and some other feedback raised by qemu developers. But with a custom qemu build, we could already use it here...</p> BBS-Revival - Feature #4242 (New): offer CCC event schedule (Fahrplan) as gopher servicehttps://osmocom.org/issues/42422019-10-28T09:22:39Zlaforge
<p>The CCC event schedules are typically availble in a machine-readable (XML) format, see <a class="external" href="https://fahrplan.events.ccc.de/congress/2018/Fahrplan/schedule.xml">https://fahrplan.events.ccc.de/congress/2018/Fahrplan/schedule.xml</a> and it would be great to have a script to parse that XML and render gopher menus from it.</p>
<p>This in turn would be a nice demonstrator for gopher with up-to-date content.</p> Cellular Network Infrastructure - Bug #4131 (Stalled): osmo-gsm-manuals: Use leveloffset attribut...https://osmocom.org/issues/41312019-07-26T13:04:49Zpespin
<p>Right now, all documents under osmo-gsm-manuals.git/commons/ start with title level 1 (==). However, if one wishes to add a document with level 2 (===) so it can also be included in other repository document, it will make osmo-gsm-manuals.git "make check" fail due to osmo-gsm-manuals/tests/Makefile.am:22:<br /><pre>
echo "include::$${chapter}[]" >> $@; \
</pre></p>
<p>Which includes stuff under a test document with level 0 (=). If a document with level different than 1 (==) is added, then it will fail on some versions (like jenkins):<br /><pre>
"asciidoc: WARNING: mgcp_extension_osmux.adoc: line 2: section title out of sequence: expected level 1, got level 2"
</pre></p>
<p>See for instance commit osmo-gsm-manuals.git 061cca4d7345bc4f496324d0b4d30bc51e1f8d23, which had to be fixed up later.</p>
<p>The solution here is to use "leveloffset" attribute. To make our life easier in the future, we need to move all documents under common/ to start with level 0 (=), and then use "leveloffset" on all includes in all other repositories using them. This way same document can easily be added on different levels on different documents.</p>
<p>Important! It seems this syntax doesn't work for me:<br /><pre>
include::chapter2.adoc[leveloffset=+1]
</pre></p>
<p>However, this does and it's basically the same:<br /><pre>
:leveloffset: 1
include::chapter1.adoc[]
:leveloffset: 0
</pre></p>
<p>Related information:<br /><a class="external" href="https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/include-directive.adoc">https://github.com/asciidoctor/asciidoctor.org/blob/master/docs/_includes/include-directive.adoc</a><br /><a class="external" href="https://mrhaki.blogspot.com/2016/09/awesome-asciidoctor-change-level-offset.html">https://mrhaki.blogspot.com/2016/09/awesome-asciidoctor-change-level-offset.html</a><br /><a class="external" href="http://asciidoc.org/userguide.txt">http://asciidoc.org/userguide.txt</a></p> Cellular Network Infrastructure - Bug #4108 (New): osmo-ctrl2cgi, osmo-trap2cgi: missing default ...https://osmocom.org/issues/41082019-07-16T12:30:11Zosmith
<p>Default configs for osmo-ctrl2cgi and osmo-trap2cgi do not get installed in the debian packages. Therefore the systemd services don't work out of the box.</p>
<p>Both programs are part of osmo-python-tests.git.</p>
<p>I'm setting this to low priority as I think that the programs are not widely used.</p> Cellular Network Infrastructure - Bug #4069 (New): Implement IPA PING/PONG mechanism everywherehttps://osmocom.org/issues/40692019-06-21T14:44:02Zlaforge
<p>As was seen in <a class="issue tracker-1 status-5 priority-3 priority-high3 closed" title="Bug: Prolonged remaining in state with RSL link gone, OML link open (Closed)" href="https://osmocom.org/issues/4061">#4061</a>, we're not doing a good job in closing connections if they're dead. Let's improve this situation by implementing an IPA PING sender / PONG receiver which closes+reconnects (client) or simply closes (server) the respective connection.</p>
<p>I recently added ipa_keepalive_fsm_start to libosmo-abis. It's used only in osmo-remsim,<br />but should probably be used by virtually any of our programs that implement IPA<br />multiplex, starting from BTS (Abis), BSC (Abis), MSC (SCCPlite, GSUP), HLR (GSUP),<br />all our CTRL interfaces, ... - but anything beyond RSL+OML in BTS+BSC is out of scope for this<br />ticket. I'll add separate tickets about this.</p>
<p>Whether or not that specific FSM is used: The IPA PING/PONG logic should exist everywhere.</p> Cellular Network Infrastructure - Bug #3694 (New): Fix lintian warnings in .deb packageshttps://osmocom.org/issues/36942018-11-14T14:27:44Zmsuraev
<p>There's a nice overview page with links to lintian errors/warnings for all the packages currently in Debian:<br /><a class="external" href="https://qa.debian.org/developer.php?email=Debian-mobcom-maintainers%40lists.alioth.debian.org">https://qa.debian.org/developer.php?email=Debian-mobcom-maintainers%40lists.alioth.debian.org</a><br />This gives a nice overview of what could be improved in our packages. Some of those are rather trivial to fix, others will require more work.</p> Cellular Modem Information - Feature #3658 (New): Create a "osmocom-bb-host-latest" docker containerhttps://osmocom.org/issues/36582018-10-16T14:11:32Zosmith
<p>The ttcn3-bts-test-latest jenkins job should use the "latest" version of everything that is used for the test.<br />But since there is no "latest" tag in the osmocom-bb.git repository, we can't build a osmocom-bb-host-latest docker image.</p>
<p>The current workaround is using osmocom-bb-host-master for ttcn3-bts-test-latest.</p> Cellular Network Infrastructure - Bug #3567 (New): coverity: move the secret token out of $HOME/o...https://osmocom.org/issues/35672018-09-18T15:34:10Zlynxis
<p>When the token has been moved, the jenkins Coverity job is independent from the static path $HOME/osmo-ci.</p> Cellular Network Infrastructure - Bug #3382 (New): Investigate and fix lintian issues listed by D...https://osmocom.org/issues/33822018-07-05T11:37:34Zpespin
<p>This web page lists a list of warnings which we may want to fix: <a class="external" href="https://lintian.debian.org/maintainer/Debian-mobcom-maintainers@lists.alioth.debian.org.html">https://lintian.debian.org/maintainer/Debian-mobcom-maintainers@lists.alioth.debian.org.html</a></p> Cellular Network Infrastructure - Bug #3192 (New): meas_vis: use the lchan identity as primary ke...https://osmocom.org/issues/31922018-04-21T19:21:40Zneelsnhofmeyr@sysmocom.de
<p>While re-adding meas_feed to osmo-bsc.git, I noticed that the meas_vis and meas_web tools appear to use the lchan's IMSI as primary key to visualizing active lchans. They should use the bts,trx,ts,ss number instead.</p>
<p>See also: <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: resurrect meas_feed (Resolved)" href="https://osmocom.org/issues/2968">#2968</a> <a class="issue tracker-2 status-3 priority-1 priority-lowest closed" title="Feature: obtain and store subscriber identity (Resolved)" href="https://osmocom.org/issues/2969">#2969</a></p>
<p>meas_vis is currently still in openbsc.git, it should probably move over to osmo-bsc <a class="issue tracker-2 status-6 priority-2 priority-default closed" title="Feature: move meas_vis and meas_json over to osmo-bsc.git (Rejected)" href="https://osmocom.org/issues/3191">#3191</a>.<br />meas_web is external, but it could make sense to send a pull request.</p> Cellular Network Infrastructure - Bug #3167 (New): Build osmo-*-master docker containers with add...https://osmocom.org/issues/31672018-04-14T12:47:52Zlaforge
<p>In order to catch use-after-free and similar bugs during TTCN-3 test execution, it would be great if we'd modify the <code>docker-playground/osmo-*-master</code> containers to build with asan enabled. We'd of course have to capture the stderr output of the related processes somehow into jenkins (e.g. as artefacts) to reap the benefits from this.</p> Cellular Network Infrastructure - Bug #2839 (New): statistics split betwteen 2G and 3Ghttps://osmocom.org/issues/28392018-01-18T20:05:59Zlaforge
<p>many of our statistics/countrs currnetly don't distinguish between 2G and 3G bearer. This means we cannot know how many 2G vs 3G LU we have received in a given period of time, for example.</p> Cellular Network Infrastructure - Bug #1612 (New): more configuration consistency checkinghttps://osmocom.org/issues/16122016-02-23T16:22:14Zlaforge
<p>Right now it is possible to configure various things that wouldn't work, like an ARFCN that is outside the band of the BTS, or even the TRX.</p>
<p>More consistency checks would make sense, together with reasonable error messages.</p>