Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-03-19T19:33:49ZOpen Source Mobile Communications
Redmine libosmocore - Bug #6410 (New): osmo_io poll backend doesn't work on file descriptors that are not...https://projects.osmocom.org/issues/64102024-03-19T19:33:49Zlaforge
<p>I just wanted to use osmo_io on a file descriptor pointing to an actual file, not a socket.</p>
<p>The poll backend fails as it unconditionally tries to use sendmsg, even if the mode is READ_WRITE.</p> libosmocore - Bug #6393 (New): osmo_io conflating osmo_iofd_unregister vs osmo_iofd_closehttps://projects.osmocom.org/issues/63932024-03-07T09:22:49Zlaforge
<p>I've been starting to work on something like an osmo_io API user manual, and as part of that tried to think about how to guard osmo_io against invalid usage.</p>
We have
<ul>
<li>osmo_iofd_unregister</li>
<li>osmo_iofd_close</li>
<li>osmo_iofd_free</li>
</ul>
Oddities:
<ul>
<li>osmo_iofd_unregister sets the IOFD_FLAG_CLOSED flag, even though it does not close
<ul>
<li>osmo_iofd_register clears the IOFD_FLAG_CLOSED, so there's some symmetry, despite the name</li>
</ul>
</li>
<li>osmo_iofd_close also sets the IOFD_FLAG_CLOSED flag, but without unregistering
<ul>
<li>this mean we cannot use the IOFD_FLAG_CLOSED to check in osmo_iofd_unregister if the iofd was already unregistered</li>
<li>it actually doesn't close the fd unless there is an osmo_iofd_ops.close call-back from the backend</li>
<li>however, it does always set iofd->fd to -1, so if no such call-back exists, we have a fd leak</li>
</ul>
</li>
<li>osmo_iofd_free calls osmo_iofd_close, but not osmo_iofd_unregister. So it somehow tries to do whatever is needed before the free, but only half of it.</li>
</ul>
<p>I'm not entirely sure yet how to untangle this. Maybe we need multiple flags to properly distinguish the closed from the unregistered state? Or maybe we don't need another flag and use iofd->fd == -1 to determine the actual closed status, and rename the CLOSED flag to n UNREGISTERED flag?</p> pySim - Bug #6314 (New): pySim-trace doesn't support ARA-Mhttps://projects.osmocom.org/issues/63142023-12-23T09:31:02Zlaforge
<p>during execution of our pySim-shell test, even with the included pcap we're getting:</p>
<pre>
WARNING pySim.apdu.ts_102_221: SELECT UNKNOWN AID a00000015141434c00
</pre>
<p>the AID is that of the ARA-M applet. We do support ARA-M in pySim-shell. However, we do not appear to use that code from pySim-shell, probably related to the AID auto-detection missing.</p> Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Bug #6291 (New): 2024 event bringing tog...https://projects.osmocom.org/issues/62912023-12-06T14:31:01Zlaforge
<p>I've been considering this for a number of years, but never actually got aroun to acting on it:</p>
<p>Have an event where the various FOSS mobile communications projects meet, get to know each other and exchange status, plans and ideas.</p>
<p>Matthias Kirschner of the FSFE suggested to <em>attach</em> that event to sfscon (<a class="external" href="https://www.sfscon.it/">https://www.sfscon.it/</a>) and do it a few days ahead (or after) the 2024 incarnation, which is likely happning again in November 2024. The FSFE could help with funding of the related expenses from a donation made by sysmocom to FSFE earmarked to help FOSS in mobile communications.</p>
<p>Let's use this issue to collect a list of projects we'd want to invite, and to generally keep track on status.</p>
<p>For now, I am thinking of the following potential projects:</p>
<a name="cellular-infrastructureprotocol-stacks"></a>
<h2 >cellular infrastructure/protocol stacks<a href="#cellular-infrastructureprotocol-stacks" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://osmocom.org/" class="external">Osmocom</a></li>
<li><a href="https://open5gs.org/" class="external">open5gs</a></li>
<li><a href="https://www.srslte.com/" class="external">srsRAN/srsUE</a></li>
<li><a href="https://free5gc.org/" class="external">free5gc</a></li>
<li><a href="https://github.com/edgecomllc/eupf" class="external">eupf</a></li>
<li><a href="https://github.com/travelping/ergw" class="external">ergw</a></li>
<li><a href="https://magmacore.org/" class="external">Magma</a> + <a href="https://github.com/magma/S1APTester" class="external">S1APTester</a></li>
<li><a href="https://github.com/omec-project" class="external">OMEC</a></li>
<li><a href="https://github.com/wmnsk" class="external">wmnsk</a> and his various go-{gtp,pfcp,m3ua,sccp,tcap} projects</li>
</ul>
<a name="SIM-card-related-projects"></a>
<h2 >SIM card related projects<a href="#SIM-card-related-projects" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://github.com/tomasz-lisowski/swsim" class="external">swsim</a> + <a href="https://github.com/tomasz-lisowski/swicc" class="external">swicc</a></li>
</ul>
<a name="Development-Debugging"></a>
<h2 >Development + Debugging<a href="#Development-Debugging" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://github.com/fgsect/scat" class="external">SCAT</a></li>
<li><a href="https://github.com/P1sec/QCSuper" class="external">QCsuper</a></li>
<li><a href="https://github.com/PentHertz/Modmobmap" class="external">Modmobmap</a></li>
<li><a href="https://github.com/SysSec-KAIST/LTESniffer" class="external">LTESniffer</a></li>
<li><a href="https://github.com/falkenber9/falcon" class="external">FALCON</a></li>
<li><a href="https://github.com/aligungr/UERANSIM" class="external">UERANSIM</a></li>
<li><a href="https://github.com/HewlettPackard/PacketRusher" class="external">PacketRusher</a></li>
<li>the various projects by <a href="https://github.com/fasferraz" class="external">fasferraz</a> (Swu-IKEv2, ...)</li>
<li><a href="https://github.com/P1sec/pycrate" class="external">pycrate</a></li>
</ul>
<a name="FOSS-software-stacks-on-mobile-devices"></a>
<h2 >FOSS software stacks on mobile devices<a href="#FOSS-software-stacks-on-mobile-devices" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://postmarketos.org/" class="external">postmarketos</a></li>
<li><a href="https://replicant.us/" class="external">replicant</a></li>
<li><a href="https://ubuntu-touch.io/" class="external">Ubuntu touch</a></li>
</ul>
<p>I'm very happy to accept further suggestions for projects/people to add to the invite list.</p> OCTOI - Osmocom Community TDM over IP - Bug #6282 (New): high BERT from laforge->divf->manawyrmhttps://projects.osmocom.org/issues/62822023-12-03T16:03:26Zlaforge
<p>When doing a BERT test from laforge via divf to manawyrm, I'm seeing 190..580 bit errors in the 1min test call to 030-65028003. This might be related to my yate upgrade earlier today. However, I'm confident all relevant zapcard patches have previously been merged to master.</p>
<p>Any ideas? Can you have a look, please?</p>
<p>I cannot test the BERT on DIVF directly as the old "call never connects" bug for loopback/wavplay is back: <a class="issue tracker-1 status-1 priority-2 priority-default" title="Bug: divf yate: calls to wave playback or loopback never connect (New)" href="https://projects.osmocom.org/issues/6281">#6281</a></p> OCTOI - Osmocom Community TDM over IP - Bug #6281 (New): divf yate: calls to wave playback or loo...https://projects.osmocom.org/issues/62812023-12-03T16:03:18Zlaforge
<p>I think we've had this problem before, but I don't recall how we worked around it. For sure after my yate upgrade (or the diaplan changes yesterday) we get the following behaviour:</p>
<ul>
<li>loopback doesn't ever answer</li>
<li>wave playback happens at early audio before the call ever connects</li>
</ul>
<p>any ideas?</p> OCTOI - Osmocom Community TDM over IP - Bug #6274 (New): yate is eating 260% CPU while doing nothinghttps://projects.osmocom.org/issues/62742023-11-25T14:31:20Zlaforge
<p>Something seems wrong if an idle yate doing nothing consumes about 260% CPU.</p>
<p>Looking at the yate threads, we can see that each <code>Zap Worker</code> consumes 10..12% of CPU while doing nothing:<br /><img src="https://projects.osmocom.org/attachments/download/7154/yate-cpu.png" alt="" /></p>
<p>This is quite weird, especially considering that osmo-e1d with 23 trunkdevs in parallel only uses 20% CPU - while actually processing packets/frames for all of those trunks.</p>
<p>a strace of such a single Zap Worker thread looks like this:<br /><pre>
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
</pre></p>
<p>So basically we're using select to check if data on a single FD has arrived, time-out after 100 microseconds and then call a zero-nanoseconds sleep and start all-over again.</p>
<p>Looking at the source code, this looks like extremely poor programming style:<br /><pre><code class="c++ syntaxhl"><span class="c1">// Process incoming data</span>
<span class="kt">bool</span> <span class="n">ZapInterface</span><span class="o">::</span><span class="n">process</span><span class="p">()</span>
<span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">m_device</span><span class="p">.</span><span class="n">select</span><span class="p">(</span><span class="mi">100</span><span class="p">))</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">m_device</span><span class="p">.</span><span class="n">canRead</span><span class="p">())</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">m_device</span><span class="p">.</span><span class="n">event</span><span class="p">())</span>
<span class="n">checkEvents</span><span class="p">();</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="p">}</span>
<span class="kt">int</span> <span class="n">r</span> <span class="o">=</span> <span class="n">m_device</span><span class="p">.</span><span class="n">recv</span><span class="p">(</span><span class="n">m_buffer</span><span class="p">,</span><span class="n">m_bufsize</span> <span class="o">+</span> <span class="n">ZAP_CRC_LEN</span><span class="p">);</span>
<span class="k">if</span> <span class="p">(</span><span class="n">r</span> <span class="o">==</span> <span class="o">-</span><span class="mi">1</span><span class="p">)</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">m_device</span><span class="p">.</span><span class="n">event</span><span class="p">())</span>
<span class="n">checkEvents</span><span class="p">();</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="p">}</span>
<span class="k">if</span> <span class="p">(</span><span class="n">r</span> <span class="o">&</span><span class="n">lt</span><span class="p">;</span> <span class="n">ZAP_CRC_LEN</span> <span class="o">+</span> <span class="mi">1</span><span class="p">)</span> <span class="p">{</span>
<span class="n">Debug</span><span class="p">(</span><span class="k">this</span><span class="p">,</span><span class="n">DebugMild</span><span class="p">,</span><span class="s">"Short read %u bytes (with CRC) [%p]"</span><span class="p">,</span><span class="n">r</span><span class="p">,</span><span class="k">this</span><span class="p">);</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="p">}</span>
<span class="n">s_ifaceNotifyMutex</span><span class="p">.</span><span class="n">lock</span><span class="p">();</span>
<span class="n">m_notify</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
<span class="n">s_ifaceNotifyMutex</span><span class="p">.</span><span class="n">unlock</span><span class="p">();</span>
<span class="n">DataBlock</span> <span class="n">packet</span><span class="p">(</span><span class="n">m_buffer</span><span class="p">,</span><span class="n">r</span> <span class="o">-</span> <span class="n">ZAP_CRC_LEN</span><span class="p">,</span><span class="nb">false</span><span class="p">);</span>
<span class="cp">#ifdef XDEBUG
</span> <span class="n">String</span> <span class="n">hex</span><span class="p">;</span>
<span class="n">hex</span><span class="p">.</span><span class="n">hexify</span><span class="p">(</span><span class="n">packet</span><span class="p">.</span><span class="n">data</span><span class="p">(),</span><span class="n">packet</span><span class="p">.</span><span class="n">length</span><span class="p">(),</span><span class="sc">' '</span><span class="p">);</span>
<span class="n">Debug</span><span class="p">(</span><span class="k">this</span><span class="p">,</span><span class="n">DebugAll</span><span class="p">,</span><span class="s">"Received data: %s [%p]"</span><span class="p">,</span><span class="n">hex</span><span class="p">.</span><span class="n">safe</span><span class="p">(),</span><span class="k">this</span><span class="p">);</span>
<span class="cp">#endif
</span> <span class="n">receivedPacket</span><span class="p">(</span><span class="n">packet</span><span class="p">);</span>
<span class="n">packet</span><span class="p">.</span><span class="n">clear</span><span class="p">(</span><span class="nb">false</span><span class="p">);</span>
<span class="k">return</span> <span class="nb">true</span><span class="p">;</span>
<span class="p">}</span>
<span class="kt">void</span> <span class="n">ZapWorkerThread</span><span class="o">::</span><span class="n">run</span><span class="p">()</span>
<span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">m_client</span><span class="p">)</span>
<span class="k">return</span><span class="p">;</span>
<span class="n">DDebug</span><span class="p">(</span><span class="o">&</span><span class="n">plugin</span><span class="p">,</span><span class="n">DebugAll</span><span class="p">,</span><span class="s">"%s is running for client (%p): %s"</span><span class="p">,</span>
<span class="n">s_threadName</span><span class="p">,</span><span class="n">m_client</span><span class="p">,</span><span class="n">m_address</span><span class="p">.</span><span class="n">c_str</span><span class="p">());</span>
<span class="k">while</span> <span class="p">(</span><span class="nb">true</span><span class="p">)</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">m_client</span><span class="o">-&</span><span class="n">gt</span><span class="p">;</span><span class="n">process</span><span class="p">())</span>
<span class="n">Thread</span><span class="o">::</span><span class="n">check</span><span class="p">(</span><span class="nb">true</span><span class="p">);</span>
<span class="k">else</span>
<span class="n">Thread</span><span class="o">::</span><span class="n">yield</span><span class="p">(</span><span class="nb">true</span><span class="p">);</span>
<span class="p">}</span>
<span class="p">}</span>
</pre></p>
<p>So basically the thread is continuously calling Thread:yield rather than waiting on some actual I/O to happen.</p></code></pre> rtl-sdr - Bug #6225 (New): rtl-sdr reelase tarballs missing from https://ftp.osmocom.org/releases/https://projects.osmocom.org/issues/62252023-10-18T17:05:38ZlaforgeOsmoSGSN - Bug #6176 (New): build failure (dependency / concurrency issue)https://projects.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> OsmoBTS - Bug #5957 (New): not all osmo-bts variants respond to abisip-findhttps://projects.osmocom.org/issues/59572023-03-22T09:20:14Zlaforge
<p>The abisip-find utility uses brodcast UDP packets to obtain a list of all BTSs reachable via the local network segment using the <code>abisip-find</code> utility (part of osmo-bsc source code).</p>
<p>For some reason unknown to me, this functionality is implemented as part of osmobts-{sysmo,lc15,oc2g}-mgr, and not part of the normal osm-bts-* program. This means that osmo-bts-trx doesn't suppport the feature.</p>
<p>Looking at <code>{oc2g,lc15,sysmo}bts_mgr_nl.c</code> in the sourec code, the only difference is the code obtaining parameters such as serial number, BTS model name and Ethernet MAC adress.</p>
IMHO, the code could be unified to have
<ul>
<li>one common/shared implementation, that
<ul>
<li>becomes part of the normal osmo-bts binary</li>
<li>gets passed in the model-specific information via some struct from the model-specific part when initialized</li>
</ul></li>
</ul>
<p>Assigning to <a class="user active" href="https://projects.osmocom.org/users/42">jolly</a> (for after april 1st)</p>
<p>Afterwards, <a class="external" href="https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/32004">https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/32004</a> can be merged to update documentation</p> osmo-remsim - Bug #5891 (New): bankd: potential pthread deadlock reported by coverityhttps://projects.osmocom.org/issues/58912023-02-03T19:35:22Zlaforge
<pre>
*** CID 307529: Program hangs (ORDER_REVERSAL)
/source-Osmocom/osmo-remsim/src/server/rspro_server.c: 782 in event_fd_cb()
776 }
777
778 LOGP(DMAIN, LOGL_INFO, "Event FD arrived, checking for any pending work\n");
779
780 pthread_rwlock_rdlock(&srv->rwlock);
781 llist_for_each_entry(conn, &srv->banks, list) {
>>> CID 307529: Program hangs (ORDER_REVERSAL)
>>> Calling "pthread_rwlock_rdlock" acquires lock "slotmaps.rwlock" while holding lock
"rspro_server.rwlock" (count: 2 / 5).
782 slotmaps_rdlock(srv->slotmaps);
783 non_empty_new = llist_empty(&conn->bank.maps_new);
784 non_empty_del = llist_empty(&conn->bank.maps_delreq);
785 slotmaps_unlock(srv->slotmaps);
786
787 /* trigger FSM to send any pending new/deleted maps */
</pre> SDR (Software Defined Radio) - Bug #5850 (New): OBS mingw builds not updated since 2019https://projects.osmocom.org/issues/58502023-01-04T12:14:33Zlaforge
<p>We do have <code>network:osmocom:mingw</code> windows builds of rtl-sdr and osmo-fl2k for 32bit and 64bit systems at <a class="external" href="https://build.opensuse.org/project/subprojects/network:osmocom:mingw">https://build.opensuse.org/project/subprojects/network:osmocom:mingw</a> - which don't appear to have seen any updates since 2019.</p>
<p>I guess we should either make sure they are updated, or remove them altogether.</p>
<p>If we want to keep them updated/maintained, we might also want to migrate them to <a class="external" href="https://obs.osmocom.org/">https://obs.osmocom.org/</a> where all our other builds are done these days.</p> OsmocomBB - Bug #5822 (New): SE K2x0i: missing RF and AFC paramshttps://projects.osmocom.org/issues/58222022-12-09T12:30:23Zlaforge
<p>From <a class="user active" href="https://projects.osmocom.org/users/308579">falconia</a> commenting in <a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/30051">https://gerrit.osmocom.org/c/osmocom-bb/+/30051</a></p>
<blockquote>
<p>RF tables: look in my freecalypso-reveng repository, se_k200i directory - the rf_XXX.c files you'll find there are extracts from original fw. Basically you would need to copy gta0x/rf_tables.c, keep the levels tables unchanged (SE fw left them unchanged from TI's version too, as you can see in my rf_XXX.c extracts), but replace all ramps with those from se_k200i/rf_XXX.c files. However, what APC offset is used by the original fw is the big unknown, and if it's wrong, all levels will off despite reading calibration records - this part is always a bummer.</p>
<p>AFC params: use "tiffs $flashdump 256x13 decode afcparams" to look at factory numbers on a few units, then use my little osmo2psi hack in freecalypso-reveng to find an AFC slope number in your style that is approximately close.</p>
</blockquote> libosmo-abis - Bug #5756 (New): io_uring support in libosmo-abishttps://projects.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://projects.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> osmo-e1d - Bug #5735 (New): ctl client disconnect doesn't re-set timeslot statehttps://projects.osmocom.org/issues/57352022-11-01T16:28:35Zlaforge
When a ctl client socket gets closed (client disconnects/crashes), we are cleaning up that ctl socket, but we don't clean up other state, such as
<ul>
<li>the fact that a given timeslot is no longer open (subsequent open of that TS gets a "cannot re-open unless FORCE option is used" error)</li>
<li>the socketpair() file-descriptors for the per-timeslot data are not closed</li>
</ul>
<p>It's currently not possible to fix this directly, as nothing in osmo-e1d tracks the relationship of client<->timeslot. So without that state, we cannot clean up.</p> Retronetworking - Bug #5681 (New): Figure out suitable connectors for EKSOShttps://projects.osmocom.org/issues/56812022-09-15T15:47:06Zlaforge
<p>While we did receive a few cables for EKSOS, many of them are missing, so I am looking for suitable alternative cables.</p>
<ul>
<li>EKSOS shelf DC power connector is confirmed to be a TE 350766-1 (contacts for 2.5mm2 wire: 640310-3)</li>
<li>EKSOS NCU E1 connector is <em>almost</em> a Harting 09232326824. Almost in that the clip-on frame has some notches, so the clip-on guide would have to be removed.</li>
<li>EKSOS POTS/ISDN line card subscriber line conncetor is <strong>not</strong> a typical 32pin 3-row DIN "C" connector. While both the EKSOS and this connector have pins every second position in the outer two rows, the order is exactly reversed: The standard DIN Connector has pins where EKSOS has none, and vice versa. A 64pos DIN C connector should work, assuming one then simply doesn't use every second pin present.</li>
</ul>
<p>The original manfacturer of those connectors (Perlos corporation of Joensuu, Finland) <a href="https://www.thefreelibrary.com/Finland%27s+Perlos+Corporation+sells+Special+Products+and+Connectors...-a0163748830" class="external">sold the connector business to Valuukumpu/M2 LTD in 2007</a></p>
<p><a href="https://www.cambridgeelectronics.com/DIN-41612-connectors" class="external">Cambridge Electronics</a> seems to be selling compatible connectors for at least some configurations, using seemingly the same retention lock / frame construction as featured on the EKSOS units.</p> Misc Hardware Projects - Bug #5672 (New): sfp-experimenter / voltage swing of LVDS driver insuffi...https://projects.osmocom.org/issues/56722022-09-02T15:27:24Zlaforge
<p>I'm surprised this never caused any problems, but</p>
<ul>
<li>the SFP MSA speifies _The inputs will accept differential swings of 500 – 2400 mV (250 – 1200 mV single-ended), though it is recommended that values between 500 and 1200 mV differential (250 – 600 mV single-ended) be used for best EMI performance.</li>
<li>the LVDS driver we use states <em>The outputs comply with the TIA/EIA-644 standard and provide a minimum differential output voltage magnitude of 247 mV into a 100-Ω load at signaling rates up to 630 Mbps...</em></li>
</ul>
<p>So the differential magnitude of the driver is much lower t han the SFP MSA requires it to be.</p>
<p>I guess real-world SFP transceivers appear to be much more sensitive and accept lower voltage swings - and hence we never saw that problem so far.</p> osmo-remsim - Bug #5628 (New): client-st2: error mesasges when mapping is removedhttps://projects.osmocom.org/issues/56282022-07-24T07:14:57Zlaforge
<pre>
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DLINP NOTICE simtrace2_api.c:168 [0] <= osmo_st2_cardem_request_card_insert(inserted=0)
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DLINP NOTICE simtrace2_api.c:317 [0] <= _modem_sim_select(remote_sim=0)
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DLINP NOTICE simtrace2_api.c:285 [0] <= _modem_reset(asserted=2, pulse_ms=300)
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DRSPRO ERROR ../rspro_client_fsm.c:359 RSPRO_CLIENT(bankd){CONNECTED}: Event SRVC_E_KA_TERMINATED not permitted
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DRSPRO INFO ../rspro_client_fsm.c:363 RSPRO_CLIENT(bankd){CONNECTED}: Destroying existing connection to server
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DMAIN ERROR ../rspro_client_fsm.c:279 CLIENT_MAIN(main){UNCONFIGURED}: Event MF_E_BANKD_LOST not permitted
</pre>
<p>not a big deal, but removing a mapping is normal business, it shoulnd't result in error messages.</p> OsmoCBC - Bug #5585 (New): CBC should not send WRITE-REPLACE to cells that had sent FAILUREhttps://projects.osmocom.org/issues/55852022-06-21T09:41:51Zlaforge
<p>TS 48.049 states about the CBC behaviour :</p>
<blockquote>
<p>Upon receipt of the FAILURE message, the CBC shall not initiate further WRITE-REPLACE messages for concerned cell(s) until the CBC is informed, by the RESTART message, that the cell(s) have resumed CBS message operational state or emergency message operational state again.</p>
</blockquote>
<p>However, osmo-cbc is currently still sending WRITE-REPLACE in such situations.</p> libosmo-sccp + libosmo-sigtran - Bug #5561 (New): pc=0=0.0.0 / RCOC-ERROR.ind not permittedhttps://projects.osmocom.org/issues/55612022-05-13T18:03:28Zlaforge
<p>On a rhizomatica deployment of osmo-msc + osmo-bsc I saw a series of bursts of these after some hours of operation:</p>
<pre>
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3456)[0x555555e9f740]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3455)[0x555555e9f9a0]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3463)[0x555555d2d450]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3462)[0x555555d1d860]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3461)[0x555555a5d200]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3460)[0x555555836d20]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3459)[0x555555a1c7b0]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3466)[0x555555ba5830]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3465)[0x555555a2c140]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3464)[0x555555d91620]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3454)[0x555555c235d0]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3453)[0x555555d42630]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
</pre>
<p>The BSC side for this is:</p>
<pre>
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
</pre>
<p>Unfortunately I have no pcap file.</p>
<p>The error disappeared automatically just as it appeared...</p> OCTOI - Osmocom Community TDM over IP - Bug #5544 (New): Strange HDLC frames in PPP when using mI...https://projects.osmocom.org/issues/55442022-04-23T10:47:00Zlaforge
<p>I have the following setup:</p>
<a name="Server-side"></a>
<h2 >Server side<a href="#Server-side" class="wiki-anchor">¶</a></h2>
<ul>
<li>Portmater3 configured to use L2TP on a certain CalledParty number (03012345051)</li>
<li>XL2TPD as LNS on a remote server</li>
</ul>
<a name="Client-side"></a>
<h2 >Client side<a href="#Client-side" class="wiki-anchor">¶</a></h2>
<ul>
<li>Debian unstable with stock debian kernel</li>
<li>HFC-S USB-ISDN adapter</li>
<li>Stock debian kernel mISDN</li>
<li>mISDNuser built from source with its CAPI plugin built</li>
<li>stock libcapi20</li>
<li>stock debian pppd + capuplugin.so (built from latest isdn-utils)</li>
</ul>
<p>The phenomenon is quite strange:</p>
<ul>
<li>pppd complains about unsupported PPP protocol 0x7eff:</li>
</ul>
<pre>
Apr 23 12:32:05 host3 pppd[12136]: rcvd [proto=0x7eff] 7d 23 c0 21 7d 21 7d 24 7d 20 7d 34 7d 22 7d 26 7d 20 7d 20 7d 20 7d 20 7d 25 7d 26 36 d0 24 3c ...
Apr 23 12:32:05 host3 pppd[12136]: Discarded non-LCP packet when LCP not open
</pre>
<ul>
<li>wireshark cannot decode those packets "PPP Uknknwon (0x7eff)" (see attached <a class="attachment" href="https://projects.osmocom.org/attachments/5182">pm3-l2tp-hdlc.pcap</a>)</li>
</ul>
<p>The connection of course is not established.</p>
<p>I'm right now not sure if it's the client or the server to be blambed here...</p>
<p>In case anyone wants to try, feel free to dial 49-30-1234-3051 from within OCTOI.</p> osmo-e1d - Bug #5521 (New): don't attempt OCTOI connection of no TDM data from driver (icE1usb)https://projects.osmocom.org/issues/55212022-04-10T10:40:32Zlaforge
<p>If there is no TDM data from the icE1usb device (loss of signal, ...) the octoi client should not attempt to connect. Basically it gets stuck in an indefinite loop of connect, timeout (due to no TDM frames), connect, timeout, ...</p> Retronetworking - Bug #5512 (New): Idea: L1OIP driver for DAHDIhttps://projects.osmocom.org/issues/55122022-04-03T11:46:45Zlaforge
<p>mISDN has <code>l1oip</code> as a protocol to use to establish virtual PRI or BRI trunks between different machines using mISDN.</p>
<p>Implementing L1OIP support in DAHDI would allow a virtual PRI/BRI line between a DAHDI machine and a mISDN machine, making it easier to user mISDN applications without the related hardware.</p> osmo-e1d - Bug #5499 (New): octoi client binds to specific IP even if 0.0.0.0 is specifiedhttps://projects.osmocom.org/issues/54992022-03-28T10:38:46Zlaforge
<p>Even if the config file specifies 0.0.0.0 as the local address for the client, the socket apparently still gets bound to a specifid address at the time of the bind/connect.</p>
<pre>
udp 0 0 192.168.2.6:3333 90.187.70.153:10010 VERBUNDEN
</pre>
<p>This means that the OCTOI connection breaks as soon as the client gets a different IP address (e.g. by DHCP).</p>
<p>The odd part is that this doesn't happen on the server side. My socket looks like this:<br /><pre>
udp 0 0 0.0.0.0:10010 0.0.0.0:*
</pre></p> OCTOI - Osmocom Community TDM over IP - Bug #5433 (New): forwarding of TS0 / Alarmshttps://projects.osmocom.org/issues/54332022-01-30T11:02:58Zlaforge
<p>In the current E1oIP PoC code of osmo-e1d, we don't treat TS0 at all. This means that the TS0 signaling (AIS, CRC error, ...) only works on the physical E1 line, but doesn't propagate over IP.</p>
<p>There are multiple approaches to this:</p>
<ol>
<li>don't treat TS0 different from any other TS. However, as it keeps changing all the time, we add 64kBps to the base load of every TDMoIP line. Very quick and simple to implement.</li>
<li>process TS0 locally and have some special-case treatment with explicit signaling/messaging of alarms in the TDMoIP protocol, and then re-create this at the remote end.</li>
</ol>
<a name="types-of-events-to-signal"></a>
<h2 >types of events to signal<a href="#types-of-events-to-signal" class="wiki-anchor">¶</a></h2>
<ul>
<li>remote end reporting CRC error</li>
<li>remote alarm indication signal (AIS)</li>
<li>blue alarm (transmit all-1 signal if we don't receive IP packets anymore)</li>
</ul> SIMtrace 2 - Bug #5423 (New): "trace" firmware continuous test setuphttps://projects.osmocom.org/issues/54232022-01-27T12:24:54Zlaforge
<p>Similar to <code>cardem</code> in <a class="issue tracker-2 status-2 priority-2 priority-default" title="Feature: "cardem" continuous testing setup (In Progress)" href="https://projects.osmocom.org/issues/5422">#5422</a>, we should also create a continuous test setup for passing SIM protocol tracing. The IUT is the simtrace2 firmware.</p>
<p>We can use diffeent modems / CCID readers accessing a SIM card via a SIMtrace2 device while tracing the communication.</p> osmo-e1d - Bug #5386 (New): stop watchdog when LOS is presenthttps://projects.osmocom.org/issues/53862022-01-05T20:38:33Zlaforge
<p>when the icE1usb receives no data (loss of signal / clock), there are no ISO IN transfers from the device to osmo-e1d, so the watchdog expires constantly.</p>
<p>Let's modify the watchdog to only run when no LOS is present.</p> E1/T1 Hardware Interface (including icE1usb) - Bug #5382 (New): icE1usb: detect all-1 pattern an...https://projects.osmocom.org/issues/53822022-01-02T12:17:29Zlaforge
<p>This applies to both DAHDI and e1d.</p> E1/T1 Hardware Interface (including icE1usb) - Bug #5381 (New): icE1usb DAHDI driver: generate YE...https://projects.osmocom.org/issues/53812022-01-02T12:16:29Zlaforge
<p>Right now we are displaying YELLOW alarms received from the peer, but we don't yet report a RED alarm using RAI bits to the peer.</p> OsmoGGSN (former OpenGGSN) - Bug #5357 (New): no more than PDP_MAX == 1024 PDP contexts possible ...https://projects.osmocom.org/issues/53572021-12-14T13:20:21Zlaforge
<p>libgtp uses statically-sized arrays for storing various things, including pdp contexts. This means that no more than 1024 PDP contexts are possible in osmo-sgsn or osmo-ggsn at the moment. This seems <em>very</em> low even for small / private networks.</p>
<p>A quick change might be to increase the #define, but we'd have to see what kind of implications this has on memory consumption as well as runtime complexity.</p>
<p>In the end, dynamic allocations is what we do in all other (native) osmocom projects, so I don't see why we should keep (inherited) libgtp using fixed static allocations imposing arbitrary limits.</p>