Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-02-28T19:37:26ZOpen Source Mobile Communications
Redmine 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 #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 #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 - 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 - 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> 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 - 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 #3386 (New): Generate man pages at build time from adoc...https://osmocom.org/issues/33862018-07-06T10:24:03Zpespin
<p>Once we have documentation being build in each project repository separately (see <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Move project specific manuals from osmo-gsm-manuals to each respective git repository (Resolved)" href="https://osmocom.org/issues/3385">#3385</a>), we want to generate man pages for each repository.</p>
<p>The idea here is to have an .adoc file with all the required content to be used in the man pag, and which is already included in the user manual. Then we need to scripts/makefile to transform this .adoc file into man source format and make it be build and installed when --enable-man is passed. Then, install it in the debian packages (which means we in turn need to modify dh_configure or similar to pass the --enable-man flag, and somehow include the common osmo-gsm-manuals.git in there when sending to OBS).</p> Cellular Network Infrastructure - Feature #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 #3227 (New): general idea: separate GSUP spec documenthttps://osmocom.org/issues/32272018-05-02T11:33:26Zneelsnhofmeyr@sysmocom.de
<p>we have GSUP specs in the osmo-gsm-manuals, but they are common chapters included in various usermanuals, i.e. somewhat hidden.<br />Maybe we should instead publish the GSUP specs as a distinct PDF so that it is more visible?</p> Cellular Network Infrastructure - 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 #2604 (Stalled): GSUP-to-DIAMETER converter / IWFhttps://osmocom.org/issues/26042017-10-29T23:01:06Zlaforge
<p>In order to support a single subscriber database for 2G/3G and LTE, operators normally use a single HSS. HSS is the EPC successor of the LTE.</p>
<p>Instead of MAP over SS7, HSS's speak DIAMETER over SCTP or TCP (with optional TLS). The types of procedures / transactions are pretty much the same as before, but the encoding and the protocol changed completely.</p>
<p>There are a couple of (at least minimal) HSS implementations out there, from freeDiameter to nextepc, to name some examples.</p>
<p>If we were to implement a converter between GSUP and DIAMETER, then the OsmoMSC and OsmoSGSN could access an external HSS - and that same HSS could be accessed from nextepc or even openair-cn for LTE access.</p>
<p>3GPP TS 29.305 specifies the MAP-to-DIAMETeR InterWorkingFunction (IWF), which is pretty much the same device, with the exception that we'd use GSUP instead of MAP.</p> Cellular Network Infrastructure - Feature #2584 (New): Have "osmo-network-check" to verify "Netwo...https://osmocom.org/issues/25842017-10-20T07:25:14Zlaforge
While looking at <a class="wiki-page" href="https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box">Osmocom_Network_In_The_Box</a> it occurred to me that it might be useful to have some kind of script/program that helps people to validate their configuration. Things that could be checked automatically are:
<ul>
<li>static configuration
<ul>
<li>if all the intended processes are running (using "ps" output)</li>
<li>if the telnet of all processes is reachable</li>
<li>if any expected TCP/UDP/SCTP ports (like OML/RSL/AoIP/...) are reachable</li>
</ul>
</li>
<li>runtime checks (mostly via CTRL, add interface where needed)
<ul>
<li>does OsmoBSC report a BTS connected?</li>
<li>does OsmoBSC think its SIGTRAN/AoIP link to STP is up?</li>
<li>does OsmoSTP think that its links to BSC and MSC are up?</li>
<li>does OsmoMSC think that its link to the STP is up?</li>
<li>does OsmoMSC see any BSC connected (BSSAP RESET)?</li>
<li>does OsmoMSC have a connection to OsmoHLR via GSUP?</li>
<li>does OsmoHLR see a connection from OsmoMSC?</li>
</ul></li>
</ul>
<p>All of the above (and possibly even more) should be possible fully automatic and a short summary could be printed to the screen, like one line for each check with a green OK or red ERROR. Any ERROR message should contain a URL to an error-specific wiki page where we can compile a list of possible causes or other help on what could possibly be the cause of such error.</p>
<p>The script/tool should (at least initially) make the assumption that (BSC, MSC, STP, HLR) and possibly (SGSN, GGSN) runs on the same system, and match 1:1 the wiki page for a basic setup.</p>
<p>This is just my initial idea, I'm sure it can be further extended.</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 #1596 (New): Generation of accounting/billing datahttps://osmocom.org/issues/15962016-02-23T15:51:42Zlaforge
<p>There should be some interface by which we generate simple accounting/billing data of some form.</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>