Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-01-11T20:17:59ZOpen Source Mobile Communications
Redmine Cellular Network Infrastructure - Feature #6327 (New): Osmocom-build-tags-against-master job buil...https://osmocom.org/issues/63272024-01-11T20:17:59Zfixeria
<p>The idea behind this job is to check if [a limited set of] old tagged versions of various Osmocom projects can still compile with the most recent versions of Osmocom libraries.</p>
<p>I checked the build logs and found out that it's building the default configurations for Osmocom projects (no <code>--with-foo</code> flags passed to configure scripts).<br />For instance, the default build configuration for osmo-bts does not include any models except the <code>-virtual</code>, so <code>osmo-bts-{trx,sysmo,...}</code> are not covered.<br />Same applies to osmo-trx: we build only the common code, but not the <code>-uhd/-lms</code> variants.</p>
<p>The more complete configurations we build, the more chances we have to catch various backwards compatibility problems.<br />A good example is <a class="external" href="https://cgit.osmocom.org/osmo-ci/tree/coverity/build_Osmocom.sh">https://cgit.osmocom.org/osmo-ci/tree/coverity/build_Osmocom.sh</a>, where we do enable much more features / variants.<br />Maybe this code can be generalized and re-used somehow?</p> Cellular Network Infrastructure - Feature #6243 (New): vty cfg: make changing startup defaults of...https://osmocom.org/issues/62432023-11-01T00:56:38Zneelsnhofmeyr@sysmocom.de
<p>Sometimes our recommendation of what the usual/good setting should be for a given vty config item changes.<br />Then we have the problem that we cannot change it without endangering running installations,<br />and/or creating hassle for admins.</p>
<p>So how about a general mechanism in all of our config files in form of a vty command, maybe like this:</p>
<p>osmo-foo.cfg:<br /><pre>
defaults (v0|v1.5|v1.6)
</pre></p>
<p>so a user can decide when to make the cfg upgrade, independently from binary upgrades.</p>
<p>When 'defaults' is not specified, we would have to assume like 'defaults v0'.<br />(A bit more convenient for new users would be to add the newest available 'defaults' setting automatically somehow,<br />but I guess that also breaks the entire feature then, unless someone can think of an elegant way.)</p> Cellular Network Infrastructure - Feature #6069 (In Progress): port hello-stk to ant-based build ...https://osmocom.org/issues/60692023-06-21T12:52:08Zlaforge
<p>It's rather hard to build the old hello-stk using java8 sdk and the sim-tools makefiles etc. on a current distribution today.</p>
<p>Instead, @merlinchlosta came up with a modern, ant-based build using <a href="https://github.com/martinpaljak/ant-javacard/releases/latest/download/ant-javacard.jar" class="external">ant-javacard</a> by Martin Paljak</p>
<p>I've started to migrate our hello-stk.git (with both the HelloSTK and the ImsiChange applet) over to this build system. See my <a href="https://gitea.osmocom.org/sim-card/hello-stk/src/branch/laforge/ant" class="external">laforge/ant branch</a>.</p>
<p>Please take this over by doing some more testing and updating documentation (README, wiki, possibly other places like sysmoUSIM/ISIM user manual, ...). Ideally we'd have the documentation in one place, and other locations just point to it.</p> Cellular Network Infrastructure - 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 - 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 - 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 - 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 #5124 (Feedback): network:osmocom:nightly feed with "-O...https://osmocom.org/issues/51242021-04-20T21:00:00Zlaforge
<p>when debugging issues, it's always annoying to run into "... optimized out" in gdb.</p>
<p>It might make sense to have an OBS feed that basically is a copy of 'nightly' but has all binaries built with -O0</p>
<p>Hopefully that's not all that much effort? Can we somehow inject the compiler flag without having to maintain a package-specific patch against debian/rules?</p> 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 - 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 - 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 - Feature #4073 (Stalled): try to get counter and vty reference i...https://osmocom.org/issues/40732019-06-21T14:55:46Zlaforge
<p>The existing approach of extracting counter and vty information at runtime has various disadvantages. We'd like to explore options to generate this information from the source code. Whether that's using static code analysis, an existing C parser of some form, clang, ... doesn't really matter.</p>
<p>The goal is to generate the same textual (asciidoc for counters, xml for VTY) format as the existing 'runtime' approach.</p> Cellular Network Infrastructure - Feature #4006 (Stalled): TRX protocol: wind of changehttps://osmocom.org/issues/40062019-05-16T19:54:33Zfixeria
<p>We are using TRX protocol in <a class="wiki-page" href="https://osmocom.org/projects/osmobts/wiki">OsmoBTS</a> in order to "speak" with transceiver (e.g. <a class="wiki-page" href="https://osmocom.org/projects/osmotrx/wiki">OsmoTRX</a>, FakeTRX). Basically it defines three interfaces: clock for TDMA frame clock indications, control (we agreed to call it TRXC) for transceiver management, and data (TRXD) for exchanging Rx/Tx bursts. It was first introduced in <a href="http://openbts.org/" class="external">OpenBTS</a> project, from which we forked <a class="wiki-page" href="https://osmocom.org/projects/osmotrx/wiki">OsmoTRX</a>. For more information, please see: <a class="external" href="https://github.com/RangeNetworks/openbts/blob/master/TRXManager/README.TRXManager">https://github.com/RangeNetworks/openbts/blob/master/TRXManager/README.TRXManager</a>.</p>
<p>The protocol is being used for years, and it still serves us for good. However, it is extremely inflexible. For example, there is no way to send more information about received bursts on TRXD interface, than the fixed-size header already has (TDMA frame number, timeslot number, RSSI, ToA256). On TRXC interface, which is working over UDP as the other ones, there is no way to distinguish command retransmission, which may happen due to timeout, from a regular command. There is no way to notify the L1 (i.e. <a class="wiki-page" href="https://osmocom.org/projects/osmobts/wiki">OsmoBTS</a>) about some events (e.g. device has been disconnected), no way to indicate transceiver version, and so on...</p>
<p>During <a class="wiki-page" href="https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019">OsmoDevCon2019</a> (and before too) we have been discussing the idea of introducing the new version of TRX protocol, which would allow us to solve the mentioned problems. In order to keep backwards compatibility, both L1 and transceiver would initially use the old TRX protocol, while the new version can be optionally enabled by sending a command on TRXC interface. If the transceiver does support the new protocol, it would acknowledge the command. Otherwise, the command is rejected, so L1 would continue to work in "backwards compatibility" mode.</p>
<p>Finally, we need to write a proper protocol description like we already have for GSUP in <a class="external" href="https://git.osmocom.org/osmo-gsm-manuals/">https://git.osmocom.org/osmo-gsm-manuals/</a>. But before starting to work on this, let's create some kind of a wish list - what would you like to see in the new version of TRX protocol?</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 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 - Feature #3714 (New): implement Internal Handover With MSC Supporthttps://osmocom.org/issues/37142018-11-27T23:17:34Zneelsnhofmeyr@sysmocom.de
<p>After we have implemented <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: internal handover: when handover changes the speech codec, it should notify the MSC with BSSMAP H... (Resolved)" href="https://osmocom.org/issues/3645">#3645</a>, I have now encountered 3GPP TS 23.009 6.3.1 "General Description of Internal Handover with MSC Support":</p>
<pre>
If the A-Interface User Plane is carried over IP (or shall be handed over to IP) and one or more of the A-Interface User
Plane parameters need to be modified, for example the Codec Type, or the Codec Configuration (BSS determines that
no compatible Codec Type or Codec Configuration exists for the target cell), or the IP Transport Layer Address, or the
UDP Port, or the CSData Redundancy Level, or the A-Interface Type itself (e.g. from TDM to IP or vice versa), then a
"BSS Internal Handover with MSC support" shall be performed (see 3GPP TS 48.008 [5] subclause 3.1.5c.1).
</pre>
<p>So if we want to change the codec, we should actually not only tell the MSC about it in the end, but involve it from the start:</p>
<p><img src="https://osmocom.org/attachments/download/3463/23.009_6.3.2.png" alt="" /></p> Cellular Network Infrastructure - Feature #3699 (Stalled): merge Debian patcheshttps://osmocom.org/issues/36992018-11-19T13:41:54Zmsuraev
<p>There're numerous patches from Debian developers available via:<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 />individual package links example:<br /><a class="external" href="https://sources.debian.org/patches/libosmo-sccp/0.10.0-2/">https://sources.debian.org/patches/libosmo-sccp/0.10.0-2/</a><br />Relevant package version could be obtained from the first link.</p>
<p>Some of those patches are Debian-specific while others are generally relevant fixes. We should go over all packaged projects and submit all relevant patches to gerrit for review.</p>
<p>Note: Debian seems to have the most recent versions packaged compared to other repositories according to repology - see for example<br /><a class="external" href="https://repology.org/metapackage/libosmocore/versions">https://repology.org/metapackage/libosmocore/versions</a></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>