Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092020-07-02T06:43:32ZOpen Source Mobile Communications
Redmine 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 - 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 - 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 - 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 - 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 - Bug #3417 (New): show asciidoc counters does not show all the c...https://osmocom.org/issues/34172018-07-25T07:01:29Zdaniel
<p>Since show asciidoc counters only iterates through the allocated rate_ctr/stat_item groups it does not necessarily show all the counters that can be available.</p>
<p>For example the sgsn only creates (and reports) bssgp:bss_ctx counters if there is actually a bssgp configured in the sgsn. While you could argue that this is just a misconfiguration the issue remains with counters allocated for each mm or pdp context. As long as no phones are GMM attached the command show asciidoc counters does not know about any statistics for mm or pdp context.</p>
<p>We could add commands to add the rate_ctr_group_desc ans osmo_stat_item_group_desc to another list which keeps track of available counters and traverse that for show asciidoc stats as we don't need the actual allocations for counter values that the *_group_alloc() functions do. Group and counter description needed for documentation are all available from the *_group_desc structs.</p>
<p>This would mean that we need to register every counter group independently from the *_group_alloc() calls happening right now, so the documentation knows about them - but as a side effect we could also have a function to allocate a rate_ctr/stat_item group by name (instead of struct pointer). Not sure how useful that would be.</p> Cellular Network Infrastructure - Bug #3382 (New): Investigate and fix lintian issues listed by D...https://osmocom.org/issues/33822018-07-05T11:37:34Zpespin
<p>This web page lists a list of warnings which we may want to fix: <a class="external" href="https://lintian.debian.org/maintainer/Debian-mobcom-maintainers@lists.alioth.debian.org.html">https://lintian.debian.org/maintainer/Debian-mobcom-maintainers@lists.alioth.debian.org.html</a></p> Cellular Network Infrastructure - Feature #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 - Bug #3192 (New): meas_vis: use the lchan identity as primary ke...https://osmocom.org/issues/31922018-04-21T19:21:40Zneelsnhofmeyr@sysmocom.de
<p>While re-adding meas_feed to osmo-bsc.git, I noticed that the meas_vis and meas_web tools appear to use the lchan's IMSI as primary key to visualizing active lchans. They should use the bts,trx,ts,ss number instead.</p>
<p>See also: <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: resurrect meas_feed (Resolved)" href="https://osmocom.org/issues/2968">#2968</a> <a class="issue tracker-2 status-3 priority-1 priority-lowest closed" title="Feature: obtain and store subscriber identity (Resolved)" href="https://osmocom.org/issues/2969">#2969</a></p>
<p>meas_vis is currently still in openbsc.git, it should probably move over to osmo-bsc <a class="issue tracker-2 status-6 priority-2 priority-default closed" title="Feature: move meas_vis and meas_json over to osmo-bsc.git (Rejected)" href="https://osmocom.org/issues/3191">#3191</a>.<br />meas_web is external, but it could make sense to send a pull request.</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 - 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> 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 - Bug #1612 (New): more configuration consistency checkinghttps://osmocom.org/issues/16122016-02-23T16:22:14Zlaforge
<p>Right now it is possible to configure various things that wouldn't work, like an ARFCN that is outside the band of the BTS, or even the TRX.</p>
<p>More consistency checks would make sense, together with reasonable error messages.</p> Cellular Network Infrastructure - Feature #1598 (New): Scripting language interfacehttps://osmocom.org/issues/15982016-02-23T15:52:29Zlaforge
<p>For lab-type setups and testing of M2M devies, it would be useful to have some kind of script language bindings so the NITB could be instructed to perform certain actions under control of external software. Actions include triggering a hand-over, sending SMS, startin silent call, ...</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>