Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-26T14:00:15ZOpen Source Mobile Communications
Redmine OsmoMGW - Bug #6424 (In Progress): TC_one_crcx_loopback_rtp_implicit consistently failing in mast...https://osmocom.org/issues/64242024-03-26T14:00:15Zlaforge
<p>`TC_one_crcx_loopback_rtp_implicit` appears to be failing consistently in master for 30+ consecutive builds. Meanwhile, the same test is passing just fine in latest. So there seems to be some (long-standing) regression in master?</p> OsmoBSC - Bug #6422 (Feedback): latest: BSC_Tests.TC_ctrl_location started fo fail on March 15thhttps://osmocom.org/issues/64222024-03-26T13:03:08Zlaforge
<ul>
<li><a class="external" href="https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/ttcn3-bsc-test-sccplite/test_results_analyzer/">https://jenkins.osmocom.org/jenkins/view/All%20no%20Gerrit/job/ttcn3-bsc-test-sccplite/test_results_analyzer/</a></li>
</ul>
<p>This test used to pass and started failing since March 15. It fails consistently ever since. Interestingly, master is not affected.</p>
<p>I don't see any commits to osmo-ttcn3-hacks.git touching the BSC code which were merged on March 14th.</p>
<p>Does anyone have any ideas?</p> 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) - Bug #6415 (New): osmo_panic after truncated packethttps://osmocom.org/issues/64152024-03-22T17:44:25Zpfassberg
<p>I'm running icE1usb connected to a Raspberry CM3 module.</p>
<p>A few times a day osmo-e1d crashes with the following output:<br /><pre>
Fri Mar 22 17:16:59 2024 DLINP octoi_clnt_fsm.c:242 OCTOI_CLIENT(N11MD)[0x55a37878e0]{ACCEPTED}: Rx OCTOI ECHO_RESP (seq=690, rtt=777)
Fri Mar 22 17:17:02 2024 DE1D usb.c:150 (I0:L0) IN EP 82 ISO packet truncated: len-4 = 173
Assert failed size % 32 == 0 mux_demux.c:450
backtrace() returned 19 addresses
/usr/local/lib/libosmocore.so.21(osmo_generate_backtrace+0x18) [0x7f83880f60]
/usr/local/lib/libosmocore.so.21(+0x30aa0) [0x7f838a0aa0]
/usr/local/lib/libosmocore.so.21(osmo_panic+0xd4) [0x7f838a0b78]
osmo-e1d(+0x6e8c) [0x557f4a6e8c]
osmo-e1d(+0x787c) [0x557f4a787c]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(+0xb1b4) [0x7f8381b1b4]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(+0x116ec) [0x7f838216ec]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(+0x1271c) [0x7f8382271c]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(+0xabc8) [0x7f8381abc8]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(libusb_handle_events_timeout_completed+0x218) [0x7f8381c09c]
/usr/local/lib/libosmousb.so.0(+0x1908) [0x7f83901908]
/usr/local/lib/libosmocore.so.21(+0x34398) [0x7f838a4398]
/usr/local/lib/libosmocore.so.21(+0x3450c) [0x7f838a450c]
/usr/local/lib/libosmocore.so.21(osmo_select_main+0x14) [0x7f838a4528]
osmo-e1d(+0x39a4) [0x557f4a39a4]
/lib/aarch64-linux-gnu/libc.so.6(+0x27780) [0x7f83627780]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98) [0x7f83627858]
osmo-e1d(+0x3bf0) [0x557f4a3bf0]
signal 6 received
</pre></p>
<p>As the packet is truncated something has gone wrong in the USB communication or maybe in the firmware, but I think that the process should not do abort but try to continue.</p>
<p>// Peter</p> OsmoMSC - Bug #6414 (Feedback): ttcn3-msc-test: TC_ho_inter_bsc_a5_[134] are failing with io_uringhttps://osmocom.org/issues/64142024-03-22T07:59:15Zfixeria
<p>Since recently, we started executing ttcn3-msc-test (among with some other testsuites) with <code>LIBOSMO_IO_BACKEND=IO_URING</code> in a separate job. Compared to the "normal" job, the IO_URING one exhibits a regression since <a href="https://jenkins.osmocom.org/jenkins/view/TTCN3-io_uring/job/ttcn3-msc-test-io_uring/5/" class="external">build 5</a> (Mar 15, 2024):</p>
<ul>
<li>TC_ho_inter_bsc_a5_3 is failing "reliably",</li>
<li>TC_ho_inter_bsc_a5_<sup><a href="#fn14">14</a></sup> are alternating between pass and fail.</li>
</ul>
<p>I was unable to reproduce the problem, neither locally on my machine nor on the dedicated build server in Docker env.</p> rtl-sdr - Bug #6413 (New): Incorrect Debian/Debian-like binary packageshttps://osmocom.org/issues/64132024-03-22T05:59:54ZFFY00
<p>Hi,</p>
<p>It seems the binary packages for Debian and Debian-like distributions, such as Ubuntu, for librtlsdr are incorrect.</p>
<p>You are shipping a librtlsdr0 package for 2.x version, which has a SO version with a major of 2. The correct package should be librtlsdr2. Not shipping a .so.0 in a librtlsdr0 package means that all software that was built against it will now result in an unresolved linker dependency.</p>
<p>With that said, I would also recommend the SO version to not be tied to the project version, as that would require all existing packages to be rebuilt against the new library package, even if there weren't any ABI changes. I don't know if there were any ABI changes between .so.0 and .so.2, but if there weren't, I would recommend for rtl-sdr 2.x to still ship a SO with a 0 major version (in this case, also a .so.2 now, since version 2.x has already been released with that SO name).</p>
<p>Cheers,<br />Filipe Laíns</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> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6396 (Feedback): add support for auth failu...https://osmocom.org/issues/63962024-03-08T15:41:35Zlynxis
<p>When a phone connects and the sim sequence numbers are out of sync, the authentication will fail<br />and the phone will additional supply Rand and Auts in the failure message.<br />Similar to the 3gpp rat.<br />The sgsn already has a test for this TC_attach_usim_resync.</p>
<p>To reproduce it with a real phone, you could decrease the sequence number in the hss. (AFAIR it is a sliding window, reducing the sequence number by 1 might not be enough).</p>
<pre>
UE - strongswan
<- Auth req
-> Auth failure (reason resync, auts, rand)
(HLR will update the sequence numbers)
<- Auth req
-> Auth succeed.
</pre> libosmocore - Bug #6393 (New): osmo_io conflating osmo_iofd_unregister vs osmo_iofd_closehttps://osmocom.org/issues/63932024-03-07T09:22:49Zlaforge
<p>I've been starting to work on something like an osmo_io API user manual, and as part of that tried to think about how to guard osmo_io against invalid usage.</p>
We have
<ul>
<li>osmo_iofd_unregister</li>
<li>osmo_iofd_close</li>
<li>osmo_iofd_free</li>
</ul>
Oddities:
<ul>
<li>osmo_iofd_unregister sets the IOFD_FLAG_CLOSED flag, even though it does not close
<ul>
<li>osmo_iofd_register clears the IOFD_FLAG_CLOSED, so there's some symmetry, despite the name</li>
</ul>
</li>
<li>osmo_iofd_close also sets the IOFD_FLAG_CLOSED flag, but without unregistering
<ul>
<li>this mean we cannot use the IOFD_FLAG_CLOSED to check in osmo_iofd_unregister if the iofd was already unregistered</li>
<li>it actually doesn't close the fd unless there is an osmo_iofd_ops.close call-back from the backend</li>
<li>however, it does always set iofd->fd to -1, so if no such call-back exists, we have a fd leak</li>
</ul>
</li>
<li>osmo_iofd_free calls osmo_iofd_close, but not osmo_iofd_unregister. So it somehow tries to do whatever is needed before the free, but only half of it.</li>
</ul>
<p>I'm not entirely sure yet how to untangle this. Maybe we need multiple flags to properly distinguish the closed from the unregistered state? Or maybe we don't need another flag and use iofd->fd == -1 to determine the actual closed status, and rename the CLOSED flag to n UNREGISTERED flag?</p> Core testing infrastructure - Bug #6386 (In Progress): eclipse-titan 9.0.0 not building in debian...https://osmocom.org/issues/63862024-03-02T15:54:57Zlaforge
<p>I just ran into bugs caused by running a too old version of eclipse-titan (8.2.0 provided by debian), since our 9.0.0 is not building on unstable: <a class="external" href="https://obs.osmocom.org/package/show/osmocom:latest/eclipse-titan">https://obs.osmocom.org/package/show/osmocom:latest/eclipse-titan</a></p>
<p>Please have a look, thanks!</p> Linux Kernel GTP-U - Bug #6382 (Feedback): "TC_pdp6_act_deact_gtpu_access" fails with kernel gtp-uhttps://osmocom.org/issues/63822024-03-01T17:08:19Zosmith
<p>Pau and I debugged why TC_pdp6_act_deact_gtpu_access does not work with osmo-ggsn with kernel gtp-u. It passes without kernel gtp-u.</p>
<blockquote>
<p>pespin: so I'd say that use case cannot really be performed right now as with current setup, but it's quite a specific one and not sure what would be the best desired behavior</p>
</blockquote>
<blockquote>
<p>pespin: so in summary: a GTP-U/IPv6(src-addr-link-local) arrives to the gtp kernel module (socket fd1u), and it decides the GGSN (userspace) needs to handle the packet, so the packet is pushed/read by osmo-ggsn, which in our current logic decides to forward the packet out of the tun. In order to do that, when we have a non-gtp generic tun, we use the tun FD to inject the decapsulted packet (IPv6(src-addr-link-local) into the network stack.</p>
</blockquote>
<blockquote>
<p>pespin: but when using the gtp tundev kind, we apparently do have the "tun fd" we need to inject decapsulated packets from the userspace program (osmo-ggsn), that only happens through the network stack internally.</p>
</blockquote>
<blockquote>
<p>pespin: So the question would be: 1- Can we somehow obtain an fd for the tun so we can inject decapsulated packets to it like we do in the userspace-gtp scenario? If yes, we should replace fd = -1 with that. If no, then we simply assume we don't want to inject those packets and discard them</p>
</blockquote>
<blockquote>
<p>pespin: feel free to create the ticket or point me to the existing one and I can fill in more info</p>
</blockquote>
<p><a href="#" onclick="$('#collapse-a57eae70-show, #collapse-a57eae70-hide').toggle(); $('#collapse-a57eae70').fadeToggle(150);; return false;" id="collapse-a57eae70-show" class="icon icon-collapsed collapsible">osmo-ggsn log + dmesg</a><a href="#" onclick="$('#collapse-a57eae70-show, #collapse-a57eae70-hide').toggle(); $('#collapse-a57eae70').fadeToggle(150);; return false;" id="collapse-a57eae70-hide" class="icon icon-expended collapsible" style="display:none;">osmo-ggsn log + dmesg</a><div id="collapse-a57eae70" 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> OsmoBSC - Bug #6378 (New): Ericsson DUG 20 rejects SI2quaterhttps://osmocom.org/issues/63782024-02-28T00:28:49Zkeith
<p>Sending SI2quater to the DUG20 results in</p>
<pre>
ERROR REPORT (cause=Radio Resource not available [ 21 01 80 ])
</pre>
<p>For what it may be worth, the SI and the error are in the attached pcap.</p>
<p>Maybe the BTS software version I have simply does not support it?</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6370 (In Progress): setup ims with kamailiohttps://osmocom.org/issues/63702024-02-20T19:53:27Zlynxis
<p>Setup kamailio as IMS to allow UEs to connect</p>
<p>PLMN: 901 / 70</p> OsmoPCU - Bug #6359 (Feedback): TbfTest: sporadic SEGV in https://osmocom.org/issues/63592024-02-13T09:37:52Zpespin
<p>This error showed up today in raspbian11 test:<br /><a class="external" href="https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=master,WITH_MANUALS=0,label=rpi4-raspbian11,with_dsp=none,with_vty=False/6448/console">https://jenkins.osmocom.org/jenkins/job/master-osmo-pcu/FIRMWARE_VERSION=master,WITH_MANUALS=0,label=rpi4-raspbian11,with_dsp=none,with_vty=False/6448/console</a></p>
<pre>
../../../tests/testsuite.at:28: $OSMO_QEMU $abs_top_builddir/tests/tbf/TbfTest
--- experr 2024-02-13 07:37:47.768562611 +0000
+++ /build/osmo-pcu-1.4.0.1-b04e1/_build/sub/tests/testsuite.dir/at-groups/4/stderr 2024-02-13 07:37:48.558541306 +0000
@@ -11580,18 +11580,16 @@
TBF(DL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN} Starting timer X2001 [assignment (PACCH)] with 2 sec. 0 microsec
DL_TBF(DL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN}: Received Event ASSIGN_PCUIF_CNF
TBF(DL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN} Ignoring event ASSIGN_PCUIF_CNF from BTS (CCCH was not requested on current assignment)
-DL_ASS_TBF(UL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){SEND_ASS}: Received Event CREATE_RLCMAC_MSG
-PDCH(bts=0,trx=0,ts=2) POLL scheduled at FN 0 + 13 = 13
-TBF(UL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN} start Packet Downlink Assignment (PACCH) for TBF(DL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN}
-+++++++++++++++++++++++++ TX : Packet Downlink Assignment +++++++++++++++++++++++++
-------------------------- TX : Packet Downlink Assignment -------------------------
-PDCH(bts=0,trx=0,ts=2) Reserving FN 13 for type POLL
-TBF(UL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN} Scheduled DL Assignment polling on PACCH (FN=13, TS=2)
-DL_ASS_TBF(UL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){SEND_ASS}: state_chg to WAIT_ACK
-PDCH(bts=0,trx=0,ts=2) FN=0 Scheduling control message at RTS for TBF(UL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN}
-=== end test_ms_merge_dl_tbf_different_trx ===
-MS(IMSI-001001000000001:TLLI-0xecc1f953:TA-220:MSCLS-11-0:UL:DL) Destroying MS object
-MS(IMSI-001001000000001:TLLI-0xecc1f953:TA-220:MSCLS-11-0:UL:DL) Detaching TBF: TBF(UL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN}
-MS(IMSI-001001000000001:TLLI-0xecc1f953:TA-220:MSCLS-11-0:DL): - tbf: now used by 1 (tbf)
-MS(IMSI-001001000000001:TLLI-0xecc1f953:TA-220:MSCLS-11-0:DL) Detaching TBF: TBF(DL:TFI-0-0-0:G:IMSI-001001000000001:TLLI-0xecc1f953){ASSIGN}
-MS(IMSI-001001000000001:TLLI-0xecc1f953:TA-220:MSCLS-11-0): - tbf: now used by 0 (-)
+UL_TBF(UL:TFI-0-0-0:G){ASSIGN}: Timeout of X2002
+UL_TBF(UL:TFI-0-0-0:G){ASSIGN}: Received Event ASSIGN_READY_CCCH
+../../../src/tbf_ul_fsm.c:173:3: runtime error: member access within null pointer of type 'struct GprsMs'
+AddressSanitizer:DEADLYSIGNAL
+=================================================================
+==1984==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000c (pc 0x00687b8e bp 0x1d52b65d sp 0xbeeb12b0 T0)
+==1984==The signal is caused by a READ memory access.
+==1984==Hint: address points to the zero page.
+ #0 0x687b8e in st_assign (/build/osmo-pcu-1.4.0.1-b04e1/_build/sub/tests/tbf/TbfTest+0x227b8e)
+
+AddressSanitizer can not provide additional info.
+SUMMARY: AddressSanitizer: SEGV (/build/osmo-pcu-1.4.0.1-b04e1/_build/sub/tests/tbf/TbfTest+0x227b8e) in st_assign
+==1984==ABORTING
stdout:
../../../tests/testsuite.at:28: exit code was 1, expected 0
4. testsuite.at:25: 4. tbf (testsuite.at:25): FAILED (testsuite.at:28)
</pre>
<p>At first sight it seems that something took longer than usual to run (due to load?) and then some event triggered which caused a SEGV.</p>
<p>I marked the job above as "Keep this build forever". It can be unmarked once this issue is looked at.<br />I also upload here the build artifacts of the job just in case.</p> Cellular Network Infrastructure - Bug #6352 (Stalled): ttcn3-bts-test[-latest] is broken since Fe...https://osmocom.org/issues/63522024-02-05T09:25:36Zfixeria
<p>ttcn3-bts-test[-latest] is failing for a few days already:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/</a></p>
<p>The console log (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console</a>) tells us about problems with the virtphy:</p>
<pre>
+ docker kill jenkins-ttcn3-bts-test-2293-virtphy
Error response from daemon: Cannot kill container: jenkins-ttcn3-bts-test-2293-virtphy: No such container: jenkins-ttcn3-bts-test-2293-virtphy
</pre>
<p>Here is the related logging (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log</a>):</p>
<pre>
0: starting: osmo-bts-virtual -c /data/osmo-bts.gen.cfg
((*))
|
/ \ OsmoBTS
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853486 DLGLOBAL NOTICE Setting up GSMTAP Um forwarding '(null)->'172.18.29.10:4729' (main.c:363)
20240201061853486 DLCTRL NOTICE CTRL at 0.0.0.0 4238 (control_if.c:1014)
20240201061853487 DL1C NOTICE Unimplemented bts_model_ctrl_cmds_install (bts_model.c:222)
20240201061853487 DLGLOBAL NOTICE Available via telnet 0.0.0.0 4241 (telnet_interface.c:88)
20240201061853487 DPCU INFO Started listening on PCU socket (PCU IF v12): /data/unix/pcu_sock (pcu_sock.c:1237)
20240201061853487 DOSMUX INFO Osmux socket listening on 172.18.29.20:1984 (osmux.c:352)
20240201061853487 DABIS NOTICE A-bis connection establishment to BSC (127.0.0.11) in progress... (abis.c:161)
20240201061853487 DLINP NOTICE enabling ipaccess BTS mode, OML connecting to 127.0.0.11:3002 (ipaccess.c:1098)
20240201061853487 DL1C INFO phy0: PHY link state change shutdown -> connecting (phy_link.c:58)
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
20240201061853487 DL1C INFO phy0: PHY link state change connecting -> shutdown (phy_link.c:58)
unable to open PHY link(s)
0: stopped pid 8 with status 2
</pre>
<p>The virtphy container (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log</a>) fails to start:</p>
<pre>
Thu Feb 1 06:18:53 2024 DVIRPHY virtphy.c:248 Virtual physical layer starting up...
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
Segmentation fault (core dumped)
</pre> OsmoSGSN - Bug #6197 (Feedback): "Cannot handle SM for unknown MM CTX"https://osmocom.org/issues/61972023-09-28T14:32:29Zfixeria
<p>I am observing relatively long PDP Context activation with Sony Ericsson K800i and recent osmo-sgsn:</p>
<p>osmo-sgsn 1.11.0<br />osmo-pcu 1.3.1.1-c1b0</p>
<p>I don't remember if this was the case before, most likely not.</p>
<p>As can be seen from the attached PCAP, the MS orders a PDP Context activation right after completing the Attach (frame 259):</p>
<pre>
130 16.160906108 127.0.0.1 → 127.0.0.1 GPRS-LLC 107 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Attach Request
156 16.161190149 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Identity Request
157 16.797408334 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 1(DTAP) (GMM) Identity Response
173 16.797533278 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 1(DTAP) (GMM) Identity Request
181 17.200282825 127.0.0.1 → 127.0.0.1 GPRS-LLC 86 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 2(DTAP) (GMM) Identity Response
226 17.225222456 127.0.0.1 → 127.0.0.1 GPRS-LLC 113 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 2(DTAP) (GMM) Attach Accept
239 17.697504097 127.0.0.1 → 127.0.0.1 GPRS-LLC 77 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 3(DTAP) (GMM) Attach Complete
259 17.739056217 127.0.0.1 → 127.0.0.1 GPRS-LLC 136 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 4(DTAP) (SM) Activate PDP Context Request <-- (!)
274 17.739270297 127.0.0.1 → 127.0.0.1 GPRS-LLC 76 SAPI: LLGMM, U, XID
275 17.739280476 127.0.0.1 → 127.0.0.1 GPRS-LLC 75 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Detach Request <-- (!)
</pre>
<p>The SGSN is responding with GMM Detach Request (frame 275), here is the related logging:</p>
<pre>
259 17.739056217 127.0.0.1 → 127.0.0.1 GPRS-LLC 136 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 4(DTAP) (SM) Activate PDP Context Request
260 17.739109847 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Rx NS-UNITDATA
261 17.739128332 127.0.0.1 → 127.0.5.1 GSMTAP 263 GPRS-NS2-VC(UDP-NSE00101-NSVC00101-0_0_0_0:23000-127_0_0_1:23023)[0x55e69ba253d0]{UNBLOCKED}: Received Event RX-UNITDATA
262 17.739139873 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Rx NS-UNITDATA
263 17.739148439 127.0.0.1 → 127.0.5.1 GSMTAP 183 BSSGP TLLI=0x85c79efb Rx UPLINK-UNITDATA
264 17.739181411 127.0.0.1 → 127.0.5.1 GSMTAP 236 LLME(ffffffff/85c79efb){UNASSIGNED} LLC RX: unknown TLLI 0x85c79efb, creating LLME on the fly
265 17.739188394 127.0.0.1 → 127.0.5.1 GSMTAP 193 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x3ef88c
266 17.739193033 127.0.0.1 → 127.0.5.1 GSMTAP 149 CMD=UI
267 17.739196720 127.0.0.1 → 127.0.5.1 GSMTAP 147 DATA
268 17.739200627 127.0.0.1 → 127.0.5.1 GSMTAP 143
269 17.739212048 127.0.0.1 → 127.0.5.1 GSMTAP 214 LLME(ffffffff/85c79efb){UNASSIGNED} Cannot handle SM for unknown MM CTX
270 17.739224792 127.0.0.1 → 127.0.5.1 GSMTAP 198 LLME(ffffffff/85c79efb){UNASSIGNED} LLGM Reset (SAPI=1)
271 17.739243207 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Tx NS-UNITDATA
272 17.739252294 127.0.0.1 → 127.0.5.1 GSMTAP 215 <- GMM DETACH REQ (type: re-attach required, cause: Implicitly detached)
273 17.739257293 127.0.0.1 → 127.0.5.1 GSMTAP 180 NSE(00101)-NSVC(00101) Tx NS-UNITDATA
274 17.739270297 127.0.0.1 → 127.0.0.1 GPRS-LLC 76 SAPI: LLGMM, U, XID
275 17.739280476 127.0.0.1 → 127.0.0.1 GPRS-LLC 75 SAPI: LLGMM, UI, protected, non-ciphered information, N(U) = 0(DTAP) (GMM) Detach Request
</pre>
<p>The MS repeats the request again (frame 517) 30 seconds after the first attempt, and finally gets a PDP Context activated.<br />The key difference between frames 259 (first attempt) and 517 (second attempt) is TLLI indicated in the BSSGP header.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6091 (Feedback): osmo-epdg: Implement CEAI ...https://osmocom.org/issues/60912023-07-10T17:09:19Zlynxis
<p>Write all relevant parts to have a gsup server module which the strongswan can connect to it.</p> osmo-ePDG - VoWifi Evolved Packet Data Gateway - Bug #6045 (Feedback): report erlang diameter pro...https://osmocom.org/issues/60452023-05-26T11:49:29Zlynxis
<p>Somehow is the erlang diameter code not generating all AVPs. I've the feeling it doesn't have enough inherits layer. e.g. when a dia spec inherits from another spec, from another spec, .. it comes to a limit without a failure. In the end the decoding of messages fails.</p>
<p>Create a test case with github repo to report the issue.</p> OsmoBTS - Bug #5953 (Feedback): ttcn3-bts-test: TC_ms_pwr_ctrl_{constant,pf_ewma} are failinghttps://osmocom.org/issues/59532023-03-21T12:57:05Zfixeria
<p>These two testcases were added by me back in 2020 and have been passing until recently:</p>
<pre>
commit c7ef03057fe6644372b8bf08c165afef29fc600f
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sun Oct 18 19:24:18 2020 +0700
BTS_Tests: introduce TC_ms_pwr_ctrl_constant()
Unexpected MS Power level change: 7 -> 13
BTS_Tests.ttcn:9052 BTS_Tests control part
BTS_Tests.ttcn:8111 TC_ms_pwr_ctrl_constant testcase
</pre>
<pre>
commit 652e60eb83f928036a649fa45f7a4a4eb8207eac
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Sun Oct 18 19:43:27 2020 +0700
BTS_Tests: add TC_ms_pwr_ctrl_pf_ewma: test EWMA based power filtering
Unexpected MS Power level change: 7 -> 13
BTS_Tests.ttcn:9053 BTS_Tests control part
BTS_Tests.ttcn:8178 TC_ms_pwr_ctrl_pf_ewma testcase
</pre>
<p>The "red age" of both TCs is 102 days ago for both -master and -latest.<br />I guess this might be related to the recent changes in osmocom-bb.git/trxcon.</p> 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> Core testing infrastructure - Bug #5301 (Stalled): Run TTCN3 docker tests with sanitizer enabledhttps://osmocom.org/issues/53012021-11-10T10:49:12Zdaniel
<p>After updating libosmocore I noticed that the TTCN3 GbProxy tests start to fail with an ASan issue when run locally.</p>
<p>I think at least for the TTCN3 tests on master we should enable <code>*San</code> to catch hidden bugs early. Unfortunately this has a large impact on how the <code>osmo-*-master</code> docker images are built if we want to enable it for the libraries as well - currently we install the nightly packages and build the target from master.</p>
<p>Instead we could build an image that builds all the libraries from master (with sanitizer enabled) and installs those and then use that as base for osmo-*-master.</p>
<p>Not sure what the downsides are, any ideas?</p> OsmoHNBGW - Bug #4933 (New): Femtocell choice in U.K 2021/01https://osmocom.org/issues/49332021-01-03T13:55:43ZcopslockOsmoMSC - Bug #4721 (In Progress): osmo-msc creates evil-twin entries in the VLR when an already ...https://osmocom.org/issues/47212020-08-19T06:24:05Zlaforge
<p>When running this test locally against a (sanitize-enabled) osmo-msc, I get sporadic failures.</p>
<p>The differnence in the log files seems to start:</p>
<p>successful case:<br /><pre>
Wed Aug 19 08:10:24 2020 DVLR <000e> gsm_04_08.c:1394 SUBSCR(IMSI-262420000000013:MSISDN-491230000013:TMSI-0x01020304) VLR: update for IMSI=262420000000013 (MSISDN=491230000013)
</pre></p>
<p>failing case:<br /><pre>
Wed Aug 19 08:10:29 2020 DVLR <000e> gsm_04_08.c:1394 SUBSCR(IMSI-262420000000013:MSISDN-491230000013:TMSI-0x3BEDCD7C) VLR: update for IMSI=262420000000013 (MSISDN=491230000013) (NO CONN!)
</pre></p>
<p>The pcap file containing both cases is attached. They seem exactly identical, it's just that in the first (successful) case, there is a LU ACCEPT immediately, while in the second (failing) case, there is a LU REJECT after timeout of 5s.</p>
<p>I've seen the failure both when running a single test case, as well as when running the entire MSC_Tests.control in one batch.</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> Linux Kernel GTP-U - Bug #1952 (In Progress): IPv6 support for inner (user) IP layer missinghttps://osmocom.org/issues/19522017-02-18T12:29:29Zlaforge
<p>The 3GPP specs permit for both IPv4 and IPv6, but we only implement IPv4. This is embarrassing and should be changed. Contribution welcome!</p>