Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-15T18:45:50ZOpen Source Mobile Communications
Redmine osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6408 (New): osmo-epdg: Support check IMEIhttps://osmocom.org/issues/64082024-03-15T18:45:50Zpespin
<p>We didn't implement anything IMEI related yet, grep for "IMEI" in TS 29.273.</p>
<p>For instance:<br /><pre>
Specific operator policies may be configured for emergency services, regarding whether to check the IMEI and, if the
IMEI needs to be checked, whether to continue or stop the authentication and authorization procedure upon getting the
IMEI check result or when the IMEI(SV) is not available.
</pre></p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Feature #6407 (New): osmo-epdg: Support Emergenc...https://osmocom.org/issues/64072024-03-15T18:43:20Zpespin
<p>Grep for "Emergency" in TS 29.273. We didn't implement any of those yet. We expect an IMSI everywhere.</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> pySim - Bug #6398 (New): Add helper for SwMatchErrorhttps://osmocom.org/issues/63982024-03-09T21:34:47Zn4n5
<p>Hello</p>
<p>Here is a tiny patch to add the error interpreter to SwMatchError()</p>
<p>Btw I have another question :<br />What can we do when we have "Expected 9000 and got 6983: Command not allowed - Authentication/PIN method blocked" ?</p>
<p>Thanks</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6396 (Feedback): add support for auth failu...https://osmocom.org/issues/63962024-03-08T15:41:35Zlynxis
<p>When a phone connects and the sim sequence numbers are out of sync, the authentication will fail<br />and the phone will additional supply Rand and Auts in the failure message.<br />Similar to the 3gpp rat.<br />The sgsn already has a test for this TC_attach_usim_resync.</p>
<p>To reproduce it with a real phone, you could decrease the sequence number in the hss. (AFAIR it is a sliding window, reducing the sequence number by 1 might not be enough).</p>
<pre>
UE - strongswan
<- Auth req
-> Auth failure (reason resync, auts, rand)
(HLR will update the sequence numbers)
<- Auth req
-> Auth succeed.
</pre> 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-1 priority-3 priority-high3" title="Feature: Basic URR (Usage Reporting Rule) support for tunnel mapping (New)" 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 (New): 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 (New): 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> Linux Kernel GTP-U - Bug #6382 (Feedback): "TC_pdp6_act_deact_gtpu_access" fails with kernel gtp-uhttps://osmocom.org/issues/63822024-03-01T17:08:19Zosmith
<p>Pau and I debugged why TC_pdp6_act_deact_gtpu_access does not work with osmo-ggsn with kernel gtp-u. It passes without kernel gtp-u.</p>
<blockquote>
<p>pespin: so I'd say that use case cannot really be performed right now as with current setup, but it's quite a specific one and not sure what would be the best desired behavior</p>
</blockquote>
<blockquote>
<p>pespin: so in summary: a GTP-U/IPv6(src-addr-link-local) arrives to the gtp kernel module (socket fd1u), and it decides the GGSN (userspace) needs to handle the packet, so the packet is pushed/read by osmo-ggsn, which in our current logic decides to forward the packet out of the tun. In order to do that, when we have a non-gtp generic tun, we use the tun FD to inject the decapsulted packet (IPv6(src-addr-link-local) into the network stack.</p>
</blockquote>
<blockquote>
<p>pespin: but when using the gtp tundev kind, we apparently do have the "tun fd" we need to inject decapsulated packets from the userspace program (osmo-ggsn), that only happens through the network stack internally.</p>
</blockquote>
<blockquote>
<p>pespin: So the question would be: 1- Can we somehow obtain an fd for the tun so we can inject decapsulated packets to it like we do in the userspace-gtp scenario? If yes, we should replace fd = -1 with that. If no, then we simply assume we don't want to inject those packets and discard them</p>
</blockquote>
<blockquote>
<p>pespin: feel free to create the ticket or point me to the existing one and I can fill in more info</p>
</blockquote>
<p><a href="#" onclick="$('#collapse-eaa890aa-show, #collapse-eaa890aa-hide').toggle(); $('#collapse-eaa890aa').fadeToggle(150);; return false;" id="collapse-eaa890aa-show" class="icon icon-collapsed collapsible">osmo-ggsn log + dmesg</a><a href="#" onclick="$('#collapse-eaa890aa-show, #collapse-eaa890aa-hide').toggle(); $('#collapse-eaa890aa').fadeToggle(150);; return false;" id="collapse-eaa890aa-hide" class="icon icon-expended collapsible" style="display:none;">osmo-ggsn log + dmesg</a><div id="collapse-eaa890aa" class="collapsed-text" style="display:none;"><pre>
+ osmo-ggsn -c /data/osmo-ggsn.cfg
20240301163326408 DLSTATS INFO Stats timer started with interval 5 sec (stats.c:206)
20240301163326410 DGGSN INFO APN(internet): Starting (ggsn.c:186)
20240301163326411 DGGSN INFO APN(internet): Opening Kernel GTP device tun46 (ggsn.c:204)
20240301163326412 DGGSN NOTICE APN(internet): Skipping APN start (ggsn.c:210)
20240301163326413 DGGSN INFO GGSN(ggsn0): Starting GGSN (ggsn.c:816)
20240301163326414 DLGTP NOTICE GTP: gtp_newgsn() started at 172.18.70.201 (gsn.c:465)
20240301163326416 DLGTP NOTICE State information file (/tmp/gsn_restart) not found. Creating new file. (gsn.c:386)
20240301163326417 DLGLOBAL DEBUG validating counter group 0x7fd8d2ca7b00(gsn) with 18 counters (rate_ctr.c:86)
20240301163326419 DGGSN NOTICE GGSN(ggsn0): Successfully started (ggsn.c:852)
20240301163326420 DGGSN INFO APN(internet): Starting (ggsn.c:186)
20240301163326421 DGGSN INFO APN(internet): Opening Kernel GTP device tun46 (ggsn.c:204)
20240301163326422 DGGSN NOTICE Initialized GTP kernel mode (genl ID is 32) (gtp-kernel.c:79)
[ 0.772102] gtp: enable gtp on 7, 4
[ 0.772475] gtp: enable gtp on 9, 5
[ 0.773067] tun46: registered new GTP interface
20240301163326425 DTUN NOTICE GTP kernel configured (tun.c:217)
[ 0.774548] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0002, skip
20240301163326426 DGGSN INFO APN(internet): Setting tun IP address 176.16.16.0/20 (ggsn.c:230)
20240301163326428 DGGSN INFO APN(internet): Setting tun IPv6 address 2001:780:44:2100::/56 (ggsn.c:242)
20240301163326429 DGGSN INFO APN(internet): Creating IPv4 pool 176.16.16.0/20 (ggsn.c:288)
20240301163326430 DGGSN INFO APN(internet): Blacklist tun IP 176.16.16.0/20 (ggsn.c:167)
20240301163326432 DGGSN INFO APN(internet): Creating IPv6 pool 2001:780:44:2100::/56 (ggsn.c:305)[ 0.781506] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0016, skip
20240301163326434 DGGSN INFO APN(internet): Blacklist tun IP 2001:780:44:2100::/56 (ggsn.c:167)
20240301163326435 DGGSN NOTICE APN(internet): Successfully started (ggsn.c:320)
20240301163326436 DLGLOBAL NOTICE Available via telnet 0.0.0.0 4260 (telnet_interface.c:88)
20240301163326437 DLCTRL NOTICE CTRL at 127.0.0.1 4257 (control_if.c:1014)
[ 1.166137] input: ImExPS/2 Generic Explorer Mouse as /devices/platform/i8042/serio1/input/input3
[ 1.603649] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0016, skip
[ 1.604747] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0002, skip
[ 1.606563] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0016, skip
[ 1.739641] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0016, skip
[ 2.243889] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0016, skip
20240301163328636 DLGLOBAL INFO Accept()ed new telnet connection r=172.18.70.202:37064<->l=172.18.70.201:4260 (telnet_interface.c:192)
20240301163328660 DLGLOBAL NOTICE TTCN3 f_logp(): TC_pdp6_act_deact_gtpu_access() start (logging_vty.c:1165)
20240301163328670 DLGTP DEBUG Begin pdp_tidget tid = e505007495524262 (pdp.c:322)
20240301163328674 DLGTP DEBUG Begin pdp_tidget. Not found (pdp.c:330)
20240301163328678 DLGTP DEBUG Begin pdp_tidset tid = e505007495524262 (pdp.c:277)
20240301163328682 DLGTP DEBUG End pdp_tidset (pdp.c:286)
20240301163328686 DGGSN DEBUG PDP(262425594700505:14): Processing create PDP context request for APN 'inet6' (ggsn.c:441)
20240301163328690 DGGSN DEBUG PDP(262425594700505:14): gtp_kernel_tunnel_add tun46 v1 TEID c88d0b86 EUA=(,2001:780:44:2101::) SGSN=172.18.70.202 (gtp-kernel.c:50)
[ 3.043499] tun46: GTPv1-U: new PDP ctx id=1/c88d0b86 ssgn=172.18.70.202 ms=32.1.7.128 (pdp=(____ptrval____))
20240301163328698 DGGSN INFO SGSN(172.18.70.202): Discovered (sgsn.c:83)
20240301163328700 DGGSN DEBUG PDP(262425594700505:14): PCO Protocol 0x0003 (pco.c:206)
20240301163328704 DGGSN INFO PDP(262425594700505:14): Successful PDP Context Creation: APN=inet6(internet), TEIC=1, IPv4=none, IPv6=2001:780:44:2101:: (ggsn.c:563)
20240301163328710 DLGTP DEBUG Registering seq=62633 in restransmit resp queue (gtp.c:503)
[ 3.065090] tun46: encap_recv sk=(____ptrval____)
[ 3.066495] tun46: received GTP1U packet
[ 3.067603] tun46: No PDP ctx for this MS
[ 3.068730] tun46: pass up to the process
20240301163328721 DGGSN DEBUG PDP(262425594700505:14): Packet received on APN(internet): forwarding to tun tun46 (ggsn.c:675)
[ 3.078465] tun46: encap_recv sk=(____ptrval____)
[ 3.079954] tun46: received GTP1U packet
[ 3.081068] tun46: No PDP ctx for this MS
[ 3.082226] tun46: pass up to the process
[ 3.083371] tun46: encap_recv sk=(____ptrval____)
[ 3.084696] tun46: received GTP1U packet
[ 3.085825] tun46: No PDP ctx for this MS
[ 3.086953] tun46: pass up to the process
20240301163328739 DGGSN DEBUG PDP(262425594700505:14): Packet received on APN(internet): forwarding to tun tun46 (ggsn.c:675)
20240301163328744 DTUN ERROR errno=9/Bad file descriptor TUN(tun46): write() failed (tun.c:324)
20240301163328747 DGGSN DEBUG PDP(262425594700505:14): Packet received on APN(internet): forwarding to tun tun46 (ggsn.c:675)
20240301163328752 DTUN ERROR errno=9/Bad file descriptor TUN(tun46): write() failed (tun.c:324)
[ 5.251918] tun46: no PDP ctx found for ff02:0000:0000:0000:0000:0000:0000:0002, skip
20240301163331735 DLGLOBAL INFO Closing telnet connection r=172.18.70.202:37064<->l=172.18.70.201:4260 (telnet_interface.c:138)
</pre></div></p>
<p>The error happens in <code>lib/tun.c</code>:</p>
<pre><code class="c syntaxhl"><span class="kt">int</span> <span class="nf">tun_encaps</span><span class="p">(</span><span class="k">struct</span> <span class="n">tun_t</span> <span class="o">*</span><span class="n">tun</span><span class="p">,</span> <span class="kt">void</span> <span class="o">*</span><span class="n">pack</span><span class="p">,</span> <span class="kt">unsigned</span> <span class="n">len</span><span class="p">)</span>
<span class="p">{</span>
<span class="kt">int</span> <span class="n">rc</span><span class="p">;</span>
<span class="n">rc</span> <span class="o">=</span> <span class="n">write</span><span class="p">(</span><span class="n">tun</span><span class="o">-></span><span class="n">fd</span><span class="p">,</span> <span class="n">pack</span><span class="p">,</span> <span class="n">len</span><span class="p">);</span>
<span class="k">if</span> <span class="p">(</span><span class="n">rc</span> <span class="o"><</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
<span class="n">SYS_ERR</span><span class="p">(</span><span class="n">DTUN</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="n">errno</span><span class="p">,</span> <span class="s">"TUN(%s): write() failed"</span><span class="p">,</span> <span class="n">tun</span><span class="o">-></span><span class="n">devname</span><span class="p">);</span>
<span class="p">...</span>
</code></pre>
<code>tun->fd</code> is -1 for kernel gtp-u, it gets set in <code>lib/tun.c:tun_new()</code>:
<pre><code class="c syntaxhl"> <span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">use_kernel</span><span class="p">)</span> <span class="p">{</span>
<span class="cm">/* Open the actual tun device */</span>
<span class="k">if</span> <span class="p">(((</span><span class="o">*</span><span class="n">tun</span><span class="p">)</span><span class="o">-></span><span class="n">fd</span> <span class="o">=</span> <span class="n">open</span><span class="p">(</span><span class="s">"/dev/net/tun"</span><span class="p">,</span> <span class="n">O_RDWR</span><span class="p">))</span> <span class="o"><</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
<span class="p">...</span>
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
<span class="n">strncpy</span><span class="p">((</span><span class="o">*</span><span class="n">tun</span><span class="p">)</span><span class="o">-></span><span class="n">devname</span><span class="p">,</span> <span class="n">dev_name</span><span class="p">,</span> <span class="n">IFNAMSIZ</span><span class="p">);</span>
<span class="p">(</span><span class="o">*</span><span class="n">tun</span><span class="p">)</span><span class="o">-></span><span class="n">devname</span><span class="p">[</span><span class="n">IFNAMSIZ</span> <span class="o">-</span> <span class="mi">1</span><span class="p">]</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
<span class="p">(</span><span class="o">*</span><span class="n">tun</span><span class="p">)</span><span class="o">-></span><span class="n">fd</span> <span class="o">=</span> <span class="o">-</span><span class="mi">1</span><span class="p">;</span>
<span class="k">if</span> <span class="p">(</span><span class="n">gtp_kernel_create</span><span class="p">(</span><span class="o">-</span><span class="mi">1</span><span class="p">,</span> <span class="n">dev_name</span><span class="p">,</span> <span class="n">fd0</span><span class="p">,</span> <span class="n">fd1u</span><span class="p">)</span> <span class="o"><</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
</code></pre> 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> OsmoHNBGW - Bug #6380 (New): VTY transcript tests are broken [again]https://osmocom.org/issues/63802024-02-28T18:34:06Zfixeria
<p>The <a href="https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-hnbgw/" class="external">master-osmo-hnbgw</a> Jenkins job is broken since Feb 27th.</p>
<pre>
Error during transcript step 3:
[
OsmoHNBGW# show cs7 config
cs7 instance 0
point-code 0.23.5
asp asp-clnt-msc-0 2905 0 m3ua
local-ip localhost
remote-ip localhost
role asp
sctp-role client
as as-clnt-msc-0 m3ua
asp asp-clnt-msc-0
routing-key 0 0.23.5
]
Error while verifying transcript file './config//defaults.vty'
Traceback (most recent call last):
File "/usr/local/lib/python3.11/dist-packages/osmopython-0.2.1-py3.11.egg/osmopy/osmo_interact/common.py", line 357, in verify_application
interact.verify_transcript_file(transcript_file)
File "/usr/local/lib/python3.11/dist-packages/osmopython-0.2.1-py3.11.egg/osmopy/osmo_interact/common.py", line 111, in verify_transcript_file
result = self.verify_transcript(content)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/dist-packages/osmopython-0.2.1-py3.11.egg/osmopy/osmo_interact/common.py", line 199, in verify_transcript
raise Exception('Result mismatch:\n%s\n\nExpected:\n[\n%s\n]\n\nGot:\n[\n%s\n%s\n]'
Exception: Result mismatch:
Mismatch:
Expect:
' sctp-role client'
Got:
' transport-role client'
Expected:
[
OsmoHNBGW# show cs7 config
cs7 instance 0
point-code 0.23.5
asp asp-clnt-msc-0 2905 0 m3ua
local-ip localhost
remote-ip localhost
role asp
sctp-role client
as as-clnt-msc-0 m3ua
asp asp-clnt-msc-0
routing-key 0 0.23.5
]
Got:
[
OsmoHNBGW# show cs7 config
cs7 instance 0
point-code 0.23.5
asp asp-clnt-msc-0 2905 0 m3ua
local-ip localhost
remote-ip localhost
role asp
transport-role client
as as-clnt-msc-0 m3ua
asp asp-clnt-msc-0
routing-key 0 0.23.5
]
RESULTS:
FAIL: ./config//defaults.vty
</pre>
<p>This is a side effect of my patch that has been merged to libosmo-sccp.git:</p>
<p><a class="external" href="https://cgit.osmocom.org/libosmo-sccp/commit/?id=4d7e20193c264585080b9edc91eb630dd005e396">https://cgit.osmocom.org/libosmo-sccp/commit/?id=4d7e20193c264585080b9edc91eb630dd005e396</a></p>
<pre>
commit 4d7e20193c264585080b9edc91eb630dd005e396
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Thu Feb 15 05:29:14 2024 +0700
VTY: rename 'sctp-role' to 'transport-role', add an alias
</pre> OsmoBSC - Bug #6378 (New): Ericsson DUG 20 rejects SI2quaterhttps://osmocom.org/issues/63782024-02-28T00:28:49Zkeith
<p>Sending SI2quater to the DUG20 results in</p>
<pre>
ERROR REPORT (cause=Radio Resource not available [ 21 01 80 ])
</pre>
<p>For what it may be worth, the SI and the error are in the attached pcap.</p>
<p>Maybe the BTS software version I have simply does not support it?</p> erlang/osmo_ss7 - Bug #6377 (Feedback): ipa: Failure decoding ipa frames split between several tc...https://osmocom.org/issues/63772024-02-27T17:53:18Zpespin
<p>This happens when a lot of IPA concurrent clients send messages and end up in the same TCP packet due to naggle algorithm.<br />When that happens, ipa code in osmo_ss7 fails to decode in osmo-epdg:</p>
<pre>
*DBG* epdg_ue_fsm_262424287925697 receive call {auth_request,33,"internet"} from <0.204.0> in state state_new
*DBG* epdg_ue_fsm_262424287925697 send ok to <0.204.0>
*DBG* gsup_server new state {gsups_state,#Port<0.16>,4222,#Port<0.19>,
{ipa_ccm_options,"EPDG-00-00-00-00-00-00",
"0/0/0","00:00:00:00:00:00","00:00:00:00:00:00",
"00:00:00:00:00:00","00:00:00:00:00:00",
"00:00:00:00:00:00","EPDG-00-00-00-00-00-00",
false},
{set,6,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],
[]},
{{[],[],[],[],
[{gsups_ue,<<"262429242370912">>,<0.240.0>}],
[],
[{gsups_ue,<<"262423473100631">>,<0.243.0>}],
[],[],
[{gsups_ue,<<"262423491582839">>,<0.244.0>}],
[],[],
[{gsups_ue,<<"262424287925697">>,<0.248.0>}],
[{gsups_ue,<<"262426121377808">>,<0.245.0>}],
[{gsups_ue,<<"262426512097609">>,<0.246.0>}],
[]}}}}
*DBG* epdg_ue_fsm_262424287925697 consume call {auth_request,33,"internet"} from <0.204.0> in state state_new => state_wait_auth_res
p
*DBG* gsup_server got {ipa,#Port<0.19>,
{osmo,5},
#{imsi => <<"262425921669062">>,
message_type => send_auth_info_req,
pdp_info_list =>
[#{access_point_name => "internet",
pdp_address =>
#{address => #{},pdp_type_nr => 33,
pdp_type_org => 241},
pdp_context_id => 0}]}}
*DBG* epdg_ue_fsm_262425921669062 enter epdg_ue_fsm in state state_new
17:39:21.043 [error] Error in process <0.222.0> with exit value:
{{badmatch,<<0,32,238,5,8,1,8,98,66,98,68,72,146,87,244,5,18,16,1,0,17,2,241,33,18>>},[{ipa_proto,split_ipa_msg,1,[{file,"/tmp/osmo-
epdg/_build/default/lib/osmo_ss7/src/ipa_proto.erl"},{line,135}]},{ipa_proto,process_rx_ipa_msg,4,[{file,"/tmp/osmo-epdg/_build/defa
ult/lib/osmo_ss7/src/ipa_proto.erl"},{line,182}]},{ipa_proto,loop,3,[{file,"/tmp/osmo-epdg/_build/default/lib/osmo_ss7/src/ipa_proto
.erl"},{line,269}]}]}
</pre> libosmo-abis - Bug #6375 (In Progress): 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> libosmocore - Bug #6374 (New): libosmocore --disable-libsctp not tested by jenkinshttps://osmocom.org/issues/63742024-02-23T15:40:23Zpespin
<p>Right now we are not testing build of libosmocore disabling libsctp support, which means it went broken some time ago and which has recently been fixed by:<br /><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/36055/1">https://gerrit.osmocom.org/c/libosmocore/+/36055/1</a></p>
<pre>
$ ./configure --help | grep sctp
--disable-libsctp Do not enable socket multiaddr APIs requiring
libsctp
--disable-sctp-tests Do not run socket tests requiring system SCTP
</pre>
<p>We should ideally test building with those flags above set in the build matrix of the jenkins job when submitting patches to gerrit (and also probably the master jobs?).</p>
<p>We should ideally test the same when building libosmo-netif and libosmo-sccp (they also have similar configure flags iirc, which in turn relate to --disable-libsctp from libosmocore).</p> OsmocomBB SDR PHY - Bug #6372 (New): Cant connect to BS using cell_log and mobile https://osmocom.org/issues/63722024-02-22T07:13:32Zarrowtem
<p>Hello<br />i managed to run usrp , sib's were succesfully decoded and usrp send RACH to station , but i never can decode reply due to CCCH received bad frame error<br />ubuntu 18.04<br />libosmocomcore 0.11.0<br /><img src="https://osmocom.org/attachments/download/7680/clipboard-202402221012-vtk0a.png" alt="" /><br />uhd 3.10.3<br />gnu radio 3.7.11<br />gr-gsm fixeria/trx branch <br />osmocom bb fixeria/gprs branch</p>
<p>On most new branches i even cant managed to start tranciever , i always had <br /><abbr title="'L' indicates a late packet on transmit">LLLLL</abbr> and usrp_sink error , cmd time error so rach was not sent</p>
<p>Is there are any solution ? maybe i need to checkout to another branches/commits ? i seen in demo you could succesfully camp on cell <br />Btw as a BS i use openbts 2g cell , phones easily camp on it <br />Thank you</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6370 (In Progress): setup ims with kamailiohttps://osmocom.org/issues/63702024-02-20T19:53:27Zlynxis
<p>Setup kamailio as IMS to allow UEs to connect</p>
<p>PLMN: 901 / 70</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> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6366 (New): strongswan: test if gsup_client...https://osmocom.org/issues/63662024-02-17T01:05:48Zlynxis
<p>Can gsup requests pile up, when the gsup connection was dead when the sender tried to send a packet?</p>
<p>I've seen strongswan not always sending out requests after a reconnect situation.<br />As test case, let osmo-epdg crash or ignore a GSUP Send Auth Info Request.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6365 (New): strongswan: get the PDP type ou...https://osmocom.org/issues/63652024-02-17T00:03:41Zlynxis
<p>According to 33.402 / Section 8.2.2</p>
<blockquote>
<p>The UE sends the "Configuration Payload, Sec. associations, Traffic selectors, APN info" in the first IKE_Auth Request.</p>
</blockquote>
<p>Strongswan doesn't care. It only takes the APN and UE Identity from it. But nothing else.</p>
<p>1) Use a real phone to see the request and get the wireshark decode table<br />2) Find out when those information is available to collect it with the strongswan code (osmo-epdg plugin).<br />3) Send the correct type in SendAuthInfo and/or Location Update Request towards the osmo-epdg (erlang)</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6364 (In Progress): strongswan: gsup: remov...https://osmocom.org/issues/63642024-02-16T23:51:54Zlynxis
<p>Currently the strongswan only operates a single request via GSUP.<br />Remove this limitation and allow multiple requests in flight.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6363 (New): strongswan: Catch IKEv2 disconn...https://osmocom.org/issues/63632024-02-16T23:50:23Zlynxis
<p>When the IKEv2 SA got destroy we should<br />- inform osmo-epdg via GSUP (Msg: Purge MS Request)<br />- remove internal state</p>
<p>Use listener api ike_updown() + ike_rekey() to get notified about changes in the SA.<br />The python SWu-IKEv2 doesn't seem good enough to test this. Only ike_rekey() can be tested.</p>
<p>Reducing the timeout of the ike SA might help to provoke the code path.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6361 (Feedback): open5gs-upfd: Fix open5gs ...https://osmocom.org/issues/63612024-02-15T19:50:49Zpespin
<p>From <a class="external" href="https://osmocom.org/issues/6235?issue_count=13&issue_position=5&next_issue_id=6229&prev_issue_id=6289#note-26">https://osmocom.org/issues/6235?issue_count=13&issue_position=5&next_issue_id=6229&prev_issue_id=6289#note-26</a>:</p>
<blockquote>
<p>Also, I had to tweak broken open5gs setup where open5gs-upfd ogtsun gets assigned IP address "10.45.0.1/16", but that IP address is actually also assigned to the first MS (my SWu emulator), and that creates problems in the network stack when the inner packet is decapsulated from GTP. In order to fix it:</p>
<pre>
> root@epc:~# ip addr del 10.45.0.1/16 dev ogstun
> root@epc:~# ip route add 10.45.0.0/24 dev ogstun
> </pre>
<p>According to lynxis this is a problem coming from open5gs package (file /etc/systemd/network/99-open5gs.network). The IP address is set in order to get the routing entry for free. Instead, it should only add the routing entry.</p>
</blockquote>
<p>We should look into fixing the open5gs package to avoid having to apply those changes every time open5gs-upf is restarted.</p>