Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-26T11:40:28ZOpen Source Mobile Communications
Redmine OsmoGGSN (former OpenGGSN) - Bug #6420 (New): osmo-ggsn + pre-configured tun device seems to be b...https://osmocom.org/issues/64202024-03-26T11:40:28Zosmith
<p>When using a pre-configured tun device with OsmoGGSN as described in the user manual, in combination with <code>gtpu-mode kernel-gtp</code>, osmo-ggsn fails to configure the kernel GTP device:</p>
<pre>
<0002> ggsn.c:210 APN(internet): Skipping APN start
<000d> gsn.c:465 GTP: gtp_newgsn() started at 10.23.24.2
<000d> gsn.c:386 State information file (/tmp/gsn_restart) not found. Creating new file.
<0002> ggsn.c:854 GGSN(ggsn0): Successfully started
<0002> gtp-kernel.c:79 Initialized GTP kernel mode (genl ID is 34)
<0001> tun.c:213 cannot create GTP tunnel device: File exists
<0002> ggsn.c:215 APN(internet): Failed to configure Kernel GTP device
</pre> OsmoGGSN (former OpenGGSN) - Bug #6419 (New): osmo-ggsn removes tun devices it did not createhttps://osmocom.org/issues/64192024-03-26T11:26:04Zosmith
<p>From the <a href="https://ftp.osmocom.org/docs/osmo-ggsn/master/osmoggsn-usermanual.pdf" class="external">user manual</a>:</p>
<blockquote>
<p>It’s possible to run OsmoGGSN without root privileges if the tun devices are already configured.<br />The interface creation + configuration must then happen before osmo-ggsn starting up.<br />[...]<br />With the tun device pre-configured in one of the ways outlined above, the main changes in your osmo-ggsn.cfg file are:<br />• remove ip ifconfig directive,<br />• make sure that no shutdown is present in the apn section as well as no shutdown ggsn in the ggsn section.</p>
</blockquote>
<p>With this configuration, a tun device created by <code>/etc/network/interfaces</code> will be removed when osmo-ggsn shuts down and <code>ifup -f apn0</code> must be used to recreate it, before starting osmo-ggsn again.</p> pySim - Bug #6418 (New): osmo-smdpp docshttps://osmocom.org/issues/64182024-03-25T17:54:30Zlavy
<p>In these docs: <a class="external" href="https://ftp.osmocom.org/docs/pysim/master/html/osmo-smdpp.html">https://ftp.osmocom.org/docs/pysim/master/html/osmo-smdpp.html</a></p>
<p><img src="https://osmocom.org/attachments/download/8141/clipboard-202403251046-awlff.png" alt="" /></p>
<p>It says osmo-smdpp is absolutely insecure as it does not perform any certificate verification, does not consider matching ID or Confirmation Code, ...</p>
<p>I'm slightly confused by this. By no certificate verification, does it mean that it doesn't check if the root certificate of the eUICC is the same as the SM-DP+ server? Also for not considering matching ID, I had to make it the name of a profile package in the upp folder for it to work. If I did something like 1234 (like you did in the osmodevcall), it doesn't work. I debugged and found it was throwing an error if the matching ID was not a file in the upp folder. Do these docs need an update? I'd be happy to do that if that's the case.</p> E1/T1 Hardware Interface (including icE1usb) - Feature #6417 (New): CRC4 configurationhttps://osmocom.org/issues/64172024-03-22T18:01:37Zpfassberg
<p>Even if the icE1usb support CRC4 enabled or disabled the osmo-e1d process need CRC4 on Rx to align.</p>
<p>I suggest that we do CRC4 check configurable.</p>
<p>On a Cisco modem pool you can disable CRC4 in the E1 controller section:<br /><pre>
controller E1 2/1
framing NO-CRC4
pri-group timeslots 1-31
description Towards Kanin-Q921_4
</pre></p>
<p>Maybe we can do the same in the line section in the config file, something like this:<br /><pre>
e1d
interface 0 icE1usb
usb-serial xxxxxxxxxxxx
line 0
framing no-crc4
mode e1oip
</pre></p>
<p>// Peter</p> Cellular Network Infrastructure - Bug #6411 (New): ttcn3: execute testsuites with a more realisti...https://osmocom.org/issues/64112024-03-20T14:24:47Zfixeria
<p>This idea by <a class="user active" href="https://osmocom.org/users/7">laforge</a> originates from <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: default TCP user timeout is way too low (Resolved)" href="https://osmocom.org/issues/6375">#6375</a>: we should try running at least some of our BTS / BSC tests over an Abis link with simulated latency and non-zero packet loss. I did some experiments using tc-netem, running the whole ttcn3-bts-test with a simulated delay: <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: default TCP user timeout is way too low (Resolved)" href="https://osmocom.org/issues/6375#note-14">#6375#note-14</a>. Let's continue discussing this here.</p> libosmocore - Bug #6410 (New): osmo_io poll backend doesn't work on file descriptors that are not...https://osmocom.org/issues/64102024-03-19T19:33:49Zlaforge
<p>I just wanted to use osmo_io on a file descriptor pointing to an actual file, not a socket.</p>
<p>The poll backend fails as it unconditionally tries to use sendmsg, even if the mode is READ_WRITE.</p> 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> OsmoHNBGW - Feature #6395 (New): PFCP URR support in osmo-hnbgwhttps://osmocom.org/issues/63952024-03-08T13:38:17Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to use PFCP URR to instruct the UPF to:
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p>The osmo-hnbgw side then will have to report those packet/byte counters [at the very least] as per-hnb aggregate figures.</p>
<p>Until osmo-upf has the related features (<a class="issue tracker-2 status-7 priority-1 priority-lowest" title="Feature: Basic URR (Usage Reporting Rule) support for tunnel mapping (Stalled)" href="https://osmocom.org/issues/6394">#6394</a>), testing of the osmo-hnbgw side can be done against open5gs-upf, which should already suport it since <a class="user active" href="https://osmocom.org/users/30187">pespin</a> taught it URR support in April 2022.</p> OsmoUPF - Feature #6394 (Stalled): Basic URR (Usage Reporting Rule) support for tunnel mappinghttps://osmocom.org/issues/63942024-03-08T13:33:39Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p><a class="user active" href="https://osmocom.org/users/30187">pespin</a> had implemented something like this for open5gs-upf in<br /><pre>commit fb8ebcdbeae0648e30d04fd016a956642131dddd
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date: Fri Apr 8 16:10:42 2022 +0200
[UPF] Add initial support for URR Usage Report (#1476)
</pre><br />and following commits.</p>
<p>Now sadly, open5gs-upf is more like a lab-grade upf and nothing that scales at all, and we hence have users of osmo-upf that use it for its fast kernel path.</p>
<p>The primary goal for this feature is the <em>tunnel mapping</em> case in a osmo-hnbgw co-located osmo-upf. The packet and byte counters hence will have to be added to the nftables rules.</p> libosmocore - 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> 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-41871ec2-show, #collapse-41871ec2-hide').toggle(); $('#collapse-41871ec2').fadeToggle(150);; return false;" id="collapse-41871ec2-show" class="icon icon-collapsed collapsible">osmo-ggsn log + dmesg</a><a href="#" onclick="$('#collapse-41871ec2-show, #collapse-41871ec2-hide').toggle(); $('#collapse-41871ec2').fadeToggle(150);; return false;" id="collapse-41871ec2-hide" class="icon icon-expended collapsible" style="display:none;">osmo-ggsn log + dmesg</a><div id="collapse-41871ec2" 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> 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> 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> OsmoGGSN (former OpenGGSN) - Bug #6106 (New): OsmoGGSN attempts to use the same GTP-U socket for ...https://osmocom.org/issues/61062023-07-21T10:50:09Zosmith
<p>Currently it is not possible to configure multiple APNs with gtpu-mode kernel-gtp in OsmoGGSN. When attempting to do so:</p>
<pre>
tun.c:213 cannot create GTP tunnel device: Device or resource busy
</pre>
<p>laforge wrote in <a class="external" href="https://osmocom.org/issues/6096#note-9">https://osmocom.org/issues/6096#note-9</a>:</p>
<blockquote>
<p>On Thu, Jul 20, 2023 at 01:35:30PM +0000, osmith wrote:</p>
<blockquote>
<p>As I understand it, the problem is that we pass the same gsn->fd0 and gsn->fd10 to gtp_kernel_create in lib/tun.c:tun_new().</p>
</blockquote>
<p>Ah. Ok, that explains. The way how the kernel GTP driver works is that for each UDP socket there can only be one gtp-net-device. After all, the kernel and all of GTP-U know nothing about APNs. All they know is packets arriving, and TEID-to-IP address mappings.</p>
<p>This means, indeed, for every UDP socket, there can only be one APN configured. However, multiple different<br />UDP sockets can serve multiple APNs. The way how GTP-C vs GTP-U works, one can actually hand out a different GTP-U endpoint/socket/port for each PDP context that is being activated. So osmo-ggsn could create one different GTP-U socket for each APN, and then hand out the respective GTP-U IP address during PDP context activate.</p>
</blockquote> OsmoHNBGW - Feature #5816 (New): Picocells availiable in R.Uhttps://osmocom.org/issues/58162022-12-07T03:42:28Zcopslock
<p>This topic is describing the info of femtocells in russia,as the local operaters seem started to retire these devices<br />For example,the MTS ePico3801<br /><img src="https://osmocom.org/attachments/download/5719/2650013279-1.png" alt="" /><br /><img src="https://osmocom.org/attachments/download/5720/2650013279-2.png" alt="" /><br /><img src="https://osmocom.org/attachments/download/5721/2650013279-3.png" alt="" /><br /><img src="https://osmocom.org/attachments/download/5722/2650013279-4.png" alt="" /></p> OsmoHNBGW - Feature #5813 (New): Alcatel-Lucent femtocells availiable in Europehttps://osmocom.org/issues/58132022-12-06T18:21:43Zcopslock
<p>This is the topic that collecting the info and availability of the diverse Alcatel-Lucent femtocells<br /><img src="https://osmocom.org/attachments/download/5708/picture227-1.png" alt="" /><br /><img src="https://osmocom.org/attachments/download/5707/picture807-2.png" alt="" /></p>
<pre><code class="html syntaxhl">The Alcatel-Lucent 9362 Enterprise Cell (EC) V2.2 cost-effectively extends Wideband Code
Division Multiple Access (W-CDMA) coverage and high-speed packet access (HSPA) capacity
to businesses, delivering fast, responsive data service and crystal-clear voice. With scalable
capacity, the Alcatel-Lucent 9362 EC is just the right size for enterprises, whether they have
16, 24 or 32 users. Additionally, the Alcatel-Lucent 9362 EC has a unique capability to form
autonomous self-organizing groups of coverage, so medium to large enterprises, requiring many
access points, are as easy to cover as offices needing only a single 9362 Enterprise Cell.
FEATURES
• Small, lightweight device that may be
installed in a free-standing position or
mounted on a wall or ceiling
• Flexible coverage, supporting a maximum
transmit power of 100 mW or 250 mW
• Scalable capacity, which supports 16 users
with options to upgrade to 24 and 32 users
• Comes with Two integrated
omnidirectional antennas
• Receive (Rx) space diversity for improved
signal quality and greater capacity
• 64 QAM for higher throughput
• SON capabilities
• Secure outer casing – forced opening may
optionally disable the unit permanently
• Support for shared secret and certificatebased authentication
• Access control with support for open,
prioritized open, and closed modes
• Small cell net capability to form autonomous self-organizing groups of
extended coverage
• Handovers to and from the macro network
• Applications enablement with presence
API, network local routing and Internet
traffic breakout
• Complete status reporting with user
enabled/disabled bi-color LEDs
Protocols and interfaces
• Radio Access Network Application
Protocol (RANAP) on Iuh
• RANAP on Iu Prime
• Transmission and PoE+: Gigabit Ethernet
(GigE) connection (1000Base-T RJ45
connector)
• Local GigE connection to any other
device: 1000Base-T RJ45
Radio characteristics
• Operating band: 2100 MHz
• Listening bands
¬ 2100 MHz UMTS
¬ 900/1800 MHz GSM
• Rx diversity
• Capacity
¬ 16 active users
¬ Option to increase capacity in steps of
8 users, up to a maximum of 32 active
users, with the purchase of additional
licensing keys (with SW release BCR 3.0)
• Maximum bearers
¬ BCR 2.4.1
– 14.4 Mb/s HSDPA
– 2 Mb/s HSUPA
¬ BCR 3.0
– 21 Mb/s HSDPA (with 64 QAM
optional feature)
– 5.7 Mb/s HSUPA
• Maximum transmission power
¬ BCR 2.4.1
– Two orderable versions:
100 mW or 250 mW
¬ BCR 3.0
– 100 mW
– Option to increase transmission
power to 250 mW with the purchase
of additional licensing key
• Sensitivity: -107 dBm
</code></pre> libosmo-abis - Bug #5756 (New): io_uring support in libosmo-abishttps://osmocom.org/issues/57562022-11-09T12:57:42Zlaforge
<p>Once libosmocore provides the new API for the upcoming io_uring backend (<a class="issue tracker-2 status-3 priority-3 priority-high3 closed" title="Feature: io_uring support in libosmocore (Resolved)" href="https://osmocom.org/issues/5751">#5751</a>) we will need to port libosmo-abis over to this new API.</p>
<p>Currently we're using the following code-paths for I/O</p>
<table>
<tr>
<th>libosmo-abis function</th>
<th>I/O function</th>
<th>provided by</th>
</tr>
<tr>
<td>ipa_client_write_default_cb</td>
<td>send</td>
<td>-</td>
</tr>
<tr>
<td>ipa_server_conn_write</td>
<td>send</td>
<td>-</td>
</tr>
<tr>
<td>ipa_client_read</td>
<td>ipa_msg_recv_buffered</td>
<td>libosmocore</td>
</tr>
<tr>
<td>ipa_server_conn_read</td>
<td>ipa_msg_recv_buffered</td>
<td>libosmocore</td>
</tr>
</table>
<p>We need to analyze each of those and migrate, if possible.</p>
<p>There are also the mISDN and DAHDI input drivers, which are currently not seen as performance critical.</p>
<p>Likewise there is RTP support in libosmo-trau which is doing I/O via libortp, which we also consider out of scope for now.</p> OsmoHNBGW - Bug #5304 (New): Verizon CDMA femtocellhttps://osmocom.org/issues/53042021-11-10T15:32:33Zcopslock
<p>Verizon Samsung SCS-2U01 is a very famous target for many hackers,while as Harald said in 32C3,none of them even thought about running a local network upon it.Verizon is phasing out its CDMA network,it's time to play with these valuable blackbox<br /><img src="https://scache.vzw.com/content/dam/support/images/network_extender.png" alt="" /><br />It looks like the IS95 core network is a bit simpler than 3GPP network,however,there is no project about IS95 at all,Neither the data PDSN nor the IS95 MSC.</p> OsmoHNBGW - Bug #4933 (New): Femtocell choice in U.K 2021/01https://osmocom.org/issues/49332021-01-03T13:55:43ZcopslockOsmoHNBGW - Feature #4882 (New): HSPA+ Picocell availiable in U.Shttps://osmocom.org/issues/48822020-12-01T06:24:17Zcopslock
<p>The Ericsson RBS6402 WCDMA Picocell can be obtained from ebay recently at a very good price.It runs on Texas Instrument Keystone SoC,and have a good capacity compared to other femtocells<br /><img src="https://osmocom.org/attachments/download/4435/6402_page-0001.jpg" alt="" /><br /><img src="https://osmocom.org/attachments/download/4436/6402_page-0002.jpg" alt="" /><br /><pre>
Multi standard: WCDMA, LTE and Wi-Fi (optional)
● Up to 10 bands in three modules available:2-4 LTE/WCDMA bands per module
● 2 3GPP bands operate simultaneously and 1 Wi-Fi module operates in 2 bands
● LTE 2 Carrier Aggregation up to 300/50 Mbps DL/UL
● LTE 2 Carrier and LAA/LTE-U 5GHz unlicensed band
LTE: Carrier bandwidth 5,10 and 20 MHz
2x2 MIMO
WCDMA: 21/5.76 Mbps DL/UL, HW prepared for Dual Carrier 42 Mbps DL
RNC connected, Full mobility
Wi-Fi 2.4 GHz 802.11 b/g/n, 3x3 MIMO, 23 dBm (EIRP, 18 dBm per chain)
Wi-Fi 5 GHz: 802.11 a/n/ac, 3x3 MIMO, 23 dBm (EIRP, 18 dBm per chain)
RF Power 3GPP: Up to 2x250 mW per module (total 4x250 mW)
Antenna: Integrated omni-directional antennas for LTE/WCDMA and Wi-Fi
Support for external antennas for LTE/WCDMA
Typical coverage: 800 - 2 500 m² depending on building type
Active users: Up to 64 for WCDMA and up to 128 for LTE
TRANSMISSION^
Interfaces: 1 Gbps Electrical Ethernet, Optical as an option
SFP and transmission module options
Features Internet-grade Backhaul support, TWAMP
Security: IPsec for untrusted networks
Signed SW and secure O&M access for untrusted locations
Synchronization: GPS, NTP, IEEE 1588v
MECHANICAL SPECIFICATIONS
HxW xD: 280x167x62mm (excluding connector field)
Volume: 2.8 liters
Weight: 2.5 kg
Mounting: Flexible mounting on walls and ceilings
INTERFACE SPECIFICATIONS^
Power supply: Power over Ethernet line, Power over Ethernet injector or External AC/DC adapter
LED indication: Total 8 LED for 3GPP, Backhaul & Wi-Fi
GPS: Support for external GPS (optional)
ENVIRONMENTAL SPECIFICATIONS
Environment: ETSI 3.1, IP
Normal operating temp.: 0 - +50º C with fan, 0 - +40º C with passive cooling
OSS support: Integrated to OSS-RC/Ericsson Network Manager
</pre></p> OsmoHNBGW - Feature #4790 (New): Vodafone HSPA+ femtocell availiable in Deutschlandhttps://osmocom.org/issues/47902020-10-09T08:35:38Zcopslock
<p>Seems like the Vodafone femtocell 3802V widely availiable on ebay sites recently,it's based on broadcom solution and runs on the Standard Iuh interface,better alternative choice than expensive Erricson smallcells<br /><img src="https://i.ebayimg.com/images/g/VVsAAOSwk25cfrfc/s-l1600.jpg" alt="" /><br /><img src="https://i.ebayimg.com/images/g/wskAAOSwpCFcfrfd/s-l1600.jpg" alt="" /></p> OsmoHNBGW - Feature #4574 (New): Femtocell choice in 2020/06https://osmocom.org/issues/45742020-06-01T09:18:46Zcopslock
<p>Recently the AT&T had shutdown its UMTS femto system,thus,result in the Cisco femtocells that operated in their network are widely available on eBay or Amazon platform,it turned out to be the DPH-151/153/154 microcell,But as the Harald noticed,these units are communicated through the Cisco URSL protocal,which is the evolution of the current 2G RSL signaling,and possible someone can add UMTS patch to it.So far it's the best available femtocell rather than the ip.access one.<br /><img src="https://cdn.embedded.com/contenteetimes/images/edn/Teardowns/3GMicroCell/3G-MicroCell-PC-board_resized.jpg" alt="" /></p> OsmoSTP - Bug #4274 (New): AS Name isn't displayedhttps://osmocom.org/issues/42742019-11-21T10:47:29Zroch
<p>Hi,</p>
<p>It looks like AS Name isn't displayed properly even if both AS and ASPs are active.<br /><pre>
OsmoSTP# show cs7 instance 0 asp
Effect Primary
ASP Name AS Name State Type Remote IP Addr:Rmt Port SCTP
------------ ------------ ------------- ---- ----------------------- ----------
stp2 ? ASP_ACTIVE m3ua 199.255.7.133:2919
asp-dyn-0 ? ASP_ACTIVE ipa 172.17.0.2:34856
asp-dyn-1 ? ASP_ACTIVE ipa 172.17.0.3:53584
OsmoSTP# show cs7 instance 0 as all
Routing Routing Key Cic Cic Traffic
AS Name State Context Dpc Si Opc Ssn Min Max Mode
------------ ------------ ---------- ------------- ---- ------------- --- ----- ----- -------
STP2 AS_ACTIVE 56 0.8.6 loadshare
telnahub AS_ACTIVE 0 0.0.0 loadshare
</pre></p>