Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-01-28T15:42:07ZOpen Source Mobile Communications
Redmine 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 #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 #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 #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> Cellular Network Infrastructure - Feature #5446 (New): correlate git version to ttcn3 testshttps://osmocom.org/issues/54462022-02-07T18:06:01Zneelsnhofmeyr@sysmocom.de
<p>This happens a lot: we improve ttcn3 testing and enhance osmo-foo master, and then<br />obviously the latest binaries cannot possibly pass the tests. We invent and managa<br />shims in jenkins.sh and ttcn3 config to not do something or other on latest.</p>
<p>A way to not have this burden would be that the ttcn3 test suite for a program <br />is correlated to the git version being tested, for example if the ttcn3 is kept <br />in the same git tree as the program. We should use the 'latest' version of <br />ttcn3 tests for a latest binary. With an implicit correlation, we can always <br />use exactly the tests that match the specific git revision that was built, no<br />matter if it was released or we're just rebasing a local branch.</p>
<p>I think in the long run it would save us a lot of grunt work, and it would <br />definitely save a lot of code cruft to make specific parts of the tests<br />optional.</p> Cellular Network Infrastructure - Bug #5188 (New): BSSMAP Cell Identifier IE vs. Cell Identifier ...https://osmocom.org/issues/51882021-06-23T00:43:19Zneelsnhofmeyr@sysmocom.de
<p>In libosmocore, we have enum CELL_IDENT, which gets used in both of<br /> Cell Identifier IE (3GPP TS 48.008 3.2.2.17)<br />and<br /> Cell Identifier List IE (3GPP TS 48.008 3.2.2.27)</p>
<p>The similar meaning and structuring of these two IEs suggests that the List IE<br />is simply a bunch of the plain Cell Identifier. However, if you read in 3GPP TS<br />48.008, comparing 3.2.2.17 and 3.2.2.27, there is this odd difference:</p>
<p>3.2.2.17, Cell Identifier IE:</p>
<pre><code>0000 CGI<br /> 0001 LAC+CI<br /> 0010 CI<br /> 0011 No cell</code></pre>
<pre><code>1000 PLMN+LAC+RNC (<del>> E-UTRAN)<br /> 1001 RNC (</del>> E-UTRAN)<br /> 1010 LAC+RNC (-> E-UTRAN)<br /> 1011 SAI<br /> 1100 LAC+RNC+CI</code></pre>
<p>3.2.2.27a, Cell Identifier List Segment:</p>
<pre><code>0000 CGI<br /> 0001 LAC+CI<br /> 0010 CI<br /> 0011 No cell</code></pre>
<pre><code>0100 LAI<br /> 0101 LAC<br /> 0110 entire BSS<br /> 0111 MCC+MNC</code></pre>
<p>I noticed this because I was trying to check for the correct target cell <br />identifier in the BSSMAP Handover Request message; we send a LAI cell <br />identification in the Cell Identifier IE. wireshark shows the LAI cell<br />identifer the same way that osmo-msc intends to encode it, but the TTCN3 <br />BSSAP_Templates fail to parse this LAI cell identifier.</p>
<p>So I added this cell id type to BSSMAP_IE_CellIdentifier in<br />./deps/titan.ProtocolModules.BSSMAP/src/BSSAP_Types.ttcn. and just to confirm<br />that I'm right i took a quick look in the spec, and then found that the ttcn <br />definition is in fact on par with the spec: the LAI cell id is not<br />present in 3.2.2.17 at all!</p>
<p>Now, our libosmocore gsm/protocol/gsm_08_08.h and gsm0808_utils.h are based on<br />the assumption that the same cell identifiers are used in both of these IEs.</p>
<p>The osmo-bsc and osmo-msc neighbor config for inter-BSC handover is built<br />assuming that we can send the 3.2.2.27a cell identifiers in the Handover<br />Request's 'Cell Identifier (Target)' IE.</p>
<p>Apparently the spec intends otherwise.</p>
<p>The effect of this goes across several osmo cn components:</p>
<ul>
<li>We define enum CELL_IDENT in libosmocore.</li>
<li>osmo-bsc sends the Handover Request using the 'Cell Identifier (Serving)' and 'Cell Identifier (Target)' IEs.</li>
<li>osmo-msc parses these, possibly forwards in inter-MSC handover procedure.</li>
</ul>
<p>I'm not sure how to resolve this.</p>
<ul>
<li>We could just accept that we're using the 3.2.2.27a identifiers also in 3.2.2.17. It makes an awful lot of sense in fact.<br /> The wireshark implementation seems to agree with this point, though of course that's not the benchmark.<br /> It might pose an incompatibility with strictly spec conforming cn implementations.<br /> And we would need to extend the TTCN BSSAP_Types.ttcn with values that aren't strictly present in 3.2.2.17,<br /> if we want to test these cell identifier types in our test suite.</li>
</ul>
<ul>
<li>or we could endeavour to fix the identifiers that we use in the BSSMAP protocol according to spec, in osmo-bsc and osmo-msc
<ul>
<li>either we introduce two distinct enums -- that could ripple through a lot of the cell identifier API, ugly.</li>
<li>or we still use the same enum for both, but making distinctions in the implementations which values are used for which.</li>
</ul></li>
</ul>
<p>To enforce that, we may have to adjust which cell identifier types can be used in the neighbor configuration of osmo-bsc and osmo-msc,<br />or we find ways to, for example, convert all cell identifier types to a supported one.<br />I guess easiest would be to enforce full CGI everywhere.</p>
<p>Yet easier would be to highlight in the documentation that osmocom is capable of nonstandard cell identifiers,<br />and to conform to specs users should simply use the full CGI everywhere in the neighbor config.</p>
<p>Any insights or opinions on this?</p> 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 Network Infrastructure - Feature #4587 (New): Add port numbers to /etc/services during i...https://osmocom.org/issues/45872020-06-06T09:40:54Zlaforge
<p>I think it would be great if we'd add the <code>/etc/services</code> snippet from <a class="wiki-page" href="https://osmocom.org/projects/cellular-infrastructure/wiki/Port_Numbers#etcservices">Port_Numbers</a> to /etc/services during the installation. This enables people to do <code>telnet localhost osm-msc</code> or the like, without having to memorize port numbers all the time.</p>
<p>It's a bit ugly as there is no /etc/services.d or the like, so we have to add/patch the services to the file.</p>
In order to do that reasonable, the related postinst script should (for each service)
<ul>
<li>check if the entry already exists, and do nothing if it does</li>
<li>append the entry to the end of the file, if no entry exists yet</li>
</ul>
<p>We could do this in bulk from libosmocore, or we could add/remove each individual line for each program we install from the respective osmo-* package.</p>
<p>The alternative would be to ship something like an 'osmo-telnet' client program that would have compile-time knowledge about the port numbers. As we already maintain a fork of libtelnet.git on osmocom.org, that may be an option...</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> Cellular Network Infrastructure - Feature #4376 (New): Define distinct X timer numbers across all...https://osmocom.org/issues/43762020-01-23T21:21:16Zneelsnhofmeyr@sysmocom.de
<p>Using osmo_tdef API, we are managing various 3GPP defined T timer numbers (like "T3203")<br />To add our own timers, we're using X timers (like "X1234").<br />We should best choose globally distinct X timer numbers for every program and every use.<br />So far we're seeing a collision of e.g. X1, X2 to mean different things according to context.<br />That would be fine and is manageable, but it also wouldn't be much of a problem to choose distinct number spaces.</p>
<p>Create a wiki page like <a class="wiki-page" href="https://osmocom.org/projects/cellular-infrastructure/wiki/Port_Numbers">Port Numbers</a> for X timers (and maybe also for T timers we have implemented, while at it)<br />and possibly fix current duplication in recently added X timer numbers</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 #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 #3779 (New): explore providing a VM image with all of o...https://osmocom.org/issues/37792019-02-03T23:19:50Zlaforge
<p>For gnuradio this exists (I don't think it's an "official" part of the project): An auto-generated VM image containing gnuradio, gqrx, soapysdr, and whatever other tools that one might use it with.</p>
<p>The images are created using packer.io, which seems to automatize the build of images in a variety of formats, including kvm/qemu, virtualbox and others.</p>
It might make sense to explore something similar, whree we'd start with a stock debian/ubuntu, and then
<ul>
<li>pull in the osmo* packages via the feeds, as well as</li>
<li>wireshark with a good default configuration (and possibly any of our pending patches), </li>
<li>other tools that may be useful when setting up an osmocom network</li>
<li>all our user manuals (which might actually want to become part of the debian -doc packages)</li>
</ul> 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 - Feature #3628 (New): document nanoBTS calibration procedure usi...https://osmocom.org/issues/36282018-10-04T11:13:31Zlaforge
<p>The nanoBTS has the capability to OCXO calibration against another (macro) BTS. We had implemented this in ipaccess-config, but we apparently never documented how it works.</p>
<p>Let's add it somewhere to the nanoBTS related wiki pages.</p>
<p>Without trying, I remember that it was part of the "Tests" that can be triggered via OML.</p>
<pre>
static const struct value_string test_names[] = {
»·······{ NM_IPACC_TESTNO_CHAN_USAGE, "Channel Usage" },
»·······{ NM_IPACC_TESTNO_BCCH_CHAN_USAGE, "BCCH Channel Usage" },
»·······{ NM_IPACC_TESTNO_FREQ_SYNC, "Frequency Synchronization" },
»·······{ NM_IPACC_TESTNO_BCCH_INFO, "BCCH Info" },
»·······{ NM_IPACC_TESTNO_TX_BEACON, "Transmit Beacon" },
»·······{ NM_IPACC_TESTNO_SYSINFO_MONITOR, "System Info Monitor" },
»·······{ NM_IPACC_TESTNO_BCCCH_MONITOR, "BCCH Monitor" },
</pre>
<p>I think you start with a CHAN_USAGE to see the receive level per ARFCN. You then proceed to a FREQ_SYNC to see which of those have a FCCH (and hence are BCCH/CCCH carrying).</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 - 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 - Feature #3229 (New): build-system: jenkins.sh: Improve debian ...https://osmocom.org/issues/32292018-05-03T12:40:28Zpespin
<p>The idea is to add extra tests/checks to avoid breaking debian package building during nightly builds in OBS. Instead, let's catch it during gerrit patch submission time and don't allow merging it until it's fixed.</p>
<p>We should investigate several tools, like pbuilder, dpkg-build, etc. I recall lynxis also told me something about some kind of lint tool available for this purposes.</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 #3142 (New): Further simplification of "NITB like" setupshttps://osmocom.org/issues/31422018-04-05T20:09:38Zlaforge
<p>Running the post-NITB network is quite a lot more complex than the old code.</p>
<p>There are some ideas on how to make it simpler to run small, self-contained networks while removing some complexity</p>
<ul>
<li>I was also wondering if we should spend time on "MGW-less operation". In theory, you only need OsmoMGW if you have no IP-level routing between your Abis / A / core network [like any decent network operator for security reasons]. But then, if you run everything on one machine, and don't need/want transcoding, and have transparent routing between all components, we could do without the MGW.</li>
</ul>
<ul>
<li>stp-less operation should also be possible (but make configuration actually more complicated), as both the "ASP" (client) and "SG" (server) role are inside libosmo-sigtran, and hence the server could run inside the MSC without the need of an external stp (osmo-stp is just a thin wrapper with vty around libosmo-sigtran)</li>
</ul>
<p>Let's keep this as a reminder and create sub-tasks as ideas materialize more</p> Cellular 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> 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> Cellular Network Infrastructure - Feature #1590 (New): Extension of Control Interface / external ...https://osmocom.org/issues/15902016-02-23T15:47:47Zlaforge
<p>The request to configure most (or all?) NITB parameters not only by VTY but also via an external SNMP agent via the control interface has come up several times.</p>
<p>The control interface would have to be extended with all relevant (which are those?) parameters.</p>
<p>An external SNMP agent would have to be developed, attaching to the control interface. python snmp might be a good candidate as basis for that.</p>