Open Source Mobile Communications: Issueshttps://osmocom.org/https://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://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://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://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://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://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://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://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://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://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://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://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://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://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://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://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://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://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://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://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://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://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://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> pySim - Feature #6367 (New): PC/SC <-> Android OMAPI bridge for pySim and othershttps://osmocom.org/issues/63672024-02-17T13:34:01Zlaforge
It's a frequent usage pattern that somebody
<ul>
<li>inserts a (sysmocom) USIM/ISIM or even EUICC in their PC/SC card reader, performs some actions with it from the PC (such as changing a file via pySim) and then</li>
<li>inserts it into a phone to test it with the modification, then</li>
<li>restarts the cycle again by removing the card and placing it in the PC/SC reader</li>
</ul>
<p>While working with <a href="https://gitea.angry.im/PeterCxy/OpenEUICC" class="external">EasyEUICC</a> it occurred to me that it has raw APDU-level access via Androids FEATURE_SE_OMAPI_UICC. So it should be possible to write an Android app that acts as a proxy/brige for passing APDUs transparently to between an UICC/eUICC present in the phone and a remote PC running pySim (or any other software that expects a local PC/SC card reader)</p>
<p>In fact, given that the vpcd project alreay has a "APDU over TCP" protocol and has an <a href="https://github.com/frankmorgner/vsmartcard/blob/master/virtualsmartcard/src/ifd-vpcd/ifd-vpcd.c" class="external">ifd_handler exposing virtual card readers to pcscd</a>, only the android side would have to be developed.</p>
<p>So in the end, using the approach above, it shoul be possible to have pySim-shell or other tools talk to the UICC/eUICC while it remains inserted into the phone. After changes were made, we have to see if we can somehow trigger the REFRESH proactive command to tell the baseband to discard its cache and re-read the card contents. Likely a manual "Airplane mode on / off" toggle will also do the trick. But no more inserting/removing the card in between iterations.</p>
<p>Of course the same should in theory be possible also via 03.48 OTA / SCP80 without any Android app. However, OTA works with "APDU scripts" and that's not 1:1 the same as a live connection to the card, where the card doesn't loose state like which file was SELECTed between different OTA commands.</p>
Any ideas/comments on this? I'm not an Android developer, but the task looks reasonably simple to me:
<ul>
<li>access the UICC/eUICC the same way as EasyEUICC</li>
<li>create a TCP connection to a user-configured IP/Port (the ifd-vpcd)</li>
<li>implement the super simple VPCD protocol over TCP to transceive APDUs</li>
</ul> Core testing infrastructure - Feature #6357 (Resolved): run (some?) tests with io_uring backend f...https://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> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6354 (New): investigate UE behavior in ...https://osmocom.org/issues/63542024-02-07T16:10:55Zlaforge
<p>As we've seen in <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: connect a real phone to the epdg to test strongswan ipsec configuration (Closed)" href="https://osmocom.org/issues/6114">#6114</a> it might be interesting to control the eDPG hostname so we can generate a certificate for it (signed by letsencrypt which presumably is trusted by default in unmodified android). It's not critical as EAP-only authentication appeared to be working in the test case there.</p>
<p>It would be good to find some time to test with a couple of different UE whether they actually respect the ePDG related files / configs that can be stored in the USIM/ISIM.</p>
<p>A quick look in TS 31.102 revaled:</p>
<ul>
<li><code>EF.ePDGId</code>
<ul>
<li>contains a TLV-wrapped IPv4, IPv6 or hostname of the ePDG</li>
</ul>
</li>
<li><code>EF.ePDGSelection</code>
<ul>
<li>control the <em>Selection of the ePDG</em> proceduer in the UE (3GPP TS 24.302)</li>
<li>contais a number of (plmn, epdg_priority, epdg_fqdn_indicator)
<ul>
<li>the epdg_fqdn_indicator state whether the <em>Operator Identifier FQDN</em>, or a <em>location based FQDN</em> format shall be used</li>
</ul></li>
</ul></li>
</ul>
<ul>
<li><code>EF.ePDGIdEm</code>
<ul>
<li>same as above, but for emergency calls</li>
</ul>
</li>
<li><code>EF.ePDGSelectionEm</code>
<ul>
<li>same as above, but for emergency calls.</li>
</ul></li>
</ul>
<p>So <code>EF.ePDGId</code> is really the most interesting one.</p> pySim - Bug #6317 (Stalled): data driven tests for TLV decodershttps://osmocom.org/issues/63172023-12-23T15:12:32Zlaforge
<p>While we do have the <code>_test_de_encode</code> data driven tests for file definitions, we don't yet have something similar for derived classes of BER_TLV_IE. This means that TLVs used outside of the filesystem context (for example, decoding the SELECT/STATUS response, but also eUICC and other stuff) do not yet have test coverage.</p> pySim - Feature #6316 (New): include test data in user manualhttps://osmocom.org/issues/63162023-12-23T09:36:16Zlaforge
<p>If you're looking at a SIM that doesn't have meaningful contents in all files,<br />It's sometimes difficult to figure out the JSON syntax that you can use in edit_binary_decoded and the like.</p>
<p>However, we already do have valid per-file JSON as part of the tests (like the <code>_test_de_encode</code> list). So in order to improve the situation, let's try to auto-generate a section of the user manual which contains those examples.</p> pySim - Feature #6315 (New): have test data for all supported fileshttps://osmocom.org/issues/63152023-12-23T09:33:25Zlaforge
<p>We long have the support for <code>_test_de_encode</code> and related class attributes specifiying per-file test data. This is still lacking for a number of files.</p>
<p>For some files it is easy to get real-world data, but for other files (specifically ADF.ISIM related, or mdoern DF.5GS) there simply are no real-world SIMs of production operators that would provide us with test data.</p>
<p>It might be worth looking at the UE/SIM conformance test specs, maybe those can help</p> pySim - Bug #6314 (New): pySim-trace doesn't support ARA-Mhttps://osmocom.org/issues/63142023-12-23T09:31:02Zlaforge
<p>during execution of our pySim-shell test, even with the included pcap we're getting:</p>
<pre>
WARNING pySim.apdu.ts_102_221: SELECT UNKNOWN AID a00000015141434c00
</pre>
<p>the AID is that of the ARA-M applet. We do support ARA-M in pySim-shell. However, we do not appear to use that code from pySim-shell, probably related to the AID auto-detection missing.</p> Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Bug #6291 (New): 2024 event bringing tog...https://osmocom.org/issues/62912023-12-06T14:31:01Zlaforge
<p>I've been considering this for a number of years, but never actually got aroun to acting on it:</p>
<p>Have an event where the various FOSS mobile communications projects meet, get to know each other and exchange status, plans and ideas.</p>
<p>Matthias Kirschner of the FSFE suggested to <em>attach</em> that event to sfscon (<a class="external" href="https://www.sfscon.it/">https://www.sfscon.it/</a>) and do it a few days ahead (or after) the 2024 incarnation, which is likely happning again in November 2024. The FSFE could help with funding of the related expenses from a donation made by sysmocom to FSFE earmarked to help FOSS in mobile communications.</p>
<p>Let's use this issue to collect a list of projects we'd want to invite, and to generally keep track on status.</p>
<p>For now, I am thinking of the following potential projects:</p>
<a name="cellular-infrastructureprotocol-stacks"></a>
<h2 >cellular infrastructure/protocol stacks<a href="#cellular-infrastructureprotocol-stacks" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://osmocom.org/" class="external">Osmocom</a></li>
<li><a href="https://open5gs.org/" class="external">open5gs</a></li>
<li><a href="https://www.srslte.com/" class="external">srsRAN/srsUE</a></li>
<li><a href="https://free5gc.org/" class="external">free5gc</a></li>
<li><a href="https://github.com/edgecomllc/eupf" class="external">eupf</a></li>
<li><a href="https://github.com/travelping/ergw" class="external">ergw</a></li>
<li><a href="https://magmacore.org/" class="external">Magma</a> + <a href="https://github.com/magma/S1APTester" class="external">S1APTester</a></li>
<li><a href="https://github.com/omec-project" class="external">OMEC</a></li>
<li><a href="https://github.com/wmnsk" class="external">wmnsk</a> and his various go-{gtp,pfcp,m3ua,sccp,tcap} projects</li>
</ul>
<a name="SIM-card-related-projects"></a>
<h2 >SIM card related projects<a href="#SIM-card-related-projects" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://github.com/tomasz-lisowski/swsim" class="external">swsim</a> + <a href="https://github.com/tomasz-lisowski/swicc" class="external">swicc</a></li>
</ul>
<a name="Development-Debugging"></a>
<h2 >Development + Debugging<a href="#Development-Debugging" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://github.com/fgsect/scat" class="external">SCAT</a></li>
<li><a href="https://github.com/P1sec/QCSuper" class="external">QCsuper</a></li>
<li><a href="https://github.com/PentHertz/Modmobmap" class="external">Modmobmap</a></li>
<li><a href="https://github.com/SysSec-KAIST/LTESniffer" class="external">LTESniffer</a></li>
<li><a href="https://github.com/falkenber9/falcon" class="external">FALCON</a></li>
<li><a href="https://github.com/aligungr/UERANSIM" class="external">UERANSIM</a></li>
<li><a href="https://github.com/HewlettPackard/PacketRusher" class="external">PacketRusher</a></li>
<li>the various projects by <a href="https://github.com/fasferraz" class="external">fasferraz</a> (Swu-IKEv2, ...)</li>
<li><a href="https://github.com/P1sec/pycrate" class="external">pycrate</a></li>
</ul>
<a name="FOSS-software-stacks-on-mobile-devices"></a>
<h2 >FOSS software stacks on mobile devices<a href="#FOSS-software-stacks-on-mobile-devices" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://postmarketos.org/" class="external">postmarketos</a></li>
<li><a href="https://replicant.us/" class="external">replicant</a></li>
<li><a href="https://ubuntu-touch.io/" class="external">Ubuntu touch</a></li>
</ul>
<p>I'm very happy to accept further suggestions for projects/people to add to the invite list.</p> Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Feature #6290 (In Progress): Organize Os...https://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> pySim - Bug #6288 (Resolved): eUICC support: get_profiles_info only lists one of two profileshttps://osmocom.org/issues/62882023-12-05T23:10:57Zlaforge
<pre>
pySIM-shell (00:MF/ADF.ISD-R)> get_profiles_info
-> 80E2910003 bf2d00
<- 6100:
-> 80c0000000
<- 6100: bf2d82032ba0820327e38202e35a0a980010325476981032144f10a0000005591010ffffffff89000010009f70010191095350204e616d652031921a4f7065726174696f6e616c2050726f66696c65204e616d6520319301019482029089504e470d0a1a0a0000000d49484452000000400000004008040000000060b9550000000774494d4507e00b091007364c956f97000000097048597300000b1200000b1201d2dd7efc0000000467414d410000b18f0bfc61050000021f4944415478daed99cd1583200c803d32000b3004abb00ecbb0822338578af559223f49b0a8175f2ec023e1238410db09a667e5e1e55f80bf00f686060b1e66b80420c02a3255
-> 80c0000000
<- 6100: 0d0e966e8cc6f0128d193460635fa66a3b7d511db48dd94788b655d7815071ba26e61b9000acc711841085eb398d84c0cd94f921ebe2ddab18db6b5005b055c3bc752b4038745c5339449cd4950248100e1d4528fac207b228e3101a4bd4ae52ba96a603808b05d44c27adab2af8807a00a6184b228014807566eca13538e5008ac890bf06be809e4dbebe0b808a842a009ffd7b010436af06b04f034c8d47ea46004703e034e4d95b90a98a447300dc353c9f07a843404d9b2d904bca84f62480a7013c39351431225b722de9f6ad591a0047c194e5ae19bd865afc1a26976f088603c0a7ac9117fce131f64200bcdfed8e290ee058906c46f2fad09dac885a
-> 80c0000000
<- 6130: b1550c68d2a8b426dcf69b8e71f76d195b15cd368207463513fd2dea6648476b2500eb999b6250fa5dc0499e0b88b921f2bbaf782e877588930370724e4d3f0dd01d49dbe7e92cb940423172008f3ed3c6011c03b1396bce6ec24800c703b862682480a20142250b8c05c081385186cd65009607d059dd772b80ae3cb963010205b054436414808abb0ff237752480a996fb3702d8334fda0bf002bc002fc0488053b5f5380005dc0a1703f03ffdfdc433a6fa010cf1ef4165c831e602b40134844c66e67fa4c1000618e5ab8f6008c03faab7028c9117e0036baf44917035af0e0000000049454e44ae426082950100e33e5a0a985822548200107813094f10
-> 80c0000030
<- 9000: a0000005591010ffffffff89000011009f700100910d526564746561204d6f62696c659208526564746561474f950102
{
"profile_info_seq": {
"profile_info": {
"iccid": "98582254820010781309",
"isdp_aid": "a0000005591010ffffffff8900001100",
"profile_state": "disabled",
"service_provider_name": "Redtea Mobile",
"profile_name": "RedteaGO",
"profile_class": "operational"
}
}
}
</pre>
<p>but: <br /><pre>
LIBEUICC_DEBUG_APDU=1 ./lpac profile list | json_pp 74/0/0
[DEBUG] [REQ] CLA: 81, INS: E2, P1: 91, P2: 00, Lc: 03, Data: BF 2D 00
[DEBUG] [RES] SW1: 61, SW2: 00, Data:
[DEBUG] [REQ] CLA: 81, INS: C0, P1: 00, P2: 00, Lc: 00, Data:
[DEBUG] [RES] SW1: 61, SW2: 00, Data: BF 2D 82 03 2B A0 82 03 27 E3 82 02 E3 5A 0A 98 00 10 32 54 76 98 10 32 14 4F 10 A0 00 00 05 59 10 10 FF FF FF FF 89 00 00 10 00 9F 70 01 01 91 09 53 50 20 4E 61 6D 65 20 31 92 1A 4F 70 65 72 61 74 69 6F 6E 61 6C 20 50 72 6F 66 69 6C 65 20 4E 61 6D 65 20 31 93 01 01 94 82 02 90 89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 00 00 00 40 00 00 00 40 08 04 00 00 00 00 60 B9 55 00 00 00 07 74 49 4D 45 07 E0 0B 09 10 07 36 4C 95 6F 97 00 00 00 09 70 48 59 73 00 00 0B 12 00 00 0B 12 01 D2 DD 7E FC 00 00 00 04 67 41 4D 41 00 00 B1 8F 0B FC 61 05 00 00 02 1F 49 44 41 54 78 DA ED 99 CD 15 83 20 0C 80 3D 32 00 0B 30 04 AB B0 0E CB B0 82 23 38 57 8A F5 59 22 3F 49 B0 A8 17 5F 2E C0 23 E1 23 84 10 DB 09 A6 67 E5 E1 E5 5F 80 BF 00 F6 86 06 0B 1E 66 B8 04 20 C0 2A 32 55
[DEBUG] [REQ] CLA: 81, INS: C0, P1: 00, P2: 00, Lc: 00, Data:
[DEBUG] [RES] SW1: 61, SW2: 00, Data: 0D 0E 96 6E 8C C6 F0 12 8D 19 34 60 63 5F A6 6A 3B 7D 51 1D B4 8D D9 47 88 B6 55 D7 81 50 71 BA 26 E6 1B 90 00 AC C7 11 84 10 85 EB 39 8D 84 C0 CD 94 F9 21 EB E2 DD AB 18 DB 6B 50 05 B0 55 C3 BC 75 2B 40 38 74 5C 53 39 44 9C D4 95 02 48 10 0E 1D 45 28 FA C2 07 B2 28 E3 10 1A 4B D4 AE 52 BA 96 A6 03 80 8B 05 D4 4C 27 AD AB 2A F8 80 7A 00 A6 18 4B 22 80 14 80 75 66 EC A1 35 38 E5 00 8A C8 90 BF 06 BE 80 9E 4D BE BE 0B 80 8A 84 2A 00 9F FD 7B 01 04 36 AF 06 B0 4F 03 4C 8D 47 EA 46 00 47 03 E0 34 E4 D9 5B 90 A9 8A 44 73 00 DC 35 3C 9F 07 A8 43 40 4D 9B 2D 90 4B CA 84 F6 24 80 A7 01 3C 39 35 14 31 22 5B 72 2D E9 F6 AD 59 1A 00 47 C1 94 E5 AE 19 BD 86 5A FC 1A 26 97 6F 08 86 03 C0 A7 AC 91 17 FC E1 31 F6 42 00 BC DF ED 8E 29 0E E0 58 90 6C 46 F2 FA D0 9D AC 88 5A
[DEBUG] [REQ] CLA: 81, INS: C0, P1: 00, P2: 00, Lc: 00, Data:
[DEBUG] [RES] SW1: 61, SW2: 30, Data: B1 55 0C 68 D2 A8 B4 26 DC F6 9B 8E 71 F7 6D 19 5B 15 CD 36 82 07 46 35 13 FD 2D EA 66 48 47 6B 25 00 EB 99 9B 62 50 FA 5D C0 49 9E 0B 88 B9 21 F2 BB AF 78 2E 87 75 88 93 03 70 72 4E 4D 3F 0D D0 1D 49 DB E7 E9 2C B9 40 42 31 72 00 8F 3E D3 C6 01 1C 03 B1 39 6B CE 6E C2 48 00 C7 03 B8 62 68 24 80 A2 01 42 25 0B 8C 05 C0 81 38 51 86 CD 65 00 96 07 D0 59 DD 77 2B 80 AE 3C B9 63 01 02 05 B0 54 43 64 14 80 8A BB 0F F2 37 75 24 80 A9 96 FB 37 02 D8 33 4F DA 0B F0 02 BC 00 2F C0 48 80 53 B5 F5 38 00 05 DC 0A 17 03 F0 3F FD FD C4 33 A6 FA 01 0C F1 EF 41 65 C8 31 E6 02 B4 01 34 84 4C 66 E6 7F A4 C1 00 06 18 E5 AB 8F 60 08 C0 3F AA B7 02 8C 91 17 E0 03 6B AF 44 91 70 35 AF 0E 00 00 00 00 49 45 4E 44 AE 42 60 82 95 01 00 E3 3E 5A 0A 98 58 22 54 82 00 10 78 13 09 4F 10
[DEBUG] [REQ] CLA: 81, INS: C0, P1: 00, P2: 00, Lc: 30, Data:
[DEBUG] [RES] SW1: 90, SW2: 00, Data: A0 00 00 05 59 10 10 FF FF FF FF 89 00 00 11 00 9F 70 01 00 91 0D 52 65 64 74 65 61 20 4D 6F 62 69 6C 65 92 08 52 65 64 74 65 61 47 4F 95 01 02
{
"payload" : {
"code" : 0,
"data" : [
{
"iccid" : "89000123456789012341",
"icon" : "iVBORw0KGgoAAAANSUhEUgAAAEAAAABACAQAAAAAYLlVAAAAB3RJTUUH4AsJEAc2TJVvlwAAAAlwSFlzAAALEgAACxIB0t1+/AAAAARnQU1BAACxjwv8YQUAAAIfSURBVHja7ZnNFYMgDIA9MgALMASrsA7LsIIjOFeK9VkiP0mwqBdfLsAj4SOEENsJpmfl4eVfgL8A9oYGCx5muAQgwCoyVQ0Olm6MxvASjRk0YGNfpmo7fVEdtI3ZR4i2VdeBUHG6JuYbkACsxxGEEIXrOY2EwM2U+SHr4t2rGNtrUAWwVcO8dStAOHRcUzlEnNSVAkgQDh1FKPrCB7Io4xAaS9SuUrqWpgOAiwXUTCetqyr4gHoAphhLIoAUgHVm7KE1OOUAisiQvwa+gJ5Nvr4LgIqEKgCf/XsBBDavBrBPA0yNR+pGAEcD4DTk2VuQqYpEcwDcNTyfB6hDQE2bLZBLyoT2JICnATw5NRQxIltyLen2rVkaAEfBlOWuGb2GWvwaJpdvCIYDwKeskRf84TH2QgC83+2OKQ7gWJBsRvL60J2siFqxVQxo0qi0Jtz2m45x920ZWxXNNoIHRjUT/S3qZkhHayUA65mbYlD6XcBJnguIuSHyu694Lod1iJMDcHJOTT8N0B1J2+fpLLlAQjFyAI8+08YBHAOxOWvObsJIAMcDuGJoJICiAUIlC4wFwIE4UYbNZQCWB9BZ3XcrgK48uWMBAgWwVENkFICKuw/yN3UkgKmW+zcC2DNP2gvwArwAL8BIgFO19TgABdwKFwPwP/39xDOm+gEM8e9BZcgx5gK0ATSETGbmf6TBAAYY5auPYAjAP6q3AoyRF+ADa69EkXA1rw4AAAAASUVORK5CYII=",
"iconType" : 1,
"isdpAid" : "A0000005591010FFFFFFFF8900001000",
"profileClass" : 0,
"profileName" : "Operational Profile Name 1",
"profileState" : 1,
"serviceProviderName" : "SP Name 1"
},
{
"iccid" : "89852245280001873190",
"isdpAid" : "A0000005591010FFFFFFFF8900001100",
"profileClass" : 2,
"profileName" : "RedteaGO",
"profileState" : 0,
"serviceProviderName" : "Redtea Mobile"
}
],
"message" : "success"
},
"type" : "lpa"
}
</pre></p> pySim - Bug #6287 (Resolved): response length > 255 bytes not supported / multiple rounds of GET ...https://osmocom.org/issues/62872023-12-04T20:08:18Zlaforge
<p>I'm currently playing with an eUICC and noticing we're only doing one GET_RESPONSE but not multiple rounds:</p>
<pre>
pySIM-shell (00:MF/ADF.ISD-R)> get_profiles_info
-> 80E2910003 bf2d00
<- 6100:
-> 80c0000000
<- 6100: bf2d8202eba08202e7e38202e35a0a980010325476981032144f10a0000005591010ffffffff89000010009f70010191095350204e616d652031921a4f7065726174696f6e616c2050726f66696c65204e616d6520319301019482029089504e470d0a1a0a0000000d49484452000000400000004008040000000060b9550000000774494d4507e00b091007364c956f97000000097048597300000b1200000b1201d2dd7efc0000000467414d410000b18f0bfc61050000021f4944415478daed99cd1583200c803d32000b3004abb00ecbb0822338578af559223f49b0a8175f2ec023e1238410db09a667e5e1e55f80bf00f686060b1e66b80420c02a3255
Traceback (most recent call last):
File "/space/home/laforge/.local/lib/python3.11/site-packages/cmd2/cmd2.py", line 2129, in onecmd_plus_hooks
stop = self.onecmd(statement, add_to_history=add_to_history)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/space/home/laforge/.local/lib/python3.11/site-packages/cmd2/cmd2.py", line 2559, in onecmd
stop = func(statement)
^^^^^^^^^^^^^^^
File "/space/home/laforge/projects/git/pysim/pySim/euicc.py", line 394, in do_get_profiles_info
pi = ADF_ISDR.store_data_tlv(self._cmd.lchan.scc, ProfileInfoListReq(), ProfileInfoListResp)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/space/home/laforge/projects/git/pysim/pySim/euicc.py", line 312, in store_data_tlv
(data, sw) = ADF_ISDR.store_data(scc, b2h(cmd_do_enc))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/space/home/laforge/projects/git/pysim/pySim/euicc.py", line 299, in store_data
return scc._tp.send_apdu_checksw(capdu)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/space/home/laforge/projects/git/pysim/pySim/transport/__init__.py", line 217, in send_apdu_checksw
raise SwMatchError(rv[1], sw.lower(), self.sw_interpreter)
pySim.exceptions.SwMatchError: SW match failed! Expected 9000 and got 6100.
EXCEPTION of type 'SwMatchError' occurred with message: 'SW match failed! Expected 9000 and got 6100.'
</pre>
<p>The card is not responding with 9000 as it <em>still</em> has more data and hence <em>again</em> returns <code>6100</code>. If we manually request that data, it finally succeeds with <code>9000</code><br /><pre>
pySIM-shell (00:MF/ADF.ISD-R)> apdu 80c0000000
-> 80c0000000
<- 61f0: 0d0e966e8cc6f0128d193460635fa66a3b7d511db48dd94788b655d7815071ba26e61b9000acc711841085eb398d84c0cd94f921ebe2ddab18db6b5005b055c3bc752b4038745c5339449cd4950248100e1d4528fac207b228e3101a4bd4ae52ba96a603808b05d44c27adab2af8807a00a6184b228014807566eca13538e5008ac890bf06be809e4dbebe0b808a842a009ffd7b010436af06b04f034c8d47ea46004703e034e4d95b90a98a447300dc353c9f07a843404d9b2d904bca84f62480a7013c39351431225b722de9f6ad591a0047c194e5ae19bd865afc1a26976f088603c0a7ac9117fce131f64200bcdfed8e290ee058906c46f2fad09dac885a
-> 80c00000f0
<- 9000: b1550c68d2a8b426dcf69b8e71f76d195b15cd368207463513fd2dea6648476b2500eb999b6250fa5dc0499e0b88b921f2bbaf782e877588930370724e4d3f0dd01d49dbe7e92cb940423172008f3ed3c6011c03b1396bce6ec24800c703b862682480a20142250b8c05c081385186cd65009607d059dd772b80ae3cb963010205b054436414808abb0ff237752480a996fb3702d8334fda0bf002bc002fc0488053b5f5380005dc0a1703f03ffdfdc433a6fa010cf1ef4165c831e602b40134844c66e67fa4c1000618e5ab8f6008c03faab7028c9117e0036baf44917035af0e0000000049454e44ae426082950100
SW: 9000, RESP: b1550c68d2a8b426dcf69b8e71f76d195b15cd368207463513fd2dea6648476b2500eb999b6250fa5dc0499e0b88b921f2bbaf782e877588930370724e4d3f0dd01d49dbe7e92cb940423172008f3ed3c6011c03b1396bce6ec24800c703b862682480a20142250b8c05c081385186cd65009607d059dd772b80ae3cb963010205b054436414808abb0ff237752480a996fb3702d8334fda0bf002bc002fc0488053b5f5380005dc0a1703f03ffdfdc433a6fa010cf1ef4165c831e602b40134844c66e67fa4c1000618e5ab8f6008c03faab7028c9117e0036baf44917035af0e0000000049454e44ae426082950100
</pre></p>
<p>I think this may not only be constrained to this eUICC example, but in general we should probably keep calling <code>GET RESPONSE</code> as long as <code>6100</code> is returned?</p>