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 - 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 #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 #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 #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 - 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 #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 - Feature #5722 (New): Migrate jenkins build slaves from docker t...https://osmocom.org/issues/57222022-10-21T17:42:14Zmsuraev
<p><a class="external" href="https://podman.io/whatis.html">https://podman.io/whatis.html</a> - it's container runtime compatible with docker (and corresponding jenkins plugin) with several advantages:<br />- proper handling of systemd inside the container out-of-the-box<br />- ability to run rootless<br />- better integration with host's systemd</p>
<p>Note: there's podman-docker package which comes with alias which allows using familiar "docker ..." command-line with podman.</p> Cellular Network Infrastructure - Feature #5692 (New): switch to C99 standard flexible arrays ins...https://osmocom.org/issues/56922022-09-29T05:59:50Zlaforge
<p>Apparently, C99 has introduced <em>flexible array members</em> (see <a class="external" href="https://en.wikipedia.org/wiki/Flexible_array_member">https://en.wikipedia.org/wiki/Flexible_array_member</a>) while we still use the ancient, much older gcc specific syntax of <code>[0]</code> length arrays.</p>
<p>The main advantage of the flexible array approach are that the compiler allegedly ensures there are no struct members following the [] member.</p> Cellular Network Infrastructure - Bug #5669 (New): Test .deb packages built by our OBShttps://osmocom.org/issues/56692022-08-30T08:09:44Zmsuraev
<p>Would be nice to have automated quality checks for our .deb packages similar to nightly tests run for osmo-* projects.</p>
Notable candidates:
<ul>
<li><a class="external" href="https://wiki.debian.org/piuparts">https://wiki.debian.org/piuparts</a></li>
<li><a class="external" href="https://tracker.debian.org/pkg/lintian">https://tracker.debian.org/pkg/lintian</a></li>
<li><a class="external" href="https://packaging.ubuntu.com/html/auto-pkg-test.html">https://packaging.ubuntu.com/html/auto-pkg-test.html</a></li>
</ul>
<p>This would allow us to catch packaging-related issues early on as well as prevent bitrot (like outdated standards version etc).</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 - Feature #5013 (New): investigate "vtysh" for Osmocomhttps://osmocom.org/issues/50132021-02-06T14:14:43Zlaforge
<p>The original zebra/quagga code base has the concept of a <code>vtysh</code>, which is a shared vty for all of the various deamons.</p>
<p>I've never used it in zebra/quagga, but it might be something interesting to have also in the context of osmocom software.</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 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> Cellular Network Infrastructure - Support #4333 (Feedback): GSUP binary compatibility: add GSUP p...https://osmocom.org/issues/43332019-12-16T13:56:14Zneelsnhofmeyr@sysmocom.de
<p>I think it would be good to discuss binary compat in GSUP in general.<br />We're currently putting more and more functionality and weight on GSUP,<br />especially with D-GSM connecting several otherwise independent sites.<br />If we ever need to enhance parts of the protocol, it would be good to do<br />it in a way that allows in-band knowledge about what the coding should be.<br />Related:</p>
<ul>
<li>introduce ToN/NPI to MSISDN coding; this applies to the plain MSISDN IE,<br /> as well as the SMS-over-GSUP OA and DA IEs.</li>
<li>I am tweaking the Routing Error coding, where originally it sent the Source Name and Destination Name back unchanged<br /> -- which does not make sense when proxy routing comes into the picture.<br /> The Source/Destination Name must be swapped so that the error message reaches the originator of the request.</li>
</ul>
<p>One way would be to add new IEs for each change, either to supplement or replace previous IEs.<br />But to, for example, add ToN/NPI to MSISDN encoding, should be add new IEs for all of<br />MSISDN, SMS-OA and SMS-DA MSISDNs? Rather not. Should we add a new Routing Error message type? no.</p>
<p>It seems to me that the generally cleanest way to tweak the GSUP protocol<br />coding would be to introduce a protocol version IE.<br />Then we could allow clients to encode in both old and new formats...</p>
<p>To not send a new coding to an old client, osmo-hlr would also<br />need to keep track of which GSUP site speaks which protocol version.</p>
<p>Another way would be to add explicit new IEs for every binary incompatibility,<br />either supplementing current IEs, or replacing them (and using a new IE discriminator).</p>
<p>One idea is a protocol version communicated during IPA handshake,<br />where the client also sends the IPA unit name.<br />A problem here is that a GSUP proxy may have recent protocol capability, while it forwards for older clients.<br />If an older client is proxied, the final destination may still assume a newer client only because<br />the proxy in-between is.</p>
<p>Another idea is a Version IE (osmo_gsup_message.version), that can be sent for every GSUP message.<br />Absence of the version tag would imply version == 0. It would in fact only be strictly required to be included<br />if any encoded IE has an encoding that is not identical to version 0.</p>
<p>The gsup.c encoding/decoding could then switch() on the protocol version and encode/decode differently.</p>
<p>Does it make sense to implement such, for example to fix the MSISDN coding in SMS-over-GSUP and the plain MSISDN IE at the same time,<br />and to indicate that the Routing Error response contains the original requestor as Destination Name?</p> Cellular Network Infrastructure - Feature #4277 (New): implement an SMSC to work with OsmoMSChttps://osmocom.org/issues/42772019-11-22T14:45:20Zneelsnhofmeyr@sysmocom.de
<p>The single remaining legacy from OsmoNITB that is still present in OsmoMSC is the integrated SMS database.<br />It would be nice to be able to offload SMS delivery to a separate SMSC process.<br />It would be appropriate to implement that using SMS-over-GSUP, and connect the SMSC to OsmoHLR as GSUP client.</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 #4141 (New): No osmux specific code in place during codec n...https://osmocom.org/issues/41412019-08-05T15:57:19Zpespin
<p>Current code in OsmoBSC and OsmoMSC doesn't take into account that Osmux is to be used when codec negotiation goes one. That means that supported codec list needs to be correctly configured manually in VTY in order to avoid selecting incorrect codecs (like non-AMR). Moreover if an MS doesn't support AMR, since we don't have transcoding yet, the call cannot take place.</p>
<p>Different scenarios need to be listed here and think about what we want to do in each case.</p> Cellular Network Infrastructure - Bug #4108 (New): osmo-ctrl2cgi, osmo-trap2cgi: missing default ...https://osmocom.org/issues/41082019-07-16T12:30:11Zosmith
<p>Default configs for osmo-ctrl2cgi and osmo-trap2cgi do not get installed in the debian packages. Therefore the systemd services don't work out of the box.</p>
<p>Both programs are part of osmo-python-tests.git.</p>
<p>I'm setting this to low priority as I think that the programs are not widely used.</p> Cellular Network Infrastructure - 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 Network Infrastructure - Feature #3670 (New): TTCN-3 tests for statsd exporter codehttps://osmocom.org/issues/36702018-10-24T18:46:26ZlaforgeCellular 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 #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 - 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 - Bug #2839 (New): statistics split betwteen 2G and 3Ghttps://osmocom.org/issues/28392018-01-18T20:05:59Zlaforge
<p>many of our statistics/countrs currnetly don't distinguish between 2G and 3G bearer. This means we cannot know how many 2G vs 3G LU we have received in a given period of time, for example.</p>