Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-22T17:44:25ZOpen Source Mobile Communications
Redmine 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> Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Feature #6392 (New): video recording / c...https://osmocom.org/issues/63922024-03-06T12:08:24Zlaforge
<p>We need to check how we can get c3voc video recording equipment on-site and who will operate it.</p> pySim - Bug #6340 (New): exception when using osmo-smdpp with python 3.9https://osmocom.org/issues/63402024-01-24T09:43:35Zdexter
<p>There is an exception when starting osmo-smdpp with python 3.9. This exception does not occur with python 3.10.</p>
<pre>
owner@osmotest:~/git_master/pysim$ python3.9 ./osmo-smdpp.py
Traceback (most recent call last):
File "/home/owner/git_master/pysim/./osmo-smdpp.py", line 100, in <module>
class SmDppHttpServer:
File "/home/owner/git_master/pysim/./osmo-smdpp.py", line 196, in SmDppHttpServer
def initiateAutentication(self, request: IRequest, content: dict) -> dict:
TypeError: 'staticmethod' object is not callable
</pre>
<p>Commit hash: af87cd544f784e51a41cea303cb57001d9954d9c</p> Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Bug #6291 (New): 2024 event bringing tog...https://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 #6274 (New): yate is eating 260% CPU while doing nothinghttps://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://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> OCTOI - Osmocom Community TDM over IP - Feature #6246 (New): co-locate cisco 2811 for FrameRelay...https://osmocom.org/issues/62462023-11-06T13:48:35Zlaforge
<p>let's put a Cisco 2811 into the co-location, ideally with support for both X.25 as well as FrameRelay.</p>
<p>The idea would be to use it as basis for interop testing any Linux/FOSS work on X.25/framerelay routing/switching that would happen on the OCTOI hub.</p> OCTOI - Osmocom Community TDM over IP - Feature #6245 (New): co-locate cisco 2811 ITP/STP in data...https://osmocom.org/issues/62452023-11-06T13:46:23Zlaforge
<p>The Cisco 2811 is a nice small 1U system that can run as ITP ("Internet transfer point"), i.e. a SS7 STP with support for SIGTRAN and classic TDM.</p>
<p>cisco 2811 supports up to 4xE1 as TDM connection.</p>
let's
<ul>
<li>figure out if one can have multiple signaling timeslots/links on one E1</li>
<li>connect one or multiple E1 via TE820 to AVSt</li>
</ul> Retronetworking - Feature #6244 (New): scan more/all EWS(O) documentation laforge hashttps://osmocom.org/issues/62442023-11-01T21:50:15Zlaforge
<p><a class="user active" href="https://osmocom.org/users/7">laforge</a> has multiple folders full of low-level documentation even including circuit diagrams of the EWS-O (digitally controlled bu analog switched) EWSD predecessor.</p>
<p>Part one is at <a class="external" href="https://people.osmocom.org/laforge/ftz/FTZ-161D1_14-Teil1.pdf">https://people.osmocom.org/laforge/ftz/FTZ-161D1_14-Teil1.pdf</a> but the other parts apparently are not yet scanned/released</p> Retronetworking - Feature #6237 (New): Design + Build PCBA for NE555 based fake fan rpm sensor https://osmocom.org/issues/62372023-10-30T01:38:59Zlaforge
<p>Sometimes one has to spoof fan rpm sensors.</p>
<p><a class="external" href="https://www.techidiots.net/notes/fake-fan-sensor">https://www.techidiots.net/notes/fake-fan-sensor</a> has a nice/simple design circuit. Let's build a simple PCBA around it, using parts available from JLCPCB, like</p>
<ul>
<li><a class="external" href="https://jlcpcb.com/partdetail/Hgsemi-LM555MTR/C356723">https://jlcpcb.com/partdetail/Hgsemi-LM555MTR/C356723</a> (NE555 clone)</li>
<li><a class="external" href="https://jlcpcb.com/partdetail/120172-3362P_1502/C118903">https://jlcpcb.com/partdetail/120172-3362P_1502/C118903</a> (potentiometer)</li>
</ul>
The board should have a
<ul>
<li>one or multiple 3-pin fan headers for the real fan (tacho line not connected)</li>
<li>one or multiple 3-pin fan headers (for jumper cables to mainboard)
<ul>
<li>only one of them used as power source, others have VCC disconnected</li>
<li>all of them get the same tacho signal</li>
</ul></li>
</ul> Retronetworking - Feature #6219 (New): Publish pics/videos for EWSD rescue/movehttps://osmocom.org/issues/62192023-10-17T14:10:34Zlaforge
<p>Before publishing more pictures and/or videos, have to clarify</p>
<ul>
<li>individual permission (rights to one's own picture) or in the worst case pixelize some individuals</li>
<li>corporate permission (other equipment which might be visible around the EWSD)</li>
<li>find a good way to publish an entire gallery of pictures + videos, possibly with captions</li>
<li>cut out the lunch breaks from the timelapse videos</li>
<li>provide down-scaled (HD?) versions of the videos for people who don't want to download or stream gigabytes...</li>
<li>some kind of intro / title slide for the videos (just to give context)</li>
</ul> Retronetworking - Feature #6218 (New): write article/report on EWSD rescue for IGHFT / Fernmeldem...https://osmocom.org/issues/62182023-10-17T14:05:27Zlaforge
<p>I'm a member there and it would be nice to get a report into their member magazine "Tele-Kurier" (not publicly available). Still it might be there are some people with interest not only for electromechanical switching.</p>
<p><a class="external" href="https://fernmeldemuseum-dresden.de/">https://fernmeldemuseum-dresden.de/</a></p> Retronetworking - Feature #6195 (New): Wiki page on Cisco *WIC-* line cards for 26xx/28xx serieshttps://osmocom.org/issues/61952023-09-27T12:47:42Zlaforge
<p>I have a large collection of various line cards (sync/async/BRI/E1/....). Let's create a wiki page about those line cards with some description and high-res PCB photographs.</p> Retronetworking - Feature #6194 (New): wiki page on MultiTech MT5600-BLhttps://osmocom.org/issues/61942023-09-27T12:46:25Zlaforge
<p>I have recently obtained three MT5600-BL 4-wire leased line modems. Let's create a wiki page with PCB photogrphs etc.</p> Retronetworking - Support #6193 (New): Replace "event rack" PM3 power supplyhttps://osmocom.org/issues/61932023-09-27T12:14:08Zlaforge
<p>Today I wanted to test the <a class="wiki-page" href="https://osmocom.org/projects/retronetworking/wiki/Event_Setup">Event_Setup</a> ahead of CC2023 and noticed that the PM3 won't power up :(</p>
<p>Luckily I have a few spare PM3 around so I could replace the broken PSU with one from another unit.</p>
<p>As I've now already seen two PM3 with broken PSU, let's make sure to replace them in all of them according to the procedure I documented in <a class="wiki-page" href="https://osmocom.org/projects/retronetworking/wiki/Livingston_Portmaster_3">Livingston_Portmaster_3</a></p> osmo-e1d - Bug #6169 (New): Frame masking against network frame ordering, not frame numbershttps://osmocom.org/issues/61692023-09-06T08:33:34Zmanawyrm
<p>The osmo-e1d code includes functionality to save bandwidth by not transmitting timeslots, which haven't changed since the last frame.</p>
<p><a class="external" href="https://gitea.osmocom.org/Manawyrm/osmo-e1d/src/branch/master/src/octoi/e1oip.c#L263">https://gitea.osmocom.org/Manawyrm/osmo-e1d/src/branch/master/src/octoi/e1oip.c#L263</a></p>
<p>Later in development, the frame_rifo was introduced to combat packet reordering in real-world networks (like DOCSIS).<br />The code unpacking the timeslots into full E1 frames is currently unpacking against the last frame in the incoming buffer, not the last frame in the RIFO (random in, first out) buffer.<br />This means that frames will get filled with random data from other frames in the event of a re-ordering.</p>
<p>Unpacking/Unmasking should be done after the RIFO mechanism.</p> pySim - Feature #6086 (New): implement features of sysmo-{usim,isim}-toolhttps://osmocom.org/issues/60862023-07-07T11:25:49Zlaforge
<p>I always found it rather odd that there are OS-specific executables in the sysmo-usim-tool software. The purpose was always to have a separate tool for those bits which are sysmo*SIM specific, and not normal ETSI/3GPP Standard. However, that was designed at a time before pySim-shell existed, and only pySim-prog was available.</p>
<p>As more sysmocom card models got introduced, those were not supported from within one sysmo-*sim-tool program, but with copy+pasted+edited command line tools. As a result, users need to know which card they have and execute the right tool for it, which is cumbersome. Even more so, as there are tools (specifically, the sysmo-isim-tool.sja2.py) which actually also supports the sysmoTSIM (3GPP Test profile).</p>
<p>Rather than unifying this inside the sysmo-usim-tool.git repo, I think it's better to reimplement the same functionality based on (and likely inside) pysim.git.</p>
<p>Now that we have the "new" capabilities of pySim-shell and its associated class model, we shouldn't really need separate[ly maintained] software for the actual functionality.</p>
What can sysmo-usim-tool do is:
<ul>
<li>set the imsi
<ul>
<li>3GPP standard, not sysmocom specific</li>
</ul>
</li>
<li>set mnc length
<ul>
<li>3GPP standard, not sysmocom specific</li>
</ul>
</li>
<li>show ICCID
<ul>
<li>3GPP standard</li>
</ul>
</li>
<li>show AID list
<ul>
<li>3GPP standard</li>
</ul>
</li>
<li>show milenage parameters</li>
<li>set milenage parameters</li>
<li>show ki value</li>
<li>set ki value</li>
<li>show [supported and configured] authentication algorithms</li>
<li>set 2g/3g auth algo</li>
<li>show OP/OPc configuration</li>
<li>set OP/OPc</li>
<li>show milenage SEQ/SQN parameters</li>
<li>set milenage SEQ/SQN parameters to default</li>
<li>dump proprietary file contents</li>
</ul>
<p>Let's add whatever functionality is missing to the pySim class model, and then try to implement a potentially command-line compatible replacement for at least the most common operations. For the more esoteric ones (like milenage parameters), I think it's fine to have the user go through pySim-shell and do an edit_binary_decoded or something like that to change the parameters.</p> Retrocomputing - Feature #5947 (New): Assemble PC104-SVGAhttps://osmocom.org/issues/59472023-03-15T09:29:21Zlaforge
<p><a class="external" href="https://github.com/monotech/PC104-SVGA">https://github.com/monotech/PC104-SVGA</a></p> Retrocomputing - Feature #5940 (New): Assemble LPT_Capturehttps://osmocom.org/issues/59402023-03-06T16:42:08Zlaforge
<p><a class="external" href="https://github.com/bkw777/LPT_Capture">https://github.com/bkw777/LPT_Capture</a></p> Retrocomputing - Feature #5936 (New): Assemble netpi-idehttps://osmocom.org/issues/59362023-03-02T19:20:56Zlaforge
<p><a class="external" href="https://www.retrotronics.org/home-page/netpi-ide/">https://www.retrotronics.org/home-page/netpi-ide/</a></p>
<p><a class="external" href="https://www.retrotronics.org/svn/jride/trunk/">https://www.retrotronics.org/svn/jride/trunk/</a></p> Retrocomputing - Feature #5932 (New): assemble ISA-USBhttps://osmocom.org/issues/59322023-03-02T17:28:00Zlaforge
<p><a class="external" href="https://www.lo-tech.co.uk/wiki/Lo-tech_ISA_USB_Adapter">https://www.lo-tech.co.uk/wiki/Lo-tech_ISA_USB_Adapter</a></p> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> osmo-remsim - Bug #5891 (New): bankd: potential pthread deadlock reported by coverityhttps://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> OCTOI - Osmocom Community TDM over IP - Feature #5885 (New): set up a second GPS03 + icE1usb setuphttps://osmocom.org/issues/58852023-01-31T20:05:42Zlaforge
<p>As we have some strange GPS hold-over events in <a class="issue tracker-1 status-1 priority-2 priority-default" title="Bug: GPS sync sometimes goes to hold over (New)" href="https://osmocom.org/issues/5883">#5883</a> it would be a good idea to set up a second "identical" setup, i.e. icE1usb with RS422 board and GPS03 receiver to compare against.</p>
<p>I already have a icE1usb operating my OCTOI link at home with its internal GPS receiver right now. I also have spare GPS03 and one RS422 board and free output ports at my GPS splitter.</p>
<p>Let's set that up at some point.</p> OsmoHLR - Feature #5865 (New): Automate selection of LU Reject Causehttps://osmocom.org/issues/58652023-01-20T13:59:07Zkeith
<p>There is some suggestion in <a class="external" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16808">https://gerrit.osmocom.org/c/osmo-hlr/+/16808</a> that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update</p>
<p>Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.</p>
<p>We could have a regex config option to let osmo-hlr know what is "our" SIM or not. Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP? I'm not familiar with GSUP.</p> Retronetworking - Feature #5855 (New): Establishing a German non-profit for retronetworkinghttps://osmocom.org/issues/58552023-01-13T11:43:49Zlaforge
<p>While we all have a lot of fun researching and implementing various bits of ancient communication systems, I think there are aspects of our work that deserve to be done under a formal/legal entity that should hopefully outlive the current protagonists, and also protect us against "loss" of individuals (changes in personal life, health issues, ...)</p>
<p>I'm particularly thinking of the <em>archieval and documentation</em> aspects, such as digitizing old specs and books, documenting the cirucit boards, data sheets, etc.</p>
<p>I'll continue this ticket and related information in German, as I expect a lot of the legal/organization aspects are in German, and [almost?] all initial founding members would be German.</p> Cellular Network Infrastructure - Feature #5771 (New): series of presentations about the invididu...https://osmocom.org/issues/57712022-11-14T19:25:57Zlaforge
<p>Most of the talks we ever gave on setting up and running the Osmocom CNI are ages old and hence relatively outdated.</p>
<p>Given the number of network elements and the relate complexity, I think we should consider doing a talk on each of them. The talk doesn't have to be of a particular length, so some network elements might have shorter or longer presentations.</p>
<p>Looking at the checklist below, we already have 14 items. Covering this in OsmoDevCall is not an option, it would take too long (14 months if no other topic would be covered in between). So it is going to be on a separate schedule.</p>
<p>I would consider each presentation should then be prominently linked from the redmine project page of each network element, next to the user manual.</p>
<p>We may of course still be publishing those via the OsmoDevCall "event" on media.ccc.de, so all videos are in one location.</p>
<p>I think every presentation should start with a quick picture at the overal diagram of netwokr elements, describe the surrounding elements and their interfaces to then look in detail at the specific element that ist he subject of the talk.</p>
It should cover
<ul>
<li>basic configuration to get it started / connected</li>
<li>VTY for state introspection ("ar alle connections up?", ...)</li>
<li>looking at logs / protocol traces</li>
<li>practical demo; looking at what happens in pcaps + logs for some basic transaction like LU, SMS, voice call.</li>
</ul> Retronetworking - Bug #5681 (New): Figure out suitable connectors for EKSOShttps://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> osmo-clock-gen - Feature #5633 (New): towards a first osmo-clock-gen production batchhttps://osmocom.org/issues/56332022-07-26T12:39:18Zlaforge
<p>A batch of 100 unit Si5351C that I ordered a long time ago has finally arrived. This means we have the most critical part in stock now for a first batch.</p>
<p>The main problem now is the uC situation. We originally chose the SAMD1x and later SAMD2x as they are lower cost and lower complexity compared to the SAM3S or other uC we use in other designs. However, SAMD21 are not available on the market today. One variant might be available in November 2022, while others have lead times to July 2023.</p>
<p>So what uC to use? For example, RP2040 would be available in quantity at ultra low cost. Disadvantage: no internal Flash, so we'd need a SPI flash. Alternatively use something like "RP2040-Zero":<br /><a class="external" href="https://www.waveshare.com/rp2040-zero.htm?sku=20187">https://www.waveshare.com/rp2040-zero.htm?sku=20187</a> which is a small daughterboard with RP2040 + SPI flash + USB-C...</p> osmo-remsim - Feature #5614 (New): log also application-level errorshttps://osmocom.org/issues/56142022-07-11T20:09:58Zlaforge
<p>Right now all the logging just relates to the remsim transport layer. However, it would be rather useful to also check the SW of the SIM communication and log errors whenever non-successful SW are observed. Or at least warnings. This could help us to identify where/when communicatiaon between modem and SIM goes wrong. The best location for this is probably the client, as this is also where (if at all) we are accidentially breaking the communication on the UART.</p> Open Source IMS Client - Feature #5481 (New): SIM card interface for doubangohttps://osmocom.org/issues/54812022-03-07T10:53:16Zlaforge
<p>The pre-existing <a class="wiki-page" href="https://osmocom.org/projects/foss-ims-client/wiki/Doubango">doubango</a> library code assumes that the IMS client has knowledge of the secret key material (K + OP/OPc) in order to perform the authentication and IPsec key establoshment to the P-CSCF.</p>
<p>This may be the case in <em>some</em> testing/lab setups, but in general this key material is stored on the ISIM or USIM application of a SIM card.</p>
<p>If we want to use doubango with such standard cards, we need some kind of interface how doubango can perform authentication via ISIM/USIM.</p>
The interface should be rather generic, as the detailed interface for SIM access will be highly platform specific:
<ul>
<li>For development on a normal Linux laptop, a pcsc-lite based interface to a smart card reader will be used.</li>
<li>For execution inside a specific phone, phone specific interfaces for SIM card access may be used (QMI, AT+CSIM, ...)</li>
</ul>