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 - Feature #6327 (New): Osmocom-build-tags-against-master job buil...https://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 - Feature #6243 (New): vty cfg: make changing startup defaults of...https://osmocom.org/issues/62432023-11-01T00:56:38Zneelsnhofmeyr@sysmocom.de
<p>Sometimes our recommendation of what the usual/good setting should be for a given vty config item changes.<br />Then we have the problem that we cannot change it without endangering running installations,<br />and/or creating hassle for admins.</p>
<p>So how about a general mechanism in all of our config files in form of a vty command, maybe like this:</p>
<p>osmo-foo.cfg:<br /><pre>
defaults (v0|v1.5|v1.6)
</pre></p>
<p>so a user can decide when to make the cfg upgrade, independently from binary upgrades.</p>
<p>When 'defaults' is not specified, we would have to assume like 'defaults v0'.<br />(A bit more convenient for new users would be to add the newest available 'defaults' setting automatically somehow,<br />but I guess that also breaks the entire feature then, unless someone can think of an elegant way.)</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 - Feature #6069 (In Progress): port hello-stk to ant-based build ...https://osmocom.org/issues/60692023-06-21T12:52:08Zlaforge
<p>It's rather hard to build the old hello-stk using java8 sdk and the sim-tools makefiles etc. on a current distribution today.</p>
<p>Instead, @merlinchlosta came up with a modern, ant-based build using <a href="https://github.com/martinpaljak/ant-javacard/releases/latest/download/ant-javacard.jar" class="external">ant-javacard</a> by Martin Paljak</p>
<p>I've started to migrate our hello-stk.git (with both the HelloSTK and the ImsiChange applet) over to this build system. See my <a href="https://gitea.osmocom.org/sim-card/hello-stk/src/branch/laforge/ant" class="external">laforge/ant branch</a>.</p>
<p>Please take this over by doing some more testing and updating documentation (README, wiki, possibly other places like sysmoUSIM/ISIM user manual, ...). Ideally we'd have the documentation in one place, and other locations just point to it.</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 - Feature #5929 (In Progress): document current (milestones of) n...https://osmocom.org/issues/59292023-02-28T19:37:26Zlaforge
We have been doing a number of NLnet funded projects, and should
<ol>
<li>publish some news item / blog post / release announcement (whatever applicable) on each of them</li>
<li>give credit to NLnet funding received for the respective project.</li>
</ol> Cellular Network Infrastructure - Feature #5908 (New): Cleanup license information throughout the...https://osmocom.org/issues/59082023-02-16T10:48:43Zmsuraev
<p>Right now licensing information is rather fragmented: some files use SPDX, others don't, different license headers in the same project etc.</p>
<p>There's handy tool <a class="external" href="https://reuse.software/">https://reuse.software/</a> which could help remediate this.</p>
<p>Running 'reuse lint' in the repository (installable via 'sudo apt install reuse') will give comprehensive report regarding project licensing information.</p>
<p>Once outstanding issues are fixed, it can be added to commit linter to make sure the compliance is checked automatically.</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 - Feature #5771 (New): series of presentations about the invididu...https://osmocom.org/issues/57712022-11-14T19:25:57Zlaforge
<p>Most of the talks we ever gave on setting up and running the Osmocom CNI are ages old and hence relatively outdated.</p>
<p>Given the number of network elements and the relate complexity, I think we should consider doing a talk on each of them. The talk doesn't have to be of a particular length, so some network elements might have shorter or longer presentations.</p>
<p>Looking at the checklist below, we already have 14 items. Covering this in OsmoDevCall is not an option, it would take too long (14 months if no other topic would be covered in between). So it is going to be on a separate schedule.</p>
<p>I would consider each presentation should then be prominently linked from the redmine project page of each network element, next to the user manual.</p>
<p>We may of course still be publishing those via the OsmoDevCall "event" on media.ccc.de, so all videos are in one location.</p>
<p>I think every presentation should start with a quick picture at the overal diagram of netwokr elements, describe the surrounding elements and their interfaces to then look in detail at the specific element that ist he subject of the talk.</p>
It should cover
<ul>
<li>basic configuration to get it started / connected</li>
<li>VTY for state introspection ("ar alle connections up?", ...)</li>
<li>looking at logs / protocol traces</li>
<li>practical demo; looking at what happens in pcaps + logs for some basic transaction like LU, SMS, voice call.</li>
</ul> 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 #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> Cellular Network Infrastructure - Feature #5124 (Feedback): network:osmocom:nightly feed with "-O...https://osmocom.org/issues/51242021-04-20T21:00:00Zlaforge
<p>when debugging issues, it's always annoying to run into "... optimized out" in gdb.</p>
<p>It might make sense to have an OBS feed that basically is a copy of 'nightly' but has all binaries built with -O0</p>
<p>Hopefully that's not all that much effort? Can we somehow inject the compiler flag without having to maintain a package-specific patch against debian/rules?</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 - Feature #4107 (Stalled): Start systemd services as non-root userhttps://osmocom.org/issues/41072019-07-15T06:56:35Zosmith
<p><a class="user active" href="https://osmocom.org/users/7">laforge</a> wrote in <a href="https://osmocom.org/issues/3369#note-12" class="external">OS#3369</a>:</p>
<blockquote>
<p>Ideally, as far as possible, we should start them as non-root user<br />(which may require changes to our systemd service files, etc. in the<br />individual git repos - but that is fine!). Starting them as non-root<br />will also means that any writes to unintended directories like '/'will<br />be discovered as they then would make the program start fail.</p>
</blockquote> Cellular Network Infrastructure - Feature #3982 (Feedback): osmo-depcheck.py: set dependency hash...https://osmocom.org/issues/39822019-05-07T13:48:30Zosmith
<p>Right now, osmo-depcheck.py (from osmo-ci.git) always uses the versions of the dependencies that are specified in configure.ac of the Osmocom project that is being tested.</p>
<p><a class="user active" href="https://osmocom.org/users/30187">pespin</a> was just using the script and wanted to check if a project builds against a specific commit of a dependency. He said, it would be nice to have something like:</p>
<pre>
./osmo-depcheck.py -b osmo-msc:7231edb7321a238851387479df0ee16d6c936de0[libosmocore:aa98c481fa7888e2bcd9d5c9ae1993744ee47f33]
</pre>
<p>(so after the project:hash, add [] with a list of dependencies)</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 - Feature #3386 (New): Generate man pages at build time from adoc...https://osmocom.org/issues/33862018-07-06T10:24:03Zpespin
<p>Once we have documentation being build in each project repository separately (see <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Move project specific manuals from osmo-gsm-manuals to each respective git repository (Resolved)" href="https://osmocom.org/issues/3385">#3385</a>), we want to generate man pages for each repository.</p>
<p>The idea here is to have an .adoc file with all the required content to be used in the man pag, and which is already included in the user manual. Then we need to scripts/makefile to transform this .adoc file into man source format and make it be build and installed when --enable-man is passed. Then, install it in the debian packages (which means we in turn need to modify dh_configure or similar to pass the --enable-man flag, and somehow include the common osmo-gsm-manuals.git in there when sending to OBS).</p> Cellular Network Infrastructure - Feature #2011 (New): clean-up / merge IPA (and IPA CCM) code of...https://osmocom.org/issues/20112017-04-15T12:54:09Zlaforge
<p>There are bits and pieces of code supporting different features of the IPA protocol, particularly the CCM part of it distributed over various osmocom projects:</p>
<ul>
<li>libosmocore (src/gsm/ipa.c)</li>
<li>libosmo-abis (src/input/ipa.c, src/input/ipaccess.c)</li>
<li>libosmo-netif (src/ipa.c, src/ipa_unit.c)</li>
<li>openbsc (in osmo-bsc and osmo-bsc_nat (at the very least, but also ipaccess-proxy and of course abisip-find)</li>
<li>osmo-bts (sysmobts_mgr_nl.c)</li>
</ul>
<p>We should sit down and clean this mess up. There should be one parser and one encoder for IPA and CCM messages, which can be used by all the various code bases.</p>