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 - 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> 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> pySim - Bug #6317 (Stalled): data driven tests for TLV decodershttps://projects.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 - Bug #6314 (New): pySim-trace doesn't support ARA-Mhttps://projects.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://projects.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> pySim - Bug #6288 (Resolved): eUICC support: get_profiles_info only lists one of two profileshttps://projects.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://projects.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> OCTOI - Osmocom Community TDM over IP - Bug #6282 (New): high BERT from laforge->divf->manawyrmhttps://projects.osmocom.org/issues/62822023-12-03T16:03:26Zlaforge
<p>When doing a BERT test from laforge via divf to manawyrm, I'm seeing 190..580 bit errors in the 1min test call to 030-65028003. This might be related to my yate upgrade earlier today. However, I'm confident all relevant zapcard patches have previously been merged to master.</p>
<p>Any ideas? Can you have a look, please?</p>
<p>I cannot test the BERT on DIVF directly as the old "call never connects" bug for loopback/wavplay is back: <a class="issue tracker-1 status-1 priority-2 priority-default" title="Bug: divf yate: calls to wave playback or loopback never connect (New)" href="https://projects.osmocom.org/issues/6281">#6281</a></p> OCTOI - Osmocom Community TDM over IP - Bug #6281 (New): divf yate: calls to wave playback or loo...https://projects.osmocom.org/issues/62812023-12-03T16:03:18Zlaforge
<p>I think we've had this problem before, but I don't recall how we worked around it. For sure after my yate upgrade (or the diaplan changes yesterday) we get the following behaviour:</p>
<ul>
<li>loopback doesn't ever answer</li>
<li>wave playback happens at early audio before the call ever connects</li>
</ul>
<p>any ideas?</p> libosmo-netif - Bug #6279 (Resolved): stream_cli fails to connect when using SCTP if no local add...https://projects.osmocom.org/issues/62792023-11-29T21:38:41Zlaforge
<p>In the context of developing osmo_io/io_uring SCTP support, I was trying to build a <em>simple test case</em>, and remembered the stream-server/stream-client programs of libosmo-netif.</p>
<p>Those tools are made for TCP, but one can of course add simple calls to <code>osmo_stream_*_set_proto(foo, IPPROTO_SCTP)</code>. For the server that appears to work, but for the client it doesn't: <code>osmo_stream_cli_open</code> returns -22/EINVAL.</p>
<p>I've tracked this down to the difference in setting up the socket:<code>osmo_sock_init2_multiaddr2</code> (SCTP) vs <code>osmo_sock_init2</code> (TCP).</p>
<p>It seems that the multiaddr variant fails with -EINVAL if the <code>BIND</code> flag is set and no single local address is given, while the regular variant <code>osmo_sock_init2</code> succeeds. Is this an intentional difference?</p>
<p>I would expect the BIND flag to behave like usual if no local address is provided: Bind to INADDR_ANY/IN6ADDR_ANY.</p>
<p>Slightly unrlated: One could also argue why does libosmo-netif stream client set the BIND flag if it doesn't really want to bind to a non-specific address? Well, it could want to bind to a specific local port.</p> OCTOI - Osmocom Community TDM over IP - Bug #6274 (New): yate is eating 260% CPU while doing nothinghttps://projects.osmocom.org/issues/62742023-11-25T14:31:20Zlaforge
<p>Something seems wrong if an idle yate doing nothing consumes about 260% CPU.</p>
<p>Looking at the yate threads, we can see that each <code>Zap Worker</code> consumes 10..12% of CPU while doing nothing:<br /><img src="https://projects.osmocom.org/attachments/download/7154/yate-cpu.png" alt="" /></p>
<p>This is quite weird, especially considering that osmo-e1d with 23 trunkdevs in parallel only uses 20% CPU - while actually processing packets/frames for all of those trunks.</p>
<p>a strace of such a single Zap Worker thread looks like this:<br /><pre>
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
</pre></p>
<p>So basically we're using select to check if data on a single FD has arrived, time-out after 100 microseconds and then call a zero-nanoseconds sleep and start all-over again.</p>
<p>Looking at the source code, this looks like extremely poor programming style:<br /><pre><code class="c++ syntaxhl"><span class="c1">// Process incoming data</span>
<span class="kt">bool</span> <span class="n">ZapInterface</span><span class="o">::</span><span class="n">process</span><span class="p">()</span>
<span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">m_device</span><span class="p">.</span><span class="n">select</span><span class="p">(</span><span class="mi">100</span><span class="p">))</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">m_device</span><span class="p">.</span><span class="n">canRead</span><span class="p">())</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">m_device</span><span class="p">.</span><span class="n">event</span><span class="p">())</span>
<span class="n">checkEvents</span><span class="p">();</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="p">}</span>
<span class="kt">int</span> <span class="n">r</span> <span class="o">=</span> <span class="n">m_device</span><span class="p">.</span><span class="n">recv</span><span class="p">(</span><span class="n">m_buffer</span><span class="p">,</span><span class="n">m_bufsize</span> <span class="o">+</span> <span class="n">ZAP_CRC_LEN</span><span class="p">);</span>
<span class="k">if</span> <span class="p">(</span><span class="n">r</span> <span class="o">==</span> <span class="o">-</span><span class="mi">1</span><span class="p">)</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">m_device</span><span class="p">.</span><span class="n">event</span><span class="p">())</span>
<span class="n">checkEvents</span><span class="p">();</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="p">}</span>
<span class="k">if</span> <span class="p">(</span><span class="n">r</span> <span class="o">&</span><span class="n">lt</span><span class="p">;</span> <span class="n">ZAP_CRC_LEN</span> <span class="o">+</span> <span class="mi">1</span><span class="p">)</span> <span class="p">{</span>
<span class="n">Debug</span><span class="p">(</span><span class="k">this</span><span class="p">,</span><span class="n">DebugMild</span><span class="p">,</span><span class="s">"Short read %u bytes (with CRC) [%p]"</span><span class="p">,</span><span class="n">r</span><span class="p">,</span><span class="k">this</span><span class="p">);</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="p">}</span>
<span class="n">s_ifaceNotifyMutex</span><span class="p">.</span><span class="n">lock</span><span class="p">();</span>
<span class="n">m_notify</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
<span class="n">s_ifaceNotifyMutex</span><span class="p">.</span><span class="n">unlock</span><span class="p">();</span>
<span class="n">DataBlock</span> <span class="n">packet</span><span class="p">(</span><span class="n">m_buffer</span><span class="p">,</span><span class="n">r</span> <span class="o">-</span> <span class="n">ZAP_CRC_LEN</span><span class="p">,</span><span class="nb">false</span><span class="p">);</span>
<span class="cp">#ifdef XDEBUG
</span> <span class="n">String</span> <span class="n">hex</span><span class="p">;</span>
<span class="n">hex</span><span class="p">.</span><span class="n">hexify</span><span class="p">(</span><span class="n">packet</span><span class="p">.</span><span class="n">data</span><span class="p">(),</span><span class="n">packet</span><span class="p">.</span><span class="n">length</span><span class="p">(),</span><span class="sc">' '</span><span class="p">);</span>
<span class="n">Debug</span><span class="p">(</span><span class="k">this</span><span class="p">,</span><span class="n">DebugAll</span><span class="p">,</span><span class="s">"Received data: %s [%p]"</span><span class="p">,</span><span class="n">hex</span><span class="p">.</span><span class="n">safe</span><span class="p">(),</span><span class="k">this</span><span class="p">);</span>
<span class="cp">#endif
</span> <span class="n">receivedPacket</span><span class="p">(</span><span class="n">packet</span><span class="p">);</span>
<span class="n">packet</span><span class="p">.</span><span class="n">clear</span><span class="p">(</span><span class="nb">false</span><span class="p">);</span>
<span class="k">return</span> <span class="nb">true</span><span class="p">;</span>
<span class="p">}</span>
<span class="kt">void</span> <span class="n">ZapWorkerThread</span><span class="o">::</span><span class="n">run</span><span class="p">()</span>
<span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">m_client</span><span class="p">)</span>
<span class="k">return</span><span class="p">;</span>
<span class="n">DDebug</span><span class="p">(</span><span class="o">&</span><span class="n">plugin</span><span class="p">,</span><span class="n">DebugAll</span><span class="p">,</span><span class="s">"%s is running for client (%p): %s"</span><span class="p">,</span>
<span class="n">s_threadName</span><span class="p">,</span><span class="n">m_client</span><span class="p">,</span><span class="n">m_address</span><span class="p">.</span><span class="n">c_str</span><span class="p">());</span>
<span class="k">while</span> <span class="p">(</span><span class="nb">true</span><span class="p">)</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">m_client</span><span class="o">-&</span><span class="n">gt</span><span class="p">;</span><span class="n">process</span><span class="p">())</span>
<span class="n">Thread</span><span class="o">::</span><span class="n">check</span><span class="p">(</span><span class="nb">true</span><span class="p">);</span>
<span class="k">else</span>
<span class="n">Thread</span><span class="o">::</span><span class="n">yield</span><span class="p">(</span><span class="nb">true</span><span class="p">);</span>
<span class="p">}</span>
<span class="p">}</span>
</pre></p>
<p>So basically the thread is continuously calling Thread:yield rather than waiting on some actual I/O to happen.</p></code></pre> Cellular Network Infrastructure - Bug #6272 (Resolved): default config files have different log f...https://projects.osmocom.org/issues/62722023-11-24T09:36:34Zlaforge
<p>if one installs osmo-* nightly packages from the feed, one will have various different programs which all log to stderr (which in turn ends up in the journal. That's all good, but what is weird is that those programs come with different log format configurations.</p>
<p>Please let's unify the example config files of all our (dpkg packaged) programs to reflect the same.</p>
<p>I suggest something like this:<br /><pre>
logging color 1
logging print category-hex 0
logging print category 1
logging timestamp 0
logging print file basename last
</pre></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> OsmoTRX - Bug #6269 (Resolved): osmo-trx-uhd fails to start on Debian 12 systemhttps://projects.osmocom.org/issues/62692023-11-22T14:18:25Zlaforge
<p>I'm currently setting up an osmocom system using the nightly feed for Debian 12 (on what I assume to be a clean Debian 12).</p>
<p>However, the osmo-trx-uhd.service is not starting up:<br /><pre>
Nov 22 15:15:10 nuc-osmocom2 systemd[1]: Started osmo-trx-uhd.service - Osmocom SDR BTS L1 Transceiver (UHD Backend).
Nov 22 15:15:10 nuc-osmocom2 osmo-trx-uhd[3503]: Wed Nov 22 15:15:10 2023 DLGLOBAL <0008> cpu_sched_vty.c:471 Setting SCHED_RR priority 18
Nov 22 15:15:10 nuc-osmocom2 osmo-trx-uhd[3503]: Wed Nov 22 15:15:10 2023 DLGLOBAL <0008> telnet_interface.c:88 Available via telnet 127.0.0.1 4237
Nov 22 15:15:10 nuc-osmocom2 osmo-trx-uhd[3503]: Wed Nov 22 15:15:10 2023 DLCTRL <000f> control_if.c:1014 CTRL at 127.0.0.1 4236
Nov 22 15:15:10 nuc-osmocom2 osmo-trx-uhd[3503]: [INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_107400; UHD_4.3.0.0+ds1-5
Nov 22 15:15:12 nuc-osmocom2 osmo-trx-uhd[3503]: Wed Nov 22 15:15:12 2023 DDEV <0005> UHDDevice.cpp:525 UHD make failed, device , exception:
Nov 22 15:15:12 nuc-osmocom2 osmo-trx-uhd[3503]: RuntimeError: get_xdg_config_home(): Unable to find $HOME or $XDG_CONFIG_HOME.
Nov 22 15:15:12 nuc-osmocom2 osmo-trx-uhd[3503]: Wed Nov 22 15:15:12 2023 DMAIN <0000> osmo-trx.cpp:607 Failed to create radio device
Nov 22 15:15:12 nuc-osmocom2 osmo-trx-uhd[3503]: Wed Nov 22 15:15:12 2023 DMAIN <0000> osmo-trx.cpp:588 Shutting down transceiver...
Nov 22 15:15:12 nuc-osmocom2 systemd[1]: osmo-trx-uhd.service: Main process exited, code=exited, status=1/FAILURE
Nov 22 15:15:12 nuc-osmocom2 systemd[1]: osmo-trx-uhd.service: Failed with result 'exit-code'.
</pre></p>
<p>I'm very puzzled. Does this really mean that UHD expects HOME or XDG_CONFIG_HOME environment variables being present? Have they ever considered that this is not usual for any program not started by an user at an interactive console? And why on earth would something minor like that result in a fatal failure?</p>
<p>Does anyone know anything about this?</p> libosmocore - Bug #6264 (Resolved): osmo_iofd_write_msgb unconditionally dereferences io_ops.writ...https://projects.osmocom.org/issues/62642023-11-20T13:01:06Zlaforge
<pre>
int osmo_iofd_write_msgb(struct osmo_io_fd *iofd, struct msgb *msg)
{
int rc;
if (OSMO_UNLIKELY(!iofd->io_ops.write_cb)) {
LOGPIO(iofd, LOGL_ERROR, "write_cb not set, Rejecting msgb\n");
return -EINVAL;
}
</pre>
<p>Unlike the sendto variant, there's no OSMO_ASSERT for the correct mode...</p>
<pre>
int osmo_iofd_sendto_msgb(struct osmo_io_fd *iofd, struct msgb *msg, int sendto_flags, const struct osmo_sockaddr *dest)
{
int rc;
OSMO_ASSERT(iofd->mode == OSMO_IO_FD_MODE_RECVFROM_SENDTO);
if (OSMO_UNLIKELY(!iofd->io_ops.sendto_cb)) {
LOGPIO(iofd, LOGL_ERROR, "sendto_cb not set, Rejecting msgb\n");
return -EINVAL;
}
</pre> libosmocore - Bug #6263 (In Progress): impossible to detect wrong callbacks being registered / o...https://projects.osmocom.org/issues/62632023-11-20T12:15:03Zlaforge
<p>As I just had to learn the hard way, it's possible to create an osmo_io_fd using osmo_iofd_setup in one mode (e.g. OSMO_IO_FD_MODE_READ_WRITE) but the register an osmo_io_ops with wrong call-backs (e.g. recvfrom/sendto). Given that it's a union, there's nothing we can do at runtime to detect such an error and ASSERT or the like.</p>
<p>We'd either have to break ABI by introducing a "enum osmo_io_fd_mode" member in the struct, or we'd have to expand all those unions into a struct. This way we can see which function pointers are NULL and non-NULL and hence determine if the right call-backs for the given mode were set.</p>
<p>Any ideas/comments?</p> 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> Core testing infrastructure - Bug #6261 (Resolved): jenkins warnings regarding undefined parametershttps://projects.osmocom.org/issues/62612023-11-19T11:06:33Zlaforge
<p>Our jenkins logs get spammed with:<br /><pre>
jenkins_1 | 2023-11-19 11:04:40.928+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_HOST` as it is undefined on `gerrit-osmo-e1d-build` (#74). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.928+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_PATCHSET_NUMBER` as it is undefined on `gerrit-osmo-e1d-build` (#74). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.928+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_PATCHSET_REVISION` as it is undefined on `gerrit-osmo-e1d-build` (#74). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.928+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_PATCHSET_UPLOADER_NAME` as it is undefined on `gerrit-osmo-e1d-build` (#74). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.928+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_PORT` as it is undefined on `gerrit-osmo-e1d-build` (#74). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.928+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_PROJECT` as it is undefined on `gerrit-osmo-e1d-build` (#74). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.928+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_REPO_URL` as it is undefined on `gerrit-osmo-e1d-build` (#74). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.928+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `PIPELINE_BUILD_URL` as it is undefined on `gerrit-osmo-e1d-build` (#74). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.928+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `PROJECT_NAME` as it is undefined on `gerrit-osmo-e1d-build` (#74). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.959+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `COMMENT_TYPE` as it is undefined on `gerrit-osmo-e1d-build` (#73). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.959+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `DISTRO` as it is undefined on `gerrit-osmo-e1d-build` (#73). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.959+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_CHANGE_NUMBER` as it is undefined on `gerrit-osmo-e1d-build` (#73). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.959+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_HOST` as it is undefined on `gerrit-osmo-e1d-build` (#73). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.959+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_PATCHSET_NUMBER` as it is undefined on `gerrit-osmo-e1d-build` (#73). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.959+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_PATCHSET_REVISION` as it is undefined on `gerrit-osmo-e1d-build` (#73). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.959+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_PATCHSET_UPLOADER_NAME` as it is undefined on `gerrit-osmo-e1d-build` (#73). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.959+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_PORT` as it is undefined on `gerrit-osmo-e1d-build` (#73). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.959+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_PROJECT` as it is undefined on `gerrit-osmo-e1d-build` (#73). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.959+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `GERRIT_REPO_URL` as it is undefined on `gerrit-osmo-e1d-build` (#73). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.959+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `PIPELINE_BUILD_URL` as it is undefined on `gerrit-osmo-e1d-build` (#73). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
jenkins_1 | 2023-11-19 11:04:40.959+0000 [id=586] WARNING hudson.model.ParametersAction#filter: Skipped parameter `PROJECT_NAME` as it is undefined on `gerrit-osmo-e1d-build` (#73). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.
</pre></p>
<p>Would be good to try to avoid all those warnings... We already have more than 17000 of those within the last 12 hours, so probably around 34k each day.</p> OsmoBSC - Bug #6256 (Resolved): osmo-bsc running out of file descriptors in production setupshttps://projects.osmocom.org/issues/62562023-11-11T20:53:09Zlaforge
<p>We have a production setup where there are >= 200 BTs with each up to 4 TRX. In that setup, the OS default number of open file descriptors (1024) is hit, resulting in call drops.</p>
<p>Given that there is N+1 sockets for each N-TRX BTS (e.g. 5 for a 4TRX) plus a handful for the AoIP interface, for speaking MGCP to the MGW, CTRL/VTY, etc. it is thus completely reasonable to exceed 1024.</p>
Now the 1024 is not a limit imposed by osmo-bsc. However, we might want to either
<ul>
<li>add a note to the user manual informing users that they should tune their system accordingly if they expect a high number of BTSs, and/or</li>
<li>consider tuning the limit for osmo-bsc using <code>LimitNOFILE</code> in the systemd unit we're shipping.</li>
</ul>
We might also want to look at other osmo-* programs that might encounter similar problems. AFAICT it's probably only
<ul>
<li>osmo-hnbgw (only one Iuh socket for each HNB, though)</li>
<li>osmo-mgw (2 sockets per endpoint (RTP+RTCP), resulting in 4 sockets for each call, but single-threaded mgw might not handle 256 calls anyway?</li>
<li>osmo-gbproxy (number of sockets depends on number of NS-VCs configured. But at least common setups probably only have few UDP sockets. Unlike TCP/SCTP, we don't need new sockets for each peer/connection). So probably not required</li>
<li>bts, trx, msc, hlr, sgsn, ggsn all have only a low number of sockets, from what I can tell.</li>
</ul> libosmo-sccp + libosmo-sigtran - Bug #6240 (Feedback): libosmo-sigtran doesn't reject M3UA with "...https://projects.osmocom.org/issues/62402023-10-31T14:56:25Zlaforge
<p>libosmo-sigtran has no support for "M3UA Network Appearance". Right now this means that peers using this optional M3UA IE will be able to send us such messages, the IE will be ignored and answers will be sent without that IE present (which the recipient likely cannot process properly).</p>
<p>I think the clean way would be to print error messages if we ever receive such messages, and send related error messages back to the sender. This way it becomes obvious in both log files and protocol traces that there is an incompatible feature at play.</p> osmo-e1-recorder - Bug #6228 (Resolved): osmo-e1-recorder release tarballs missing from https://f...https://projects.osmocom.org/issues/62282023-10-18T17:11:58Zlaforge
<p><a class="external" href="https://gitea.osmocom.org/cellular-infrastructure/osmo-e1-recorder/tags">https://gitea.osmocom.org/cellular-infrastructure/osmo-e1-recorder/tags</a></p> Cellular Network Infrastructure - Bug #6227 (Resolved): gapk release tarballs missing from https:...https://projects.osmocom.org/issues/62272023-10-18T17:10:16Zlaforge
<p><a class="external" href="https://gitea.osmocom.org/osmocom/gapk/tags">https://gitea.osmocom.org/osmocom/gapk/tags</a></p>