Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-03-26T14:00:15ZOpen Source Mobile Communications
Redmine OsmoMGW - Bug #6424 (In Progress): TC_one_crcx_loopback_rtp_implicit consistently failing in mast...https://projects.osmocom.org/issues/64242024-03-26T14:00:15Zlaforge
<p>`TC_one_crcx_loopback_rtp_implicit` appears to be failing consistently in master for 30+ consecutive builds. Meanwhile, the same test is passing just fine in latest. So there seems to be some (long-standing) regression in master?</p> OsmoGGSN (former OpenGGSN) - Bug #6423 (Resolved): GGSN_Tests regressions from build 1107 / Febru...https://projects.osmocom.org/issues/64232024-03-26T13:12:20Zlaforge
<p>The following 6 TTCN3 test cases used to pass in the `ttcn3-ggsn-test-kernel` job until build 110 on Feb 28, but started to fail consistently since Feb 29th:</p>
<ul>
<li>TC_act_deact_retrans_duplicate
<ul>
<li>"GGSN_Tests.ttcn:413 : CreatePDPContextResp: cause expectancies didn't match" </li>
</ul>
</li>
<li>TC_addr_pool_exhaustion
<ul>
<li>Dynamic test case error: Index overflow in a value of type @PreGenRecordOf.PREGEN_RECORD_OF_OCTETSTRING: The index is 0, but the value has only 0 elements.</li>
</ul>
</li>
<li>TC_lots_of_concurrent_pdp_ctx
<ul>
<li>"GGSN_Tests.ttcn:413 : CreatePDPContextResp: cause expectancies didn't match" </li>
</ul>
</li>
<li>TC_pdp46_act_deact_apn4
<ul>
<li>"GGSN_Tests.ttcn:413 : CreatePDPContextResp: cause expectancies didn't match" </li>
</ul>
</li>
<li>TC_pdp_act2_recovery
<ul>
<li>"GGSN_Tests.ttcn:400 : CreatePDPContextResp: cause expectancies didn't match" </li>
</ul>
</li>
<li>TC_pdp_act_restart_ctr_echo</li>
</ul>
<p>So it almsost looks like somebody changed some "cause" values and now the test expectations are no longer true?</p>
<p>Does anyone know anything about this?</p> OsmoBSC - Bug #6422 (Feedback): latest: BSC_Tests.TC_ctrl_location started fo fail on March 15thhttps://projects.osmocom.org/issues/64222024-03-26T13:03:08Zlaforge
<ul>
<li><a class="external" href="https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/ttcn3-bsc-test-sccplite/test_results_analyzer/">https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/ttcn3-bsc-test-sccplite/test_results_analyzer/</a></li>
</ul>
<p>This test used to pass and started failing since March 15. It fails consistently ever since. Interestingly, master is not affected.</p>
<p>I don't see any commits to osmo-ttcn3-hacks.git touching the BSC code which were merged on March 14th.</p>
<p>Does anyone have any ideas?</p> OsmoBTS - Bug #6421 (Resolved): BTS_Tests_OML.* all started to fail for latest+masterhttps://projects.osmocom.org/issues/64212024-03-26T12:58:34Zlaforge
<ul>
<li><a class="external" href="https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/ttcn3-bts-test-latest/test_results_analyzer/">https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/ttcn3-bts-test-latest/test_results_analyzer/</a></li>
<li><a class="external" href="https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/ttcn3-bts-test/test_results_analyzer/">https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/ttcn3-bts-test/test_results_analyzer/</a></li>
</ul>
<p>Given that both master and latest are failing, I presume it's a bug in our testsuite and not a regression in the actual software</p>
<p>In case anyone knows what might have caused this, please report here ASAP and'or adopt the ticket. Thanks!</p> libosmocore - Bug #6410 (New): osmo_io poll backend doesn't work on file descriptors that are not...https://projects.osmocom.org/issues/64102024-03-19T19:33:49Zlaforge
<p>I just wanted to use osmo_io on a file descriptor pointing to an actual file, not a socket.</p>
<p>The poll backend fails as it unconditionally tries to use sendmsg, even if the mode is READ_WRITE.</p> libosmo-sccp + libosmo-sigtran - Bug #6403 (Resolved): regression since osmo_io migrationhttps://projects.osmocom.org/issues/64032024-03-14T10:22:57Zlaforge
<p>Ever since we merged the osmo_io patch for libosmo-sigtran, it seems that SCCP_Tests.TC_process_rx_ludt is no longer passign, see<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sccp-test/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-sccp-test/</a></p>
<p>This test used to be a bit unstable in the past, but I triggered it two more times today, and all three (1x automatic, 2x manual) are consistent: This test no longer passes.</p> libosmocore - Feature #6402 (New): consider using IORING_RECVSEND_POLL_FIRST for our socket-readshttps://projects.osmocom.org/issues/64022024-03-14T08:21:57Zlaforge
<p>io_uring has an IORING_RECVSEND_POLL_FIRST which will increase the performance of read/recv/recvmsg/recvfrom calls if no data is present in the socket at the time we submit a read.</p>
<p>This works by going directly into poll, bypassing the initial attempt to recv/recvmsg.</p>
<p>Given that our sockets are often very low traffic and work in a request/response fashion, this might be worth a shot.</p> libosmocore - Feature #6401 (New): benchmark batching io_uring operationshttps://projects.osmocom.org/issues/64012024-03-14T08:10:59Zlaforge
<p>right now we <code>io_uring_submit()</code> reads/writes right when they are added. This triggers the kernel processing on those without the benefit of batching multiple operations.</p>
<p>We might want to try to benefit from batching by waiting until we enter osmo_select_main().</p> OsmoHNBGW - Feature #6395 (New): PFCP URR support in osmo-hnbgwhttps://projects.osmocom.org/issues/63952024-03-08T13:38:17Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to use PFCP URR to instruct the UPF to:
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p>The osmo-hnbgw side then will have to report those packet/byte counters [at the very least] as per-hnb aggregate figures.</p>
<p>Until osmo-upf has the related features (<a class="issue tracker-2 status-7 priority-1 priority-lowest" title="Feature: Basic URR (Usage Reporting Rule) support for tunnel mapping (Stalled)" href="https://projects.osmocom.org/issues/6394">#6394</a>), testing of the osmo-hnbgw side can be done against open5gs-upf, which should already suport it since <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> taught it URR support in April 2022.</p> OsmoUPF - Feature #6394 (Stalled): Basic URR (Usage Reporting Rule) support for tunnel mappinghttps://projects.osmocom.org/issues/63942024-03-08T13:33:39Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p><a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> had implemented something like this for open5gs-upf in<br /><pre>commit fb8ebcdbeae0648e30d04fd016a956642131dddd
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date: Fri Apr 8 16:10:42 2022 +0200
[UPF] Add initial support for URR Usage Report (#1476)
</pre><br />and following commits.</p>
<p>Now sadly, open5gs-upf is more like a lab-grade upf and nothing that scales at all, and we hence have users of osmo-upf that use it for its fast kernel path.</p>
<p>The primary goal for this feature is the <em>tunnel mapping</em> case in a osmo-hnbgw co-located osmo-upf. The packet and byte counters hence will have to be added to the nftables rules.</p> libosmocore - Bug #6393 (New): osmo_io conflating osmo_iofd_unregister vs osmo_iofd_closehttps://projects.osmocom.org/issues/63932024-03-07T09:22:49Zlaforge
<p>I've been starting to work on something like an osmo_io API user manual, and as part of that tried to think about how to guard osmo_io against invalid usage.</p>
We have
<ul>
<li>osmo_iofd_unregister</li>
<li>osmo_iofd_close</li>
<li>osmo_iofd_free</li>
</ul>
Oddities:
<ul>
<li>osmo_iofd_unregister sets the IOFD_FLAG_CLOSED flag, even though it does not close
<ul>
<li>osmo_iofd_register clears the IOFD_FLAG_CLOSED, so there's some symmetry, despite the name</li>
</ul>
</li>
<li>osmo_iofd_close also sets the IOFD_FLAG_CLOSED flag, but without unregistering
<ul>
<li>this mean we cannot use the IOFD_FLAG_CLOSED to check in osmo_iofd_unregister if the iofd was already unregistered</li>
<li>it actually doesn't close the fd unless there is an osmo_iofd_ops.close call-back from the backend</li>
<li>however, it does always set iofd->fd to -1, so if no such call-back exists, we have a fd leak</li>
</ul>
</li>
<li>osmo_iofd_free calls osmo_iofd_close, but not osmo_iofd_unregister. So it somehow tries to do whatever is needed before the free, but only half of it.</li>
</ul>
<p>I'm not entirely sure yet how to untangle this. Maybe we need multiple flags to properly distinguish the closed from the unregistered state? Or maybe we don't need another flag and use iofd->fd == -1 to determine the actual closed status, and rename the CLOSED flag to n UNREGISTERED flag?</p> Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Feature #6392 (New): video recording / c...https://projects.osmocom.org/issues/63922024-03-06T12:08:24Zlaforge
<p>We need to check how we can get c3voc video recording equipment on-site and who will operate it.</p> libosmocore - Feature #6390 (New): port CTRL over to osmo_io / io_uringhttps://projects.osmocom.org/issues/63902024-03-02T18:45:00Zlaforge
<p>In theory this should be fairly trivial to mogirate over. It uses a tx_queue anyway for writes today, so handing those msgb's over to osmo_io should be easy.</p>
<p>However, the user API of ctrl is a nightmare and it exposes a lot of internal details - among them are the use of ctrl_connection by a ctrl <strong>CLIENT</strong> from sysmobts_mgr.</p>
<p>Let's not do this now, the performance of CTRL is not that significant.</p> libosmocore - Feature #6389 (New): port VTY over to osmo_io / io_uringhttps://projects.osmocom.org/issues/63892024-03-02T16:55:56Zlaforge
<p>The VTY uses its 'buffer' layer between writes by the software and writing to the acutal socket file descriptor. buffer_flush_all is currently used whenever the socket is write-able. So it's a pull model.</p>
<p>We'd probably have to change that logic to work the other way around: Once a buffer has a certain fill-level (or age?), proactively push it via osmo_io.</p>
<p>Unless somebody uses a lot of scripts acccessing the VTY, it's also unlikely that the syscall load of a human VTY user would place significant I/O load on an osmocom program. So it's not super criticial.</p> libosmocore - Feature #6388 (New): stats_reporter via osmo_io / io_uring?https://projects.osmocom.org/issues/63882024-03-02T16:54:39Zlaforge
<p>I briefly looked at migrating the osmo_stats_reporter over to osmo_io, and I'm not entirely sure if it's that great an idea. Right now each stats_reporter has one msgb that's allocated at socket-open time. Whenever there's something to write, that buffer is used and then immediately sent off using sendto(). There's no integration into the osmocom select loop. We always assume the [udp] socket is writable. The buffers are hence never free'd or re-allocated at runtime.</p>
<p>If we switch over to osmo_io, then it would mean every stats report allocates a new msgb, and once that's handed over to the io_uring backend there are even more allocations. So yes, we'd save the sendto system call, but at the cost of more load on the heap allocator. The syscall is likely more expensive, sure. But is it worth it? I'm not so sure.</p> OsmoMGW - Feature #6387 (In Progress): osmo_io / io_uring support for RTP/RTCPhttps://projects.osmocom.org/issues/63872024-03-02T16:22:02Zlaforge
<p>The RTP/RTCP sockets of osmo-mgw should be prime candidates for migration to osmo_io and hence benefit from the optional io_uring backend.</p>
<p>Given the many small recvfrom/sendto syscalls on those sockets, performance should be enhanced in a significant way.</p> Core testing infrastructure - Bug #6386 (In Progress): eclipse-titan 9.0.0 not building in debian...https://projects.osmocom.org/issues/63862024-03-02T15:54:57Zlaforge
<p>I just ran into bugs caused by running a too old version of eclipse-titan (8.2.0 provided by debian), since our 9.0.0 is not building on unstable: <a class="external" href="https://obs.osmocom.org/package/show/osmocom:latest/eclipse-titan">https://obs.osmocom.org/package/show/osmocom:latest/eclipse-titan</a></p>
<p>Please have a look, thanks!</p> Core testing infrastructure - Bug #6381 (Feedback): libosmocore changes take too long until they ...https://projects.osmocom.org/issues/63812024-03-01T07:19:47Zlaforge
<p>(05:23:15 PM) hwelte: I don't understand why <a class="external" href="https://gerrit.osmocom.org/c/libosmo-netif/+/35069">https://gerrit.osmocom.org/c/libosmo-netif/+/35069</a> keeps failing even hours after the libosmocore patch has been merged. I even checked that the OBS package for libosmocore had been rebuilt meanwhile<br />(05:29:17 PM) hwelte: the debian10/debian12 builds fail despite the libosmocore on which the changes depend has long been built on obs.<br />(05:54:43 PM) osmith: hwelte, it says here: build jobs exist (gear icon): <a class="external" href="https://obs.osmocom.org/package/show/osmocom:master/libosmocore">https://obs.osmocom.org/package/show/osmocom:master/libosmocore</a><br />(05:55:04 PM) hwelte: osmith: yes, but that's for much more recent libosmocore commits<br />(05:55:04 PM) osmith: the builders just seem to be busy building everything, I guess because of multiple libosmocore merges in a row, each triggering a rebuild of everything<br />(05:55:12 PM) osmith: <a class="external" href="https://obs.osmocom.org/monitor">https://obs.osmocom.org/monitor</a> <- builders being busy<br />(05:55:34 PM) osmith: it might be that OBS doesn't publish a repository before all packages for a distribution are built<br />(05:58:26 PM) osmith: hwelte, so in summary: libosmocore changes cause a lot of packages to be built, and the repo (probably) only gets published once all packages are built. unfortunately it seems that the builders were not able to build everything within the last hours since the merge, or that it started building additional packages because of more merges.</p>
<p>So it somehow seems that if a longer series of patches is committed to libosmocore, each of them gets built as OBS packge for each arch/distibution, and that's what takes so long? Can we somehow get it to only build the most recent commit at a time, and first build that all the way to the end and make sure those packages are published/available for further downstream builds?</p>
It's not exactly a rare situation that we add something to one library, and then there are also patches that use those additions elsewhere. So either
<ul>
<li>we can achieve the above, or </li>
<li>we can make sure that repos/feeds are updated after building [only] the debian10/debian12 on amd64 which we use for gerrit build verification [and even prioritize those]?</li>
<li>we can make find some other way to make sure the (in this case) libosmocore package is somehow available for gerrit build verification after it has been built, and not only after the entire universe has been re-built?</li>
</ul> libosmo-abis - Bug #6375 (Resolved): default TCP user timeout is way too lowhttps://projects.osmocom.org/issues/63752024-02-24T07:00:58Zlaforge
<p>The default USERT_IMEOUT for TCP keep-alive (which is active by default) should have been:</p>
<pre><code>val = 1000 * line->keepalive_num_probes * line->keepalive_probe_interval + line->keepalive_idle_timeout;</code></pre>
<p>Which should have been 1000 * 10 * 3 + 30 which expands to roughly 30 seconds.</p>
<p>However, I guess there's two bugs in the code, looking at it:</p>
<ol>
<li>there should have been parenthesis around the + operator (line->keepalive_probe_interval + line->keepalive_idle_timeout) as the keepalive_idle_timeout is in seconds, not milli-seconds.</li>
<li>in the default case, all those values are configured to -1 (E1INP_USE_DEFAULT). This means we're using <code>1000 * -1 * -1 + -1 = 999</code>, i.e. just below aq second which clearly is not enough for a lossy satellite back-haul.</li>
</ol>
<p>This is actaully rather critical, a proposed untested fix is in <a class="external" href="https://gerrit.osmocom.org/c/libosmo-abis/+/36079">https://gerrit.osmocom.org/c/libosmo-abis/+/36079</a></p> Core testing infrastructure - Feature #6357 (Resolved): run (some?) tests with io_uring backend f...https://projects.osmocom.org/issues/63572024-02-09T16:02:06Zlaforge
For quite some time, we have the new osmo_io abstraction layer with two backends:
<ul>
<li>the [default] poll backend</li>
<li>the new io_uring backend</li>
</ul>
<p>This means we should start (or have started) testing not just with the default backend, but also with the io_uring based backend. Running the TTCN-3 test suites in both modes should give us an opportunity to see if there's any differences in tests passing/failing between the backends.</p>
<p>As we're soon moving more relevant sub-systems over to osmo_io (libosmo-sigtran being an important step) this becomes more and more relevant.</p>
The question is which tests we should run twice. I think we should start at least with
<ul>
<li>osmo-bts</li>
<li>osmo-bsc</li>
<li>osmo-mgw</li>
<li>osmo-msc</li>
<li>osmo-stp</li>
<li>osmo-hnbgw</li>
</ul>
<p>All of the above are used in performance-critical production deployments where users are waiting for io_uring based improvements.</p>
<p>STP/BSC/MSC are important given the imminent libosmo-sigtran/SCTP support for osmo_io</p> Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Feature #6290 (In Progress): Organize Os...https://projects.osmocom.org/issues/62902023-12-06T14:17:47Zlaforge
<p>We already wanted to re-start 2023 but somehow I didn't manage to ever find the time and energy to do it. But let's make sure we definitely have an OsmoDevCon in 2024 again.</p>
<p>The date and venue are still TBD, as is pretty much anything else.</p> OsmoBTS - Bug #6270 (In Progress): osmo-bts sends version report every 5s to BSC?https://projects.osmocom.org/issues/62702023-11-22T15:03:15Zlaforge
<p>on a Debian 12 system using osmocom-nightly 202311212026 (osmo-trx-uhd + osmo-bts-trx), I'm seeing osmo-bts sending a PCU version report every 5 seconds:</p>
<pre>
Nov 22 15:57:37 nuc-osmocom2 osmo-bts-trx[7356]: <0001> oml.c:93 OC=GPRS-CELL INST=(00,00,ff): Sending PCU version report to BSC: 1.3.1.9-26dc.202311212026
Nov 22 15:57:37 nuc-osmocom2 osmo-bsc[648]: <0004> abis_nm.c:352 OC=BTS(01) INST=(00,ff,ff): Reported connected PCU version 1.3.1.9-26dc.202311212026
Nov 22 15:57:38 nuc-osmocom2 osmo-bts-trx[7356]: <000b> trx_if.c:138 phy0.0: Clock indication: fn=1123815
Nov 22 15:57:38 nuc-osmocom2 osmo-bts-trx[7356]: <0000> rsl.c:496 Tx RSL RF RESource INDication
Nov 22 15:57:39 nuc-osmocom2 osmo-bts-trx[7356]: <000b> trx_if.c:138 phy0.0: Clock indication: fn=1124031
Nov 22 15:57:40 nuc-osmocom2 osmo-bts-trx[7356]: <000b> trx_if.c:138 phy0.0: Clock indication: fn=1124248
Nov 22 15:57:41 nuc-osmocom2 osmo-bts-trx[7356]: <0000> rsl.c:496 Tx RSL RF RESource INDication
Nov 22 15:57:41 nuc-osmocom2 osmo-bts-trx[7356]: <000b> trx_if.c:138 phy0.0: Clock indication: fn=1124464
Nov 22 15:57:42 nuc-osmocom2 osmo-bts-trx[7356]: <000b> trx_if.c:138 phy0.0: Clock indication: fn=1124681
Nov 22 15:57:42 nuc-osmocom2 osmo-bts-trx[7356]: <0001> oml.c:93 OC=GPRS-CELL INST=(00,00,ff): Sending PCU version report to BSC: 1.3.1.9-26dc.202311212026
Nov 22 15:57:42 nuc-osmocom2 osmo-bsc[648]: <0004> abis_nm.c:352 OC=BTS(01) INST=(00,ff,ff): Reported connected PCU version 1.3.1.9-26dc.202311212026
</pre>
<p>osmo-pcu is not respawning. There are no PDCH configured for this BTS, and "gprs mode none" is in the <code>osmo-bsc.cfg</code></p>
<p>I'm wondering why we keep sending those version reports every 5 seconds to the BSC. They are not needed at all and just spam the logs.</p>
<pre>
root@jma-osmocom2:/etc/osmocom# dpkg -l | grep osmo
ii libosmo-gsup-client0:amd64 1.7.0.5.e513.202311212026 amd64 Osmocom GSUP (General Subscriber Update Protocol) client library
ii libosmo-mgcp-client12:amd64 1.12.1.3.8b663.202311212026 amd64 libosmo-mgcp-client: Osmocom's Media Gateway Control Protocol client utilities
ii libosmo-mslookup1:amd64 1.7.0.5.e513.202311212026 amd64 Osmocom MS lookup library
ii libosmo-ranap7:amd64 1.5.0.1.5484.202311212026 amd64 Osmocom code for the Iuh interface (HNBAP, RUA, RANAP)
ii libosmo-sigtran9:amd64 1.8.0.22.42ed.202311212026 amd64 Osmocom SIGTRAN library (SCCP, SUA, M3UA and more)
ii libosmoabis13:amd64 1.5.0.2.247e.202311212026 amd64 GSM A-bis handling
ii libosmocodec4:amd64 1.9.0.48.459c.202311212026 amd64 Osmo codec library
ii libosmocoding0:amd64 1.9.0.48.459c.202311212026 amd64 Osmo coding library
ii libosmocore 1.9.0.48.459c.202311212026 amd64 Open Source MObile COMmunications CORE library (metapackage)
ii libosmocore21:amd64 1.9.0.48.459c.202311212026 amd64 Osmo Core library
ii libosmoctrl0:amd64 1.9.0.48.459c.202311212026 amd64 Osmo control library
ii libosmogb14:amd64 1.9.0.48.459c.202311212026 amd64 Osmo GPRS GB library
ii libosmogsm20:amd64 1.9.0.48.459c.202311212026 amd64 Osmo GSM utility library
ii libosmoisdn0:amd64 1.9.0.48.459c.202311212026 amd64 Osmo ISDN utility library
ii libosmonetif11:amd64 1.4.0.11.1a5f.202311212026 amd64 Common/shared code regarding network interface for OpenBSC
ii libosmosim2:amd64 1.9.0.48.459c.202311212026 amd64 Osmo SIM library
ii libosmotrau2:amd64 1.5.0.2.247e.202311212026 amd64 GSM trau handling
ii libosmousb0:amd64 1.9.0.48.459c.202311212026 amd64 Osmo USB library
ii libosmovty13:amd64 1.9.0.48.459c.202311212026 amd64 Osmo VTY library
ii osmo-bsc 1.11.0.36.647bc.202311212026 amd64 OsmoBSC: Osmocom's Base Station Controller for 2G circuit-switched mobile networks
ii osmo-bsc-doc 1.11.0.36.647bc.202311212026 all PDF documentation
ii osmo-bsc-ipaccess-utils 1.11.0.36.647bc.202311212026 amd64 Command line utilities for ip.access nanoBTS
ii osmo-bts-doc 1.7.0.39.4a6a.202311212026 all PDF documentation
ii osmo-bts-trx 1.7.0.39.4a6a.202311212026 amd64 osmo-bts-trx GSM BTS with osmo-trx
ii osmo-ggsn 1.10.2.202311212026 amd64 Osmocom Gateway GPRS Support Node (GGSN)
ii osmo-ggsn-doc 1.10.2.202311212026 all PDF documentation
ii osmo-hlr 1.7.0.5.e513.202311212026 amd64 Osmocom Home Location Register
ii osmo-hlr-doc 1.7.0.5.e513.202311212026 all PDF documentation
ii osmo-mgw 1.12.1.3.8b663.202311212026 amd64 OsmoMGW: Osmocom's Media Gateway for 2G and 3G circuit-switched mobile networks
ii osmo-mgw-doc 1.12.1.3.8b663.202311212026 all PDF documentation
ii osmo-msc 1.11.1.5.1759.202311212026 amd64 OsmoMSC: Osmocom's Mobile Switching Center for 2G and 3G circuit-switched mobile networks
ii osmo-msc-doc 1.11.1.5.1759.202311212026 all PDF documentation
ii osmo-pcu 1.3.1.9.26dc.202311212026 amd64 Osmocom GPRS/EDGE Packet Control Unit (PCU)
ii osmo-pcu-doc 1.3.1.9.26dc.202311212026 all PDF documentation
ii osmo-sgsn 1.11.0.1.e746b.202311212026 amd64 OsmoSGSN: Osmocom's Serving GPRS Support Node for 2G and 3G packet-switched mobile networks
ii osmo-sgsn-doc 1.11.0.1.e746b.202311212026 all PDF documentation
ii osmo-stp:amd64 1.8.0.22.42ed.202311212026 amd64 Osmocom SIGTRAN STP (Signaling Transfer Point)
ii osmo-stp-doc 1.8.0.22.42ed.202311212026 all PDF documentation
ii osmo-trx 1.6.0.5.242c.202311212026 all Metapackage for osmo-trx-uhd
ii osmo-trx-doc 1.6.0.5.242c.202311212026 all PDF documentation
ii osmo-trx-lms 1.6.0.5.242c.202311212026 amd64 SDR transceiver that implements Layer 1 of a GSM BTS (LimeSuite)
ii osmo-trx-uhd 1.6.0.5.242c.202311212026 amd64 SDR transceiver that implements Layer 1 of a GSM BTS (UHD)
ii osmocom-nightly 202311212026 amd64 Dummy package, con
</pre> libosmo-sccp + libosmo-sigtran - Bug #6262 (Resolved): use-after-free when io_uring backend is usedhttps://projects.osmocom.org/issues/62622023-11-20T09:19:53Zlaforge
<p>when running the TTCN3 test suite against osmo-stp with the osmo_io_sctp branches of libosmocore/netif/sccp and the io_uring backend enabled, I'm running into the following use-after-free:</p>
<pre>
DLSS7 <000c> osmo_ss7_asp.c:904 XUA_ASP(asp-sender){ASP_DOWN}: Received Event SCTP-COMM_DOWN.ind
DLSS7 <000c> xua_asp_fsm.c:679 XUA_ASP(asp-sender){ASP_DOWN}: state_chg to ASP_DOWN
DLSS7 <000c> xua_asp_fsm.c:360 XUA_AS(as-sender){AS_DOWN}: Received Event ASPAS-ASP_DOWN.ind
DLSS7 <000c> xua_asp_fsm.c:113 0: asp-asp-sender: No Layer Manager, dropping M-ASP_DOWN.indication
DLSS7 <000c> xua_asp_fsm.c:113 0: asp-asp-sender: No Layer Manager, dropping M-SCTP_RELEASE.indication
DLSS7 <000c> osmo_ss7_asp.c:754 0: asp-asp-receiver0: ss7_asp_xua_srv_conn_cb(): sctp_recvmsg() returned 0 (flags=0x80)
DLSS7 <000c> osmo_ss7_asp.c:703 0: asp-asp-receiver0: xUA CLNT SCTP NOTIFICATION 32769 flags=0x0
DLSS7 <000c> osmo_ss7_asp.c:711 0: asp-asp-receiver0: xUA CLNT SCTP_ASSOC_CHANGE: SHUTDOWN_COMP
DLSS7 <000c> osmo_ss7_asp.c:754 0: asp-asp-receiver1: ss7_asp_xua_srv_conn_cb(): sctp_recvmsg() returned 0 (flags=0x80)
DLSS7 <000c> osmo_ss7_asp.c:703 0: asp-asp-receiver1: xUA CLNT SCTP NOTIFICATION 32773 flags=0x0
DLSS7 <000c> osmo_ss7_asp.c:726 0: asp-asp-receiver1: xUA CLNT SHUTDOWN_EVENT
DLSS7 <000c> osmo_ss7_asp.c:898 asp-receiver0: connection closed
DLSS7 <000c> osmo_ss7_asp.c:904 XUA_ASP(asp-receiver0){ASP_DOWN}: Received Event SCTP-COMM_DOWN.ind
DLSS7 <000c> xua_asp_fsm.c:679 XUA_ASP(asp-receiver0){ASP_DOWN}: state_chg to ASP_DOWN
DLSS7 <000c> xua_asp_fsm.c:360 XUA_AS(as-receiver){AS_DOWN}: Received Event ASPAS-ASP_DOWN.ind
DLSS7 <000c> xua_asp_fsm.c:113 0: asp-asp-receiver0: No Layer Manager, dropping M-ASP_DOWN.indication
DLSS7 <000c> xua_asp_fsm.c:113 0: asp-asp-receiver0: No Layer Manager, dropping M-SCTP_RELEASE.indication
DLSS7 <000c> osmo_ss7_asp.c:754 0: asp-asp-receiver1: ss7_asp_xua_srv_conn_cb(): sctp_recvmsg() returned 0 (flags=0x80)
DLSS7 <000c> osmo_ss7_asp.c:703 0: asp-asp-receiver1: xUA CLNT SCTP NOTIFICATION 32769 flags=0x0
DLSS7 <000c> osmo_ss7_asp.c:711 0: asp-asp-receiver1: xUA CLNT SCTP_ASSOC_CHANGE: SHUTDOWN_COMP
DLSS7 <000c> osmo_ss7_asp.c:898 asp-receiver1: connection closed
DLSS7 <000c> osmo_ss7_asp.c:904 XUA_ASP(asp-receiver1){ASP_DOWN}: Received Event SCTP-COMM_DOWN.ind
DLSS7 <000c> xua_asp_fsm.c:679 XUA_ASP(asp-receiver1){ASP_DOWN}: state_chg to ASP_DOWN
DLSS7 <000c> xua_asp_fsm.c:360 XUA_AS(as-receiver){AS_DOWN}: Received Event ASPAS-ASP_DOWN.ind
DLSS7 <000c> xua_asp_fsm.c:113 0: asp-asp-receiver1: No Layer Manager, dropping M-ASP_DOWN.indication
DLSS7 <000c> xua_asp_fsm.c:113 0: asp-asp-receiver1: No Layer Manager, dropping M-SCTP_RELEASE.indication
DLSS7 <000c> osmo_ss7_xua_srv.c:237 (Re)binding ipa Server to :::5000
DLSS7 <000c> osmo_ss7_xua_srv.c:72 (r=::ffff:127.0.0.1:20100<->l=::ffff:127.0.0.1:5000): New ipa connection accepted
DLSS7 <000c> osmo_ss7_xua_srv.c:108 (r=::ffff:127.0.0.1:20100<->l=::ffff:127.0.0.1:5000): ipa connection without matching ASP definition and no dynamic registration enabled, terminating
DLSS7 <000c> osmo_ss7_asp.c:898 ?: connection closed
=================================================================
==3194240==ERROR: AddressSanitizer: heap-use-after-free on address 0x6140000791c0 at pc 0x7fc18926b413 bp 0x7fff489d84f0 sp 0x7fff489d84e8
READ of size 8 at 0x6140000791c0 thread T0
#0 0x7fc18926b412 in iofd_uring_handle_completion (/usr/local/lib/libosmocore.so.21+0x26b412) (BuildId: f5d73d624783a4048f5066f9c5922b925a6aa0bb)
#1 0x7fc18926bc34 in iofd_uring_cqe (/usr/local/lib/libosmocore.so.21+0x26bc34) (BuildId: f5d73d624783a4048f5066f9c5922b925a6aa0bb)
#2 0x7fc189269311 in iofd_uring_poll_cb (/usr/local/lib/libosmocore.so.21+0x269311) (BuildId: f5d73d624783a4048f5066f9c5922b925a6aa0bb)
#3 0x7fc1891fad0d in poll_disp_fds (/usr/local/lib/libosmocore.so.21+0x1fad0d) (BuildId: f5d73d624783a4048f5066f9c5922b925a6aa0bb)
#4 0x7fc1891fae9a in _osmo_select_main (/usr/local/lib/libosmocore.so.21+0x1fae9a) (BuildId: f5d73d624783a4048f5066f9c5922b925a6aa0bb)
#5 0x7fc1891faeb6 in osmo_select_main (/usr/local/lib/libosmocore.so.21+0x1faeb6) (BuildId: f5d73d624783a4048f5066f9c5922b925a6aa0bb)
#6 0x55d1534d0116 in main /space/home/laforge/projects/git/libosmo-sccp/stp/stp_main.c:269
#7 0x7fc188e456c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
#8 0x7fc188e45784 in __libc_start_main_impl ../csu/libc-start.c:360
#9 0x55d1534cf380 in _start (/space/home/laforge/projects/git/libosmo-sccp/stp/.libs/osmo-stp+0x3380) (BuildId: 9b28e0c01de34a9326cb0f0c3f3146a2b134dd3c)
0x6140000791c0 is located 384 bytes inside of 392-byte region [0x614000079040,0x6140000791c8)
freed by thread T0 here:
#0 0x7fc189ed7288 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
#1 0x7fc18a5135b1 in _tc_free_internal ../../talloc.c:1222
#2 0x7fc1895631fe in osmo_stream_srv_destroy (/usr/local/lib/libosmonetif.so.11+0xe31fe) (BuildId: a355aed21f2c416d5f7d2a90ba6d9bc0d1cbd346)
#3 0x7fc1899b8823 in xua_accept_cb (/space/home/laforge/projects/git/libosmo-sccp/src/.libs/libosmo-sigtran.so.9+0x1b8823) (BuildId: c81249073e8805fb9691fe25445dd993fecbeeb9)
#4 0x7fc18955b32e in osmo_stream_srv_link_ofd_cb (/usr/local/lib/libosmonetif.so.11+0xdb32e) (BuildId: a355aed21f2c416d5f7d2a90ba6d9bc0d1cbd346)
#5 0x7fc1891fad0d in poll_disp_fds (/usr/local/lib/libosmocore.so.21+0x1fad0d) (BuildId: f5d73d624783a4048f5066f9c5922b925a6aa0bb)
#6 0x7fc1891fae9a in _osmo_select_main (/usr/local/lib/libosmocore.so.21+0x1fae9a) (BuildId: f5d73d624783a4048f5066f9c5922b925a6aa0bb)
#7 0x7fc1891faeb6 in osmo_select_main (/usr/local/lib/libosmocore.so.21+0x1faeb6) (BuildId: f5d73d624783a4048f5066f9c5922b925a6aa0bb)
#8 0x55d1534d0116 in main /space/home/laforge/projects/git/libosmo-sccp/stp/stp_main.c:269
#9 0x7fc188e456c9 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
previously allocated by thread T0 here:
#0 0x7fc189ed85bf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x7fc18a514df3 in __talloc_with_prefix ../../talloc.c:783
SUMMARY: AddressSanitizer: heap-use-after-free (/usr/local/lib/libosmocore.so.21+0x26b412) (BuildId: f5d73d624783a4048f5066f9c5922b925a6aa0bb) in iofd_uring_handle_completion
Shadow bytes around the buggy address:
0x614000078f00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x614000078f80: fd fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa
0x614000079000: fa fa fa fa fa fa fa fa fd fd fd fd fd fd fd fd
0x614000079080: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
0x614000079100: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
=>0x614000079180: fd fd fd fd fd fd fd fd[fd]fa fa fa fa fa fa fa
0x614000079200: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x614000079280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x614000079300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x614000079380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x614000079400: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==3194240==ABORTING
</pre>
<p>So it looks like we're in a completion handler for something that we already destroyed via osmo_stream_srv_destroy in a xua_accept_cb earlier.</p>
<p>It's to be determined whose fault this is exactly.</p> OsmoGGSN (former OpenGGSN) - Feature #6096 (In Progress): add support for kernel-GTP IPv6https://projects.osmocom.org/issues/60962023-07-12T20:37:17Zlaforge
<p><a class="user active" href="https://projects.osmocom.org/users/21027">pablo</a> has implemented [inner] IPv6 support in the kernel GTP driver and libgtpnl, see <a class="issue tracker-1 status-2 priority-3 priority-high3" title="Bug: IPv6 support for inner (user) IP layer missing (In Progress)" href="https://projects.osmocom.org/issues/1952">#1952</a></p>
<p>In order to end-to-end test it in our TTCN3 test suite (which already tests ipv6 when used with userspace GTP), we would need to add supprot for it to osmo-ggsn</p>
<p>I think <a class="user active" href="https://projects.osmocom.org/users/30187">pespin</a> is currently too busy to look at this, hence assigned to <a class="user active" href="https://projects.osmocom.org/users/301771">osmith</a>, but that's not mandatory. Feel free to pass around as needed.</p> libosmo-abis - Bug #5756 (New): io_uring support in libosmo-abishttps://projects.osmocom.org/issues/57562022-11-09T12:57:42Zlaforge
<p>Once libosmocore provides the new API for the upcoming io_uring backend (<a class="issue tracker-2 status-3 priority-3 priority-high3 closed" title="Feature: io_uring support in libosmocore (Resolved)" href="https://projects.osmocom.org/issues/5751">#5751</a>) we will need to port libosmo-abis over to this new API.</p>
<p>Currently we're using the following code-paths for I/O</p>
<table>
<tr>
<th>libosmo-abis function</th>
<th>I/O function</th>
<th>provided by</th>
</tr>
<tr>
<td>ipa_client_write_default_cb</td>
<td>send</td>
<td>-</td>
</tr>
<tr>
<td>ipa_server_conn_write</td>
<td>send</td>
<td>-</td>
</tr>
<tr>
<td>ipa_client_read</td>
<td>ipa_msg_recv_buffered</td>
<td>libosmocore</td>
</tr>
<tr>
<td>ipa_server_conn_read</td>
<td>ipa_msg_recv_buffered</td>
<td>libosmocore</td>
</tr>
</table>
<p>We need to analyze each of those and migrate, if possible.</p>
<p>There are also the mISDN and DAHDI input drivers, which are currently not seen as performance critical.</p>
<p>Likewise there is RTP support in libosmo-trau which is doing I/O via libortp, which we also consider out of scope for now.</p> OsmoBSC - Feature #5755 (In Progress): io_uring support in osmo-bschttps://projects.osmocom.org/issues/57552022-11-09T12:56:54Zlaforge
<p>Once libosmocore provides the new API for the upcoming io_uring backend (<a class="issue tracker-2 status-3 priority-3 priority-high3 closed" title="Feature: io_uring support in libosmocore (Resolved)" href="https://projects.osmocom.org/issues/5751">#5751</a>) we will need to port osmo-bsc over to this new API.</p>
<p>Some I/O is done directly by osmo-bsc, while other I/O is done via libaries such as libosmo-sigtran, libosmo-netif, libosmo-mgcp-client. There are separate tickets for porting over those libraries. Once that has happened, there might also be API changes for osmo-bsc to catch up with.</p>
<p>Currently we're using the following code-paths for I/O</p>
<table>
<tr>
<th>osmo-bsc function</th>
<th>I/O function</th>
<th>provided by</th>
</tr>
<tr>
<td>bsc_sccplite_mgcp_proxy_cb</td>
<td>recv</td>
<td>-</td>
</tr>
<tr>
<td>bsc_sccplite_rx_mgcp</td>
<td>send</td>
<td>-</td>
</tr>
<tr>
<td>cbsp_srv_cb/cbsp_client_read_cb</td>
<td>osmo_cbsp_recv_buffered</td>
<td>libosmocore</td>
</tr>
<tr>
<td>cbsp_tx_decoded</td>
<td>osmo_stream_{cli,srv}_send</td>
<td>libosmo-netif</td>
</tr>
<tr>
<td>Abis interface</td>
<td>-</td>
<td>libosmo-abis</td>
</tr>
<tr>
<td>A+Lb interface</td>
<td>-</td>
<td>libosmo-sigtran</td>
</tr>
<tr>
<td>VTY interface</td>
<td>-</td>
<td>libosmo-vty</td>
</tr>
<tr>
<td>CTRL interface</td>
<td>-</td>
<td>libosmo-ctrl</td>
</tr>
</table>
<p>We need to analyze each of those and migrate, if possible.</p>
<p>There is also some other I/O like meas_feed, pcu_sock rf_ctrl which are not performance critical and hence can stay like they are and are not further discussed here.</p> OsmoMGW - Feature #5754 (Resolved): io_uring support in libosmo-mgcp-clienthttps://projects.osmocom.org/issues/57542022-11-09T12:48:15Zlaforge
<p>Once libosmocore provides the new API for the upcoming io_uring backend (<a class="issue tracker-2 status-3 priority-3 priority-high3 closed" title="Feature: io_uring support in libosmocore (Resolved)" href="https://projects.osmocom.org/issues/5751">#5751</a>) we will need to port libosmo-mgcp-client over to this new API.</p>
<p>Currently we're using the following code-paths for I/O</p>
<table>
<tr>
<th>libosmo-mgcp-client function</th>
<th>I/O function</th>
<th>provided by</th>
</tr>
<tr>
<td>mgcp_do_write</td>
<td>write</td>
<td>-</td>
</tr>
<tr>
<td>mgcp_do_read</td>
<td>read</td>
<td>-</td>
</tr>
</table>
<p>We need to analyze each of those and migrate, if possible.</p> libosmocore - Feature #5751 (Resolved): io_uring support in libosmocorehttps://projects.osmocom.org/issues/57512022-11-09T12:23:08Zlaforge
<p>Traditionally our I/O abstraction in libosmocore has been <code>select()</code>. In libosmocore 1.5.0 (2020) we migrated over to <code>poll()</code> to support more than 1024 FDs and to avoid the extreme amount of fd-set memcpy()ing involved in the venerable select interface.</p>
<p>Now of course both select and poll are ancient unix interfaces for non-blocking I/O, and both come at a high cost for systems under high load.</p>
<p>Specifically, we are getting reports from osmo-bsc users that indicate a busy BSC with 100 BTS ( 400 TRX)_is spending about 40% of its CPU cycles in the (kernel side) sock_poll, tcp_poll, do_sys_poll.</p>
<p>There are other interfaces such as linux aio, posix aio and epoll, but the brightest and shiniest new I/O interface on Linux is <code>io_uring</code>. Contrary to any of its predecessors, io_uring can, in the "worst" case, operate without any system calls at all anymore. io_uring recognizes that each syscall is associated with a rather high context switch cost.</p>
<p>io_uring consists of memory-mapped (between kernel and userspace process) queues for requests and completions, as well as lockless primitives to enqueue/dequeue from these.</p>
<p>The requests in the queue are requests like <em>read N bytes from this file descriptor</em> or <em>write N bytes to that file descriptor</em>. But io_uring can do much more (many other syscalls), though the read/write is the most relevant part to us.</p>
<p>we already have two io_uring users in the osmocom universe: the GTP and the UDP/RTP load generators I wrote some time ago. They manage their file descriptors internally.</p>
<p>This ticket is now about introducing io_uring support into libosmocore itself, in a way to enable all osmocom programs to use that shared infrastructure.</p>
<a name="Conceptual-differences"></a>
<h2 >Conceptual differences<a href="#Conceptual-differences" class="wiki-anchor">¶</a></h2>
<a name="reading-from-a-socket"></a>
<h3 >reading from a socket<a href="#reading-from-a-socket" class="wiki-anchor">¶</a></h3>
<p>Conceptually, the existing code typically works like this:</p>
<ol>
<li>register some socket file descriptor for read</li>
<li>libosmocore includes it in the poll-set</li>
<li>libosmocore calls poll()</li>
<li>kernel returns from poll, indicating fd is readable</li>
<li>libosmocore dispatches to the application call-back</li>
<li>application allocates msgb, reads data from socket</li>
<li>application processes data in msgb</li>
</ol>
<p>With io_uring, this model needs to change to something like this:</p>
<ol>
<li>application tells us it wants to read from a socket</li>
<li>libosmocore or application pre-allocate the msgb</li>
<li>libosmocore uses liburing to add a read request to the io_uring submission queue</li>
<li>kernel signals us at some point a completion event via io_uring / liburing</li>
<li>libosmocore dispatches pre-filled msgb to application call-back</li>
<li>application processes data n msgb</li>
</ol>
<p>So as we can see, the responsibility for the actual reading transfers from application (or intermediate library like libosmo-netif / libosmo-sigtran) into library.</p>
<a name="writing-to-a-socket"></a>
<h3 >writing to a socket<a href="#writing-to-a-socket" class="wiki-anchor">¶</a></h3>
<p>Conceptually, the existing code typically works like this:</p>
<ol>
<li>register some socket file descriptor for read</li>
<li>libosmocore includes it in the poll-set</li>
<li>libosmocore calls poll()</li>
<li>kernel returns from poll, indicating fd is writeable</li>
<li>libosmocore dispatches to the application call-back</li>
<li>application writes data to msgb and free's msgb.</li>
</ol>
<p>With io_uring, this model needs to change to something like this:</p>
<ol>
<li>application tells us it wants to write to a socket, including the msgb</li>
<li>libosmocore uses liburing to add a write request to the io_uring submission queue</li>
<li>kernel signals us at some point a completion event via io_uring / liburing</li>
<li>libosmocore releases the msgb with msgb_free()</li>
</ol>
<p>Again, the actual reading/writing passes into the library, and outside the scope of the application (or intermediate library like libosmo-netif / libosmo-sigtran)</p> OsmoMSC - Bug #4721 (In Progress): osmo-msc creates evil-twin entries in the VLR when an already ...https://projects.osmocom.org/issues/47212020-08-19T06:24:05Zlaforge
<p>When running this test locally against a (sanitize-enabled) osmo-msc, I get sporadic failures.</p>
<p>The differnence in the log files seems to start:</p>
<p>successful case:<br /><pre>
Wed Aug 19 08:10:24 2020 DVLR <000e> gsm_04_08.c:1394 SUBSCR(IMSI-262420000000013:MSISDN-491230000013:TMSI-0x01020304) VLR: update for IMSI=262420000000013 (MSISDN=491230000013)
</pre></p>
<p>failing case:<br /><pre>
Wed Aug 19 08:10:29 2020 DVLR <000e> gsm_04_08.c:1394 SUBSCR(IMSI-262420000000013:MSISDN-491230000013:TMSI-0x3BEDCD7C) VLR: update for IMSI=262420000000013 (MSISDN=491230000013) (NO CONN!)
</pre></p>
<p>The pcap file containing both cases is attached. They seem exactly identical, it's just that in the first (successful) case, there is a LU ACCEPT immediately, while in the second (failing) case, there is a LU REJECT after timeout of 5s.</p>
<p>I've seen the failure both when running a single test case, as well as when running the entire MSC_Tests.control in one batch.</p> Linux Kernel GTP-U - Bug #1952 (In Progress): IPv6 support for inner (user) IP layer missinghttps://projects.osmocom.org/issues/19522017-02-18T12:29:29Zlaforge
<p>The 3GPP specs permit for both IPv4 and IPv6, but we only implement IPv4. This is embarrassing and should be changed. Contribution welcome!</p>