Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-02-05T09:25:36ZOpen Source Mobile Communications
Redmine 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 - 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 - 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 #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 #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 #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 #5045 (New): write libversion "major" on build files au...https://osmocom.org/issues/50452021-02-24T12:41:58Zpespin
<p>As a reminder:<br /><a class="external" href="https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html">https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html</a></p>
<p>LIBVERSION = current:revision:age<br />LIBVERSION_MAJOR = current - age</p>
Right now we usually use the form "{*_}LIBVERSION = 1:2:3" in Makefile.am, and we hardcode the resulting LIBVERSION_MAJOR in lots of files, namely:
<ul>
<li>debian/control</li>
<li>debian/rules</li>
<li>contrib/*.spec.in</li>
</ul>
<p>The idea here would be to generate LIBVERSION_MAJOR automatically as a autconf/automake variable which can be fed into those files automatically, so we don't have to update them every time LIBCERSION_MAJOR changes (and hence potentially avoid breakage during release time).</p>
So, I'd follow these steps for each project:
<ul>
<li>Normalize the LIBVERSION variable to follow a standardized naming, so that we can track it later better on osmo-release.sh, for instance ${LIBNAME}_LIBVERSION (replacing "-" with "_"). Example: LIBOSMO_NETIF_LIBVERSION. Or even better, LIBVERSION_LIBOSMO_NETIF.</li>
<li>Have LIBVERSION variable be generated out of 3 new variables (also following normalized name with LIBNAME), example: <br /><pre>
LIBVERSION_CURRENT_LIBOSMO_NETIF = 3
LIBVERSION_REVISION_LIBOSMO_NETIF = 2
LIBVERSION_AGE_LIBOSMO_NETIF = 1
LIBVERSION_MAJOR_LIBOSMO_NETIF = LIBVERSION_CURRENT_LIBOSMO_NETIF - LIBVERSION_AGE_LIBOSMO_NETIF
</pre></li>
</ul>
<ul>
<li>Use $LIBVERSION_MAJOR_LIBOSMO_NETIF in the files mentioned above</li>
<li>Update osmo-release.sh to follow new naming</li>
</ul>
Considerations:
<ul>
<li>We may need to move debian/control to debian/control.in so we can template it? That means also configure must be run before generating the package, I guess that's expected?</li>
</ul> Cellular Network Infrastructure - Bug #5043 (New): CNI overview diagram lacks osmo-cbc and osmo-smlchttps://osmocom.org/issues/50432021-02-23T17:32:46Zlaforge
The overview diagram at <a class="external" href="https://osmocom.org/projects/cellular-infrastructure/wiki">https://osmocom.org/projects/cellular-infrastructure/wiki</a> needs an update:
<ul>
<li>OsmoCBC (cell broadcast centre) needs to be added to CN, with
<ul>
<li>CBSP interface to OsmoBSC, and </li>
<li>SABP to OsmoHNBGW (mark that grey or dashed as it's work in progress)</li>
</ul>
</li>
<li>OsmoSMLC (serving mobile location centre) needs to be added to RAN, with
<ul>
<li>Lb interface to OsmoBSC (no other interfaces)</li>
</ul>
</li>
<li>OsmoMSC should indicate its SGs interface to an external LTE EPC MME like open5gs</li>
</ul> 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 - Feature #4109 (New): debian-repo-install-test: start a virtual ...https://osmocom.org/issues/41092019-07-16T12:36:01Zosmith
<p>We could extend <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: no automatic testing of Debian/Ubuntu packages (Resolved)" href="https://osmocom.org/issues/3369">#3369</a> (which made debian-repo-install-test start up all systemd services of Osmocom programs) to also start a virtual mobile subscriber (phone) and do a location update.</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 #4091 (New): Osmux: Make sure all handover types work f...https://osmocom.org/issues/40912019-07-05T14:10:17Zpespin
<p>It has never been tried and it could be it doesn't work.</p>
Let's add some TTCN3 tests to make sure we support different scenarios.<br />For instance:
<ul>
<li>intra-bsc handover between 2 BTS while BSC<->MSC is using Osmux</li>
<li>inter-bsc handover between 1 BSC with osmux enabled and 1 BSC with osmux disabled while a call is ongoing. Test both handover directions (A->B, B->A).</li>
<li>inter-msc handover between 2 MSC, one MSC having a BSC with Osmux enabled and another MSC having a BSC with Osmux disabled. Test both handover directions (A->B, B->A).</li>
</ul> 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 - 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 #3477 (New): add a wiki page explaining interconnection...https://osmocom.org/issues/34772018-08-20T09:21:37Zneelsnhofmeyr@sysmocom.de
<p>The <a class="wiki-page" href="https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box">Osmocom Network In The Box</a> wiki page explains running components on the same machine.<br />As soon as this is split up between several boxes, numerous config items become necessary to set bind-addresses and remote addresses.<br />Each user manual should explain this, but it would also be nice to have a common wiki page guiding through this process.</p> Cellular Network Infrastructure - Bug #3417 (New): show asciidoc counters does not show all the c...https://osmocom.org/issues/34172018-07-25T07:01:29Zdaniel
<p>Since show asciidoc counters only iterates through the allocated rate_ctr/stat_item groups it does not necessarily show all the counters that can be available.</p>
<p>For example the sgsn only creates (and reports) bssgp:bss_ctx counters if there is actually a bssgp configured in the sgsn. While you could argue that this is just a misconfiguration the issue remains with counters allocated for each mm or pdp context. As long as no phones are GMM attached the command show asciidoc counters does not know about any statistics for mm or pdp context.</p>
<p>We could add commands to add the rate_ctr_group_desc ans osmo_stat_item_group_desc to another list which keeps track of available counters and traverse that for show asciidoc stats as we don't need the actual allocations for counter values that the *_group_alloc() functions do. Group and counter description needed for documentation are all available from the *_group_desc structs.</p>
<p>This would mean that we need to register every counter group independently from the *_group_alloc() calls happening right now, so the documentation knows about them - but as a side effect we could also have a function to allocate a rate_ctr/stat_item group by name (instead of struct pointer). Not sure how useful that would be.</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 - 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 - Feature #3227 (New): general idea: separate GSUP spec documenthttps://osmocom.org/issues/32272018-05-02T11:33:26Zneelsnhofmeyr@sysmocom.de
<p>we have GSUP specs in the osmo-gsm-manuals, but they are common chapters included in various usermanuals, i.e. somewhat hidden.<br />Maybe we should instead publish the GSUP specs as a distinct PDF so that it is more visible?</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 - Feature #2623 (New): SCCP/M3UA: detect restart of osmo-msc and ...https://osmocom.org/issues/26232017-11-07T23:25:36Zneelsnhofmeyr@sysmocom.de
<p>Connecting osmo-bsc and osmo-hnbgw to the MSC and SGSN via an OsmoSTP instance, it is currently not possible to detect that the MSC or SGSN has restarted.</p>
<p>Scenario: using a sysmoBTS as a NITB, change MSC config, restart MSC -- now osmo-bsc happily continues to run and does not even notice that it is an entirely new MSC instance running in the core net now.</p>
<p>In the old days, the SCCPlite link would go down, but since now OsmoSTP is in-between and has no concept of who depends on who, no-one is notifying BSC or HNBGW that MSC or SGSN have gone down. Find out how this is intended to be solved if at all, and devise a way how osmo-bsc will restart and/or reconnect to a new MSC instance, and so forth.</p> Cellular Network Infrastructure - Feature #2554 (New): Reference/Demo setup + documentation for u...https://osmocom.org/issues/25542017-10-06T14:39:27ZlaforgeCellular Network Infrastructure - Feature #2451 (New): Add static builds to jenkins jobshttps://osmocom.org/issues/24512017-08-18T10:51:23Zmsuraev
<p>Right now most (all?) Osmocom projects support static builds which is sometimes useful for testing and deployment in particular environments.</p>
<p>However, in the absence of per-commit tests it can be easily broken as an unintended side-effect of some patches.</p>
<p>We should add "--enable-static" test builds to the corresponding jenkins jobs to avoid breaking it.</p>