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> 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> 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> 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-4f5cb69e-show, #collapse-4f5cb69e-hide').toggle(); $('#collapse-4f5cb69e').fadeToggle(150);; return false;" id="collapse-4f5cb69e-show" class="icon icon-collapsed collapsible">osmo-ggsn log + dmesg</a><a href="#" onclick="$('#collapse-4f5cb69e-show, #collapse-4f5cb69e-hide').toggle(); $('#collapse-4f5cb69e').fadeToggle(150);; return false;" id="collapse-4f5cb69e-hide" class="icon icon-expended collapsible" style="display:none;">osmo-ggsn log + dmesg</a><div id="collapse-4f5cb69e" 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> libosmocore - Bug #6360 (New): libosmovty fails to parse commands like "test (foo|bar) [(one|two|...https://osmocom.org/issues/63602024-02-14T21:25:23Zfixeria
<p>Support for the <code>[(one|two|three)]</code> syntax was added back in 2019:</p>
<pre>
commit b55f4d2df21b966c3953264d8961f259814f4650
Author: Neels Hofmeyr <neels@hofmeyr.de>
Date: Thu Jan 31 08:13:31 2019 +0100
vty: enable optional-multi-choice syntax: [(one|two)]
</pre>
<p><a class="external" href="https://cgit.osmocom.org/libosmocore/commit/?id=b55f4d2df21b966c3953264d8961f259814f4650">https://cgit.osmocom.org/libosmocore/commit/?id=b55f4d2df21b966c3953264d8961f259814f4650</a></p>
<p>However the VTY parser still hits an assertion if the command has a non-optional choice preceding an optional one:</p>
<pre>
test (foo|bar) [(one|two|three)]
</pre>
<p>Here is a patch extending the existing testing coverage and reproducing the problem:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/35961">https://gerrit.osmocom.org/c/libosmocore/+/35961</a></p>
<pre>
$ gdb ./tests/vty/vty_transcript_test
(gdb) r
Program received signal SIGABRT, Aborted.
0x00007ffff7d8b83c in ?? () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7d8b83c in ?? () from /usr/lib/libc.so.6
#1 0x00007ffff7d3b668 in raise () from /usr/lib/libc.so.6
#2 0x00007ffff7d234b8 in abort () from /usr/lib/libc.so.6
#3 0x00007ffff7f3d511 in osmo_panic_default (fmt=0x7ffff7fb112c "Assert failed %s %s:%d\n", args=0x7fffffffddc0) at panic.c:45
#4 0x00007ffff7f3d4c5 in osmo_panic (fmt=0x7ffff7fb112c "Assert failed %s %s:%d\n") at panic.c:80
#5 0x00007ffff7f96d83 in cmd_make_descvec (string=0x55555555734f "multi3 (foo|bar) [(one|two|three)]", descstr=0x555555557372 "multi3 test command\nfoo\nbar\n1\n2\n3\n") at command.c:439
#6 0x00007ffff7f96add in install_element (ntype=1, cmd=0x555555559388 <multi3_cmd>) at command.c:1009
#7 0x00007ffff7f9718a in install_element_ve (cmd=0x555555559388 <multi3_cmd>) at command.c:1026
#8 0x0000555555556570 in init_vty_cmds () at vty/vty_transcript_test.c:391
#9 0x0000555555556384 in main (argc=1, argv=0x7fffffffe018) at vty/vty_transcript_test.c:429
(gdb) frame 5
#5 0x00007ffff7f96d83 in cmd_make_descvec (string=0x55555555734f "multi3 (foo|bar) [(one|two|three)]", descstr=0x555555557372 "multi3 test command\nfoo\nbar\n1\n2\n3\n") at command.c:439
439 OSMO_ASSERT(multiple);
(gdb) p cp
$1 = 0x555555557365 "|two|three)]"
</pre>
<p>libosmocore.git 9d73503bd09eb164f781d488bf2c839c0822798a</p> OsmocomBB - Bug #6337 (New): bad fr audio with gapk/ms-sdrhttps://osmocom.org/issues/63372024-01-22T21:21:06ZHoernchen
<p>The audio sounds <em>kinda</em> choppy, but not really - one half are apparently decoding issues, the other one.. well.. hard to tell, bad timing doing blocking audio calls?<br />It does not appear to be cpu related.<br />Another problem is is that the (very large!) wq used by l1ctl_client_send keeps filling up, which obviously adds latency, until it overflows. At that point random messages get dropped, which is kinda bad...<br />Sometimes the audio improves after some time - I don't understand why/how.</p>
<p>This might affect phone setups, too.</p> OsmoMSC - Bug #6330 (New): Incorrect handling of V.120 data callshttps://osmocom.org/issues/63302024-01-18T15:02:29Zfixeria
<p>Current osmo-msc (8236184ef05e5b10505bbb3189357d2050bbdc5d) fails to connect a V.120 data call, see the attached PCAP.</p>
<p>How to reproduce:</p>
<ul>
<li>find phone(s)/modem(s) supporting V.120 data calls
<ul>
<li>the result of <code>AT+CBST=?</code> should contain one of V.120 rates: 39, 43, 47, 48</li>
<li>most Sony Ericsson phones/modems can do V.120: <code>+CBST: (0,7,12,14-17,39,43,47-51,71,75,79-84),(0,4),(1)</code></li>
</ul>
</li>
<li>configure phone(s)/modem(s) to use V.120, for example: <code>AT+CBST=39,0,1</code> for 9600 bps</li>
<li>initiate a data call, for example: <code>ATD15843</code></li>
</ul>
<p>In my case (using SE K800), the call is aborted due to Assignment Failure, because osmo-msc sends weird Assignment Command:</p>
<pre>
GSM A-I/F BSSMAP - Assignment Request
Message Type Assignment Request
Channel Type - (Data)
Element ID: 0x0b
Length: 3
0000 .... = Spare bit(s): 0x00
.... 0010 = Speech/Data Indicator: Data (2)
.000 1010 = Channel rate and type: Full or Half rate TCH channel, Full rate preferred, changes allowed also after first channel allocation as a result of the request (10)
0... .... = Extension: Last Octet
.0.. .... = Service: Transparent
..01 0010 = Rate: 2.4kbit/s
...
</pre>
<p><code>2.4kbit/s</code> / <code>Transparent</code> is definitely not what the calling phone requested, it should be <code>9.6kbit/s</code> / <code>Non-transparent</code>.</p>
<p>Below is how the Bearer Capability looks like for <code>AT+CBST=39,0,1</code>:</p>
<pre>
Bearer Capability 1 - (Full rate support only MS)
Element ID: 0x04
Length: 12
Octet 3
1... .... = Extension: No Extension
.01. .... = Radio channel requirement: Full rate support only MS
...0 .... = Coding standard: GSM standardized coding
.... 0... = Transfer mode: circuit
.... .001 = Information transfer capability: Unrestricted digital information (0x1)
Octet 4
1... .... = Extension: No Extension
.1.. .... = Compression: Allowed
..00 .... = Structure: Service data unit integrity (0)
.... 1... = Duplex mode: Full
.... .0.. = Configuration: Point-to-point
.... ..0. = NIRR: No meaning is associated with this value
.... ...0 = Establishment: Demand
Octet 5
0... .... = Extension: Extended
.00. .... = Access Identity: Octet identifier (0)
...1 1... = Rate Adaption: Other rate adaption (see octet 5a) (3)
.... .001 = Signalling Access Protocol: According to ITU-T Rec. Q.920 and ITU-T Rec. Q.930 (1)
Octet 5a
0... .... = Extension: Extended
.00. .... = Other ITC: Restricted digital information (0)
...0 0... = Other Rate Adaption: According to ITU-T Rec. V.120 (0)
.... .000 = Spare bit(s): 0
Octet 5b
1... .... = Extension: No Extension
.1.. .... = Rate Adaption Header: Included
..1. .... = Multiple frame establishment support in data link: Supported
...1 .... = Mode of operation: Protocol sensitive
.... 0... = Logical link identifier negotiation: Default, LLI=256 only
.... .0.. = Assignor/Assignee: Message originator is default assignee
.... ..0. = In band/Out of band negotiation: Negotiation is done in-band using logical link zero
.... ...0 = Spare bit(s): 0
Octet 6
0... .... = Extension: Extended
.01. .... = Layer 1 Identity: Octet identifier
...0 000. = User information layer 1 protocol: Default layer 1 protocol
.... ...1 = Synchronous/asynchronous: Asynchronous
Octet 6a
0... .... = Extension: Extended
.0.. .... = Number of Stop Bits: 1
..0. .... = Negotiation: In-band negotiation not possible
...1 .... = Number of data bits excluding parity bit if present: 8
.... 0101 = User rate: 9.6 kbit/s (according to ITU-T Rec. X.1 and ITU-T Rec. V.110)
Octet 6b
0... .... = Extension: Extended
.11. .... = V.110/X.30 rate adaptation Intermediate rate: 16 kbit/s (3)
...0 .... = Network independent clock (NIC) on transmission (Tx): does not require to send data with network independent clock
.... 0... = Network independent clock (NIC) on reception (Rx): cannot accept data with network independent clock
.... .011 = Parity information: None (3)
Octet 6c
0... .... = Extension: Extended
.01. .... = Connection element: Non transparent (RLP) (1)
...0 0000 = Modem type: None
Octet 6d
0... .... = Extension: Extended
.00. .... = Other modem type: No other modem type specified in this field (0)
...0 0001 = Fixed network user rate: 9.6 kbit/s (according to ITU-T Rec. X.1 and ITU-T Rec. V.110)
Octet 6e
0... .... = Extension: Extended
.1.. .... = Acceptable channel codings (TCH/F14.4): Acceptable
..0. .... = Acceptable channel codings (Spare): False
...1 .... = Acceptable channel codings (TCH/F9.6): Acceptable
.... 0... = Acceptable channel codings (TCH/F4.8): Not Acceptable
.... .001 = Maximum number of traffic channels: 1 TCH
Octet 6f
1... .... = Extension: No Extension
.000 .... = UIMI, User initiated modification indication: not allowed/required/applicable (0)
.... 0001 = Wanted air interface user rate: 9.6 kbit/s (1)
</pre> rtl-sdr - Bug #6329 (New): rtl_sdr does not have correct rpath set on OSX buildhttps://osmocom.org/issues/63292024-01-12T21:57:08Zhut8
<p>After building using these commands (copied from the wiki) on OSX:</p>
<pre><code class="shell syntaxhl"><span class="nb">cd </span>rtl-sdr/
<span class="nb">mkdir </span>build
<span class="nb">cd </span>build
cmake ../
make
<span class="nb">sudo </span>make <span class="nb">install
sudo </span>ldconfig
</code></pre>
<p>First, ldconfig won't work on a mac. However, up to that point, everything goes fine. But then when I try to run rtl_sdr, I get:</p>
<pre><code class="shell syntaxhl">dyld[54169]: Library not loaded: @rpath/librtlsdr.2.dylib
Referenced from: <932B34BB-A147-366F-86D0-13D5D959A868> /usr/local/bin/rtl_sdr
Reason: no LC_RPATH<span class="s1">'s found
</span></code></pre>
<p>I'm not familiar at all with CMake, but I was able to get it to run by running:</p>
<pre><code class="shell syntaxhl"><span class="nb">sudo </span>install_name_tool <span class="nt">-add_rpath</span> /usr/local/lib /usr/local/bin/rtl_sdr
</code></pre>
<p>I have to do that for all of the executables. I'm on Sonoma 14.2.1 on an M2.</p> OsmoBSC - Bug #6328 (New): Channel Mode Modify fails to modify the RTP payload type numberhttps://osmocom.org/issues/63282024-01-12T06:24:55Zneelsnhofmeyr@sysmocom.de
<p>if you look at the pcap in <a class="external" href="https://osmocom.org/attachments/7192">https://osmocom.org/attachments/7192</a> from <a class="issue tracker-2 status-2 priority-2 priority-default" title="Feature: if MT call leg does not support the assigned codec, re-assign to a compatible codec (In Progress)" href="https://osmocom.org/issues/6258">#6258</a><br />you'll see that the Channel Mode Modify in packet 5368 changes the codec from GSM-FR to AMR,<br />but then the AMR payload in RTP continues to indicate PT=3 instead of the expected PT=112.</p>
<p>This is because osmo-bsc still fails to:</p>
<ul>
<li>tell the MGW about the changed codec and payload type number via MGCP MDCX</li>
<li>tell the BTS to emit the changed payload type number via ipacc.MDCX</li>
</ul>
<p>This should happen in lchan_fsm.c in lchan_fsm_wait_rsl_chan_mode_modify_ack() on rx of LCHAN_EV_RSL_CHAN_MODE_MODIFY_ACK.<br />The lchan_fsm.c should tell the lchan_rtp_fsm.c to change the payload type number and codec.<br />When lchan_rtp_fsm.c is done with both MDCX, it should signal LCHAN_EV_RTP_READY back to lchan_fsm.</p> OP25 - Bug #6323 (New): Install script is broken on Ubuntu 23.10https://osmocom.org/issues/63232024-01-05T19:33:14ZErikSwan
<p>I am trying to install OP25 on a fresh Ubuntu 23.10 virtual machine, but it appears like the install script is broken.</p>
When running <code>install.sh</code>, I get the following error message:<br /><pre>
CMake Error at op25/gr-op25/swig/CMakeLists.txt:28 (include):
include could not find requested file:
GrSwig
CMake Error at op25/gr-op25/swig/CMakeLists.txt:40 (GR_SWIG_MAKE):
Unknown CMake command "GR_SWIG_MAKE".
-- Configuring incomplete, errors occurred!
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target 'install'. Stop.
</pre><br />To reproduce:
<ol>
<li>Create a fresh Ubuntu 23.10 installation using default settings in the installer</li>
<li>Follow the <a class="wiki-page" href="https://osmocom.org/projects/op25/wiki/InstallInstructionsPage">installation instructions</a> exactly.</li>
</ol> pySim - Bug #6322 (New): ATR type annotationhttps://osmocom.org/issues/63222024-01-03T21:55:30Zmerlinchlosta
<p>There's a small mixup in the ATR type annotations (<code>Hexstr</code> vs. <code>List[int]</code>) in <code>PcscSimLink</code>:</p>
<pre>
def get_atr(self) -> Hexstr:
return self._con.getATR()
</pre>
<p><code>pyscard</code> actually returns <code>List[int]</code> for an ATR. Depending code seems to convert using <code>i2h</code>.<br /><code>SerialSimLink</code> mimics the behavior (writing <code>self._atr</code> as <code>List[int]</code> in <code>_reset_card</code>).</p> OsmoMSC - Bug #6321 (New): SMS not delivered from corrupted SMS databasehttps://osmocom.org/issues/63212024-01-02T13:07:31Zjolly
<p>When osmo-msc is started with corrupted "sms.db", no SMS is delivered.</p>
<p>Only the earliest SMS is delivered on a location update. All other SMS are not delivered until the next location update triggers the next earliest SMS delivery.</p>
<p>The problem was solved by removing the "sms.db" file and restarting osmo-msc. All queued SMS were delivered instantly. A newly queued SMS was delivered instantly.</p>
<p>To reproduce and debug the problem, I keept the corrupt database file. It is not included with this issue, because it may contain private information. Ask me for it. (/files/auftraege/sysmocom-MSC_SMS_BUG/sms.db_buggy)</p> pySim - Bug #6314 (New): pySim-trace doesn't support ARA-Mhttps://osmocom.org/issues/63142023-12-23T09:31:02Zlaforge
<p>during execution of our pySim-shell test, even with the included pcap we're getting:</p>
<pre>
WARNING pySim.apdu.ts_102_221: SELECT UNKNOWN AID a00000015141434c00
</pre>
<p>the AID is that of the ARA-M applet. We do support ARA-M in pySim-shell. However, we do not appear to use that code from pySim-shell, probably related to the AID auto-detection missing.</p> OsmoHLR - Bug #6312 (New): Querying HLR for MSISDN-to-IMSI mapping is too cumbersome and inefficienthttps://osmocom.org/issues/63122023-12-17T19:41:38Zfalconia
<p>Thanks to recently implemented features <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Possibility to route SMS messages over GSUP (Resolved)" href="https://osmocom.org/issues/3587">#3587</a> and <a class="issue tracker-2 status-7 priority-2 priority-default" title="Feature: Implement routing of SMS-over-GSUP messages between connected MSC/VLRs and SMSCs (Stalled)" href="https://osmocom.org/issues/6135">#6135</a>, we now have a way to connect an external SMSC to an OsmoMSC+OsmoHLR core network. However, there is one remaining difficulty: when that external SMSC needs to deliver MT SMS to a subscriber, the mechanism of SMS-over-GSUP requires that the target MS be identified by IMSI, while the SMSC will typically only have MSISDN for the recipient. Elaborating a little:</p>
<ul>
<li>IMSI is a strictly required IE in every GSUP message, and the design of GSUP thoroughly assumes that every entity that initiates a GSUP exchange (beginning with a request message) knows the IMSI it wishes to operate on.</li>
</ul>
<ul>
<li>Because of the previous point, I don't see an obvious way to add an exchange of "I only know MSISDN, please tell me the corresponding IMSI" to GSUP. What would the requestor put into the mandatory IMSI field of the request message? A dummy? Would the response then replace that dummy with the real IMSI and thus no longer match? Various common GSUP code paths will likely break then - hence this type of query just doesn't seem to fit into GSUP architecture.</li>
</ul>
<ul>
<li>The basic paradigmatic principle that MT-SMS recipients are identified by IMSI rather than MSISDN at the low-level MT delivery protocol level seems correct: one can think of special cases of network-originated SMS (e.g., SIM OTA programming) in which a recipient may not have an MSISDN at all, but does have an IMSI and is thus attached to GERAN or UTRAN. Hence it seems logically correct to me to have MSISDN-to-IMSI resolution as a separate step just prior to actual MT SMS delivery attempt.</li>
</ul>
<p>One currently workable approach is to have the external SMSC connect to OsmoHLR not only via GSUP, but also connect to OsmoHLR ctrl interface, issue ctrl GET queries for subscriber.by-msisdn-XXXX.info and fish the IMSI out of the verbose multiline ASCII-formatted response. My current plan is to implement this cumbersome and inefficient MSISDN-to-IMSI resolution mechanism in ThemWi-SMSC (my current real-life-need use case for an external SMSC connecting to Osmocom CN), but it would certainly be nice to have a better way. I also reason that a more efficient and more logically sensible way of doing this mapping resolution will be needed before the approach of a separate SMSC (split from OsmoMSC) can become Osmocom mainstream.</p>
<p>One easy-to-implement relief measure would be to add a subscriber.by-*.imsi ctrl variable (like subscriber.by-*.msisdn, but read-only). The benefits will be shorter TCP-carried messages on the ctrl connection for MSISDN-to-IMSI queries, and simpler parsing code in the SMSC - no need to fish the IMSI out of lots of other irrelevant info. But the whole idea of using this ctrl interface for a key internal function still feels philosophically wrong. Any better ideas?</p> OsmoMGW - Bug #6297 (New): octet-align=0 is the RFC 6871 specified default to use when omitted; b...https://osmocom.org/issues/62972023-12-08T05:31:12Zneelsnhofmeyr@sysmocom.de
<p>In rx_rtp(), we have a check that ensures the right AMR pack mode is arriving in incoming RTP packets.</p>
<p>Currently, the semantics are this:</p>
<p>- when there is no 'octet-align' fmtp at all, then don't check.<br />- for 'octet-align=[01]' fmtp present, verify correct AMR pack mode.</p>
<p>But RFC 6871 (SDP) specifies that if the 'octet-align' parameter is omitted, that means octet-align=0.</p>
<p>No spec conforming client out there will see a need to send an explicit 'octet-align=0', it will just omit 'octet-align=1'.<br />So osmo-mgw should not change its validation behavior based on the presence or absence of the fmtp;<br />It should assume a default of 0 when omitted.</p>
<p>Related: libosmo-mgcp-client currently has a problem that it can only pass the octet-align flag once per entire SDP body; there is a patch pending to fix it [1] and code has been in flux; meaning to say:<br />It seems that osmo-msc has been omitting the octet-align fmtp for a while now; and things worked out ok because absence of it disabled the AMR pack mode validity checks in osmo-mgw. For 2G-to-2G, both sides sent octet-align=1, and osmo-msc's mgw just forwards without checking. If we now enable this check in osmo-mgw when octet-align is absent, that would break 2G-to-2G calls and needs a fix of osmo-msc's fmtp.</p>
<p>But we can also not just ignore this further: when adding interop with 3G, now it is important to indicate the right pack mode, so IuUP-to-AMR conversion results in the right pack mode. In effect, omitting the octet-align fmtp now results in IuUP converted to AMR-octet-align=0, mismatching 2G. So we should really adopt the specified way of indicating octet-align and not imply anything else.</p>
<p>A solution could be to <strong>not fail</strong> when an unexpected pack mode arrives at osmo-mgw.<br />We can complain in the log, but then just convert it to whatever we expected.</p>
In summary, I suggest to
<ul>
<li>always enable the AMR pack mode checks, also when octet-align fmtp is omitted (mgcp_codec_amr_align_mode_is_indicated() == false).</li>
<li>but when the checks indicate a mismatch, convert to what is needed implicitly and continue the call.</li>
<li>a new vty option in osmo-mgw could switch the octet-align checks to be strict and fail instead of converting.</li>
</ul>
<p>This way we get a concise spec conforming representation of octet-align fmtp in our SDP,<br />while at the same time not breaking 2G-2G calls for older osmo-msc that omit the "octet-align=1" by accident.</p>
<p>(I see that the current osmo-msc I am testing omits "octet-align=1" in MGCP to its MGW,<br />but haven't really checked for how long osmo-msc omits that fmtp; forever? since recently?)</p>
<p>[1] <a class="external" href="https://gerrit.osmocom.org/c/osmo-mgw/+/34900">https://gerrit.osmocom.org/c/osmo-mgw/+/34900</a> -- libosmo-mgcp-client patch to fix fmtp</p> OsmoMGW - Bug #6293 (New): osmo-mgw "decides" for a codec during MGCP handling; instead it should...https://osmocom.org/issues/62932023-12-07T05:36:26Zneelsnhofmeyr@sysmocom.de
<p>This is how it should be:</p>
<p>- CRCX/MDCX sets up two conns of an endpoint, each with one or more codecs listed.<br />- At some point, RTP packets arrive, and the payload type number indicates the RTP payload's actual codec, as was listed in CRCX/MDCX.</p>
<p>When RTP packets arrive, that is when osmo-mgw needs to decide which codec to forward to the other side,</p>
<p>and that is when errors can happen from not being able to transcode. Not before.</p>
<p>However, working with mgcp_test.c, I notice that osmo-mgw already does some sort of "codec decision" when handling the CRCX message.</p>
<p>By adding another "CRCX" test with AMR#112 and GSM#3, I suddenly get this failure during CRCX handling:</p>
<pre><code>mgcp_protocol.c:833 endpoint:rtpbridge/1@mgw CI:91D7CDD4 CRCX: codec negotiation failure<br /> mgcp_protocol.c:1149 endpoint:rtpbridge/1@mgw CRCX: unable to create connection</code></pre>
<p>resulting in an MGCP protocol error:</p>
<pre><code>534 2 FAIL</code></pre>
<p>Investigation shows that in mgcp_tests.c, there somehow already is another conn on the endpoint, configured as EFR only,<br />meaning there is no match with [AMR,GSM]; figured out from this dbg output of conn_src and conn_dst:</p>
<pre><code>mgcp_codec.c:443 src 112 AMR/8000 AMR<br /> mgcp_codec.c:443 src 3 GSM/8000/1 GSM<br /> mgcp_codec.c:449 dst 97 GSM-EFR/8000 GSM-EFR</code></pre>
<p>So this fails only on the basis of the two codecs lists on two sides of an endpoint, at CRCX time.</p>
<p>Even if a client sets up two sides of an endpoint with unresolvable codecs (for TFO), the CRCX/MDCX to do so must be allowed.<br />The client may still MDCX later with better codecs, for example.</p>
<p>Also the client is free to choose codecs that don't match,<br />and generally do as much foot shooting as they like -- it's completely fine<br />to pick stupid codec lists that are suboptimal or not transcodable, as far as MGCP is concerned.</p>
<p>The only reason to completely fail CRCX/MDCX because of codecs would be: not a single one of the listed codecs is known to osmo-mgw.<br />Yes, we should reject codecs unknown to osmo-mgw, but we should do so only by returning a reduced list in the MGCP OK response,<br />so that only the known codecs are returned. Not by failing the MGCP protocol.</p>
<p>During MGCP handling, osmo-mgw has absolutely no need and no business to decide for a specific codec, or even check whether there is a common codec.</p>
<p>In code, these are the problematic places:</p>
<p>mgcp_codec_decide() called from handle_codec_info() called from handle_create_con()/_modify_con() in mgcp_protocol.c.<br />These are the handlers for CRCX / MDCX, resp.<br />That is the only place mgcp_codec_decide() is called.</p>
<p>There should not be a "codec" member in struct mgcp_rtp_end:</p>
<pre><code>/* currently selected audio codec */<br /> struct mgcp_rtp_codec *codec;</code></pre>
<p>It suggests that an endpoint needs to pick one codec, which it never should do. Instead, an endpoint should have a list of codecs with corresponding payload type numbers, and should figure out what to do with incoming RTP payload type numbers, when they come.</p>
<p>It looks like mgcp_codec_decide() figures out how to process incoming RTP packets already at CRCX/MDCX, stores the decision in end.codec, and then handles all RTP the same...?</p>
<p>Which so far has never been a problem because our clients assign only one codec,<br />and no-one is testing dynamically switching pt numbers in an active RTP stream on osmo-mgw?</p> OsmoHNBGW - Bug #6283 (New): cnpool: hnbgw fails to extract Mobile Identity from some GMM Attach ...https://osmocom.org/issues/62832023-12-04T01:48:00Zneelsnhofmeyr@sysmocom.de
<p>osmo-hnbgw expects a new RUA ctx to start with a RUA procedureCode = Connect.<br />Instead, while testing with the nano3G, I see a RUA procedureCode DirectTransfer.<br />osmo-hnbgw reacts to it as expected:</p>
<pre>
20231204023951411 DCN ERROR unexpected RANAP PDU in RUA Connect message: Direct Transfer (hnbgw_l3.c:313)
20231204023951411 DCN NOTICE Failed to extract Mobile Identity from RUA Connect message's RANAP payload (hnbgw_rua.c:202)
20231204023951411 DCN DEBUG (192.168.2.218:29169 000295-0000154153@ap.ipaccess.com) RUA-23 SCCP-0 PS MI=NONE: NONE NRI(10bit)=0x0=0: No sgsn found for this NRI, doing round-robin (hnbgw_cn.c:1086)
</pre>
<p>Do we need to allow a DirectTransfer message to initiate a RUA context?</p>
<p>It seems that the particular RUA context retries to do a GMM Attach,<br />and it seems that it starts out with a procedureCode Connect.<br />But when that fails, the RNC apparently keeps the RUA context open and re-sends another GMM Attach Request, in a DirectTransfer.</p>
<p>So for this scenario, we should also be able to extract the mobile identity.</p>
<p>In attached pcap iuup_init_fail4.pcapng, see packet 1307.</p>
<p>While capturing the pcap, there was no SGSN running, hence no PS attach can work,<br />but still the log shows that osmo-hnbgw is not able to handle this situation properly,<br />even if the SGSN is running to accept IuPS.</p> OCTOI - Osmocom Community TDM over IP - Bug #6281 (New): divf yate: calls to wave playback or loo...https://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> OsmoDia2GSUP - Bug #6255 (New): Implement 3GPP Purge UE Requesthttps://osmocom.org/issues/62552023-11-10T13:29:45Zlynxis
<p>Open5gs is sending 3GPP Purge UE Request on which the dia2gsup doesn't answer at all.</p> OsmocomBB - Bug #6201 (New): modem: signal proper MS Radio Access Capabilityhttps://osmocom.org/issues/62012023-10-03T17:37:39Zfixeria
<p>The modem app is currently sending hard-coded MS RACap to the PCU. It's hard-coded in libosmo-gprs-rlcmac:</p>
<pre><code class="c syntaxhl"><span class="cm">/* 11.2.16 Packet Resource Request */</span>
<span class="kt">void</span> <span class="nf">gprs_rlcmac_enc_prepare_pkt_resource_req</span><span class="p">(</span><span class="n">RlcMacUplink_t</span> <span class="o">*</span><span class="n">block</span><span class="p">,</span>
<span class="k">struct</span> <span class="n">gprs_rlcmac_ul_tbf</span> <span class="o">*</span><span class="n">ul_tbf</span><span class="p">,</span>
<span class="k">enum</span> <span class="n">gprs_rlcmac_access_type</span> <span class="n">acc_type</span><span class="p">)</span>
<span class="p">{</span>
<span class="n">Packet_Resource_Request_t</span> <span class="o">*</span><span class="n">req</span><span class="p">;</span>
<span class="k">struct</span> <span class="n">gprs_rlcmac_entity</span> <span class="o">*</span><span class="n">gre</span> <span class="o">=</span> <span class="n">ul_tbf</span><span class="o">-></span><span class="n">tbf</span><span class="p">.</span><span class="n">gre</span><span class="p">;</span>
<span class="n">memset</span><span class="p">(</span><span class="n">block</span><span class="p">,</span> <span class="mi">0</span><span class="p">,</span> <span class="k">sizeof</span><span class="p">(</span><span class="o">*</span><span class="n">block</span><span class="p">));</span>
<span class="n">req</span> <span class="o">=</span> <span class="o">&</span><span class="n">block</span><span class="o">-></span><span class="n">u</span><span class="p">.</span><span class="n">Packet_Resource_Request</span><span class="p">;</span>
<span class="n">req</span><span class="o">-></span><span class="n">MESSAGE_TYPE</span> <span class="o">=</span> <span class="n">OSMO_GPRS_RLCMAC_UL_MSGT_PACKET_RESOURCE_REQUEST</span><span class="p">;</span>
<span class="cm">/* ... */</span>
<span class="n">req</span><span class="o">-></span><span class="n">ID</span><span class="p">.</span><span class="n">UnionType</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span> <span class="cm">/* Use TLLI */</span>
<span class="n">req</span><span class="o">-></span><span class="n">ID</span><span class="p">.</span><span class="n">u</span><span class="p">.</span><span class="n">TLLI</span> <span class="o">=</span> <span class="n">gre</span><span class="o">-></span><span class="n">tlli</span><span class="p">;</span> <span class="cm">/* Use TLLI */</span>
<span class="n">req</span><span class="o">-></span><span class="n">Exist_MS_Radio_Access_capability2</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="n">req</span><span class="o">-></span><span class="n">MS_Radio_Access_capability2</span><span class="p">.</span><span class="n">Count_MS_RA_capability_value</span> <span class="o">=</span> <span class="mi">1</span><span class="p">;</span>
<span class="cm">/* TODO: fill Content_t: */</span>
<span class="cm">/* req->MS_Radio_Access_capability2.MS_RA_capability_value[0].Content.* */</span>
</code></pre>
<p>We definitely want to send something more meaningful than all zeroes.</p>
<ul>
<li>There needs to be a way (API) to "tell" libosmo-gprs-rlcmac which MS RACap to use.</li>
<li>We may also want to make some parts of the RACap configurable via the VTY.</li>
</ul> OsmoSGSN - Bug #6176 (New): build failure (dependency / concurrency issue)https://osmocom.org/issues/61762023-09-13T15:02:17Zlaforge
<p>when trying <code>make -j8 check</code> in current master (which is also 1.11.0):</p>
<pre>
...
Making check in src
make[4]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[2]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[5]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[5]: Nothing to be done for 'install-exec-am'.
make[5]: Nothing to be done for 'install-data-am'.
make[5]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[4]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
Making check in gprs
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[4]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
Making install in src
make[2]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
CC crc24.lo
CC gprs_llc_parse.lo
CC gprs_utils.lo
Making install in gprs
CC sgsn_ares.lo
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
CC gprs_llc_parse.lo
CC crc24.lo
CC gprs_utils.lo
CC sgsn_ares.lo
mv: cannot stat '.deps/crc24.Tpo': No such file or directory
make[3]: *** [Makefile:454: crc24.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
mv: cannot stat 'gprs_utils.loT': No such file or directory
mv: cannot stat '.deps/gprs_utils.Tpo': No such file or directory
make[3]: *** [Makefile:454: gprs_utils.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
make[2]: *** [Makefile:393: install-recursive] Error 1
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[1]: *** [Makefile:461: install-recursive] Error 1
make[1]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn'
make: *** [Makefile:765: install] Error 2
make: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
make[2]: *** [Makefile:393: check-recursive] Error 1
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[1]: *** [Makefile:461: check-recursive] Error 1
make[1]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn'
make: *** [Makefile:760: check] Error 2
</pre>
<p>doing that with <code>-j1</code> works, though.</p> Miscellaneous Projects - Bug #6129 (New): Discourse: Setting a custom avatar via upload failshttps://osmocom.org/issues/61292023-08-02T18:07:32ZBilly549
<p>When uploading an avatar to discourse.osmocom.org, the server returns a HTTP 500 error on the avatar URL (i.e. 'https://discourse.osmocom.org/uploads/default/original/1X/f6c7f5bc8823dce321212e28315c34837b880a0f.jpeg')</p>
<p>When speaking to LaF0rge in IRC, it was noted that the file can't be found:</p>
<blockquote>
<p>[18:28:21] <LaF0rge> Billy549: somehow the file cannot be found: ActionController::MissingFile (Cannot read file /opt/bitnami/discourse/public/uploads/default/original/1X/f6c7f5bc8823dce321212e28315c34837b880a0f.jpeg)</p>
</blockquote>
<p>The upload seems to succeed when looking in the network tab, with the "uploads.json" request returning the following:</p>
<pre><code>
{
"id": 48,
"url": "https://discourse.osmocom.org/uploads/default/original/1X/f6c7f5bc8823dce321212e28315c34837b880a0f.jpeg",
"original_filename": "external-avatar.jpeg",
"filesize": 24370,
"width": 360,
"height": 360,
"thumbnail_width": 360,
"thumbnail_height": 360,
"extension": "jpeg",
"short_url": "upload://zd7RVJpQ8a1mW4926l55LlaLJPV.jpeg",
"short_path": "/uploads/short-url/zd7RVJpQ8a1mW4926l55LlaLJPV.jpeg",
"retain_hours": null,
"human_filesize": "23.8 KB",
"dominant_color": "918782"
}
</code></pre> OsmoGSMTester - Bug #6126 (New): osmo-gsm-tester docker container uses debian 10https://osmocom.org/issues/61262023-08-01T09:33:57Zosmith
<p>osmo-gsm-tester in docker-playground.git is based on debian-buster-jenkins. I looked into upgrading it to debian 12, but as of writing the mongodb third-party repository it uses for running open5gs does not have binary packages for debian 12 yet: <a class="external" href="http://repo.mongodb.org/apt/debian/dists/">http://repo.mongodb.org/apt/debian/dists/</a></p>
<p>In theory we could adjust it to work with debian 11 currently, but that doesn't seem worth the effort.</p>
<p>I'll adjust the jenkins job to build debian-buster-jenkins before building osmo-gsm-tester, created this issue for future reference.</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>