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> Core testing infrastructure - Bug #6381 (Feedback): libosmocore changes take too long until they ...https://osmocom.org/issues/63812024-03-01T07:19:47Zlaforge
<p>(05:23:15 PM) hwelte: I don't understand why <a class="external" href="https://gerrit.osmocom.org/c/libosmo-netif/+/35069">https://gerrit.osmocom.org/c/libosmo-netif/+/35069</a> keeps failing even hours after the libosmocore patch has been merged. I even checked that the OBS package for libosmocore had been rebuilt meanwhile<br />(05:29:17 PM) hwelte: the debian10/debian12 builds fail despite the libosmocore on which the changes depend has long been built on obs.<br />(05:54:43 PM) osmith: hwelte, it says here: build jobs exist (gear icon): <a class="external" href="https://obs.osmocom.org/package/show/osmocom:master/libosmocore">https://obs.osmocom.org/package/show/osmocom:master/libosmocore</a><br />(05:55:04 PM) hwelte: osmith: yes, but that's for much more recent libosmocore commits<br />(05:55:04 PM) osmith: the builders just seem to be busy building everything, I guess because of multiple libosmocore merges in a row, each triggering a rebuild of everything<br />(05:55:12 PM) osmith: <a class="external" href="https://obs.osmocom.org/monitor">https://obs.osmocom.org/monitor</a> <- builders being busy<br />(05:55:34 PM) osmith: it might be that OBS doesn't publish a repository before all packages for a distribution are built<br />(05:58:26 PM) osmith: hwelte, so in summary: libosmocore changes cause a lot of packages to be built, and the repo (probably) only gets published once all packages are built. unfortunately it seems that the builders were not able to build everything within the last hours since the merge, or that it started building additional packages because of more merges.</p>
<p>So it somehow seems that if a longer series of patches is committed to libosmocore, each of them gets built as OBS packge for each arch/distibution, and that's what takes so long? Can we somehow get it to only build the most recent commit at a time, and first build that all the way to the end and make sure those packages are published/available for further downstream builds?</p>
It's not exactly a rare situation that we add something to one library, and then there are also patches that use those additions elsewhere. So either
<ul>
<li>we can achieve the above, or </li>
<li>we can make sure that repos/feeds are updated after building [only] the debian10/debian12 on amd64 which we use for gerrit build verification [and even prioritize those]?</li>
<li>we can make find some other way to make sure the (in this case) libosmocore package is somehow available for gerrit build verification after it has been built, and not only after the entire universe has been re-built?</li>
</ul> 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> 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 #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> 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 - Bug #5939 (In Progress): Assemble GraphicGremlin / isavideohttps://osmocom.org/issues/59392023-03-06T16:39:24Zlaforge
<p><a class="external" href="https://github.com/schlae/graphics-gremlin">https://github.com/schlae/graphics-gremlin</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 #5934 (In Progress): Assemble Pico-GUShttps://osmocom.org/issues/59342023-03-02T18:50:05Zlaforge
<p><a class="external" href="https://github.com/polpo/picogus">https://github.com/polpo/picogus</a></p> Retrocomputing - Feature #5933 (In Progress): Assemble XT-CF-Lite v4.1https://osmocom.org/issues/59332023-03-02T18:15:17Zlaforge
<p><a class="external" href="http://www.malinov.com/Home/sergeys-projects/xt-cf-lite">http://www.malinov.com/Home/sergeys-projects/xt-cf-lite</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> SDR (Software Defined Radio) - Feature #5892 (Stalled): design/build ext clock input board for Pl...https://osmocom.org/issues/58922023-02-06T10:04:22Zlaforge
<p>We have a number of plutosdr devices at sysmocom, unfortunately all of them still RevB which unlike current RevD has no external clock input. Most of our use cases require a proper reference clock input, so I thought it might be a good idea to build a small board which contains the LTC6957HMS-3#PBF based input circuitry that was added in RevD. This circuit ensures that any square or sine clock can be used, at proper 50 Ohm impedance, over a wide range of levels.</p>
<p>The ext in / ext out ports should be SMA connectors, so that the resulting PCB can be panel-mounted by bulkhead-mounting those two SMA connectors to a face plate of whatever enclosure we're putting the plutosdr into.</p>
<p>The interconnect between the clock board and plutosdr can be made via u.fl as shown in <a class="external" href="https://coherent-receiver.com/wp-content/uploads/2018/01/umc-pluto-site.jpg">https://coherent-receiver.com/wp-content/uploads/2018/01/umc-pluto-site.jpg</a></p>
<p><a class="external" href="https://wiki.analog.com/university/tools/pluto/hacking/hardware">https://wiki.analog.com/university/tools/pluto/hacking/hardware</a></p> 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> osmo-lab-rack - Feature #5745 (In Progress): component carrier Ethernet switchhttps://osmocom.org/issues/57452022-11-07T19:56:50Zlaforge
<p>It should be possible to use an existing off-the-shelf 5port switch like the netgear GS305E and make a 3U component carrier mount variant of it.</p> SIMtrace 2 - Bug #5578 (Stalled): osmo-remsim-client-st2 hangs after usb-reset without power loss...https://osmocom.org/issues/55782022-06-15T21:50:45Zroh
<p>in case of a osmo-remsim-client-st2 session which gets restarted after being stopped by a usb-disconnect<br /> (terminates with "DST2 FATAL user_simtrace2.c:221 USB IN transfer failed, status=1" as expected)</p>
<p>osmo-remsim-client-st2 gets stuck and then terminates after some time:</p>
<pre>
root@raspberrypi:~# /usr/bin/osmo-remsim-client-st2 -i 10.15.1.135 -V 1d50 -P 4004 -C 1 -I 0 -H 1-1.3.1 -c 1 -n 0
DRSPRO INFO ../rspro_client_fsm.c:307 RSPRO_CLIENT(server){REESTABLISH}: Creating TCP connection to server at 10.15.1.135:9998
DLINP NOTICE simtrace2_api.c:267 [0] <= osmo_st2_cardem_request_config(features=00000001)
DLINP NOTICE input/ipa.c:128 10.15.1.135:9998 connection done
DRSPRO NOTICE ../rspro_client_fsm.c:125 RSPRO_CLIENT(server){REESTABLISH}: RSPRO link to 10.15.1.135:9998 UP
DRSPRO INFO ../rspro_client_fsm.c:307 RSPRO_CLIENT(bankd){REESTABLISH}: Creating TCP connection to server at 10.15.1.135:9999
DLINP NOTICE input/ipa.c:128 10.15.1.135:9999 connection done
DRSPRO NOTICE ../rspro_client_fsm.c:125 RSPRO_CLIENT(bankd){REESTABLISH}: RSPRO link to 10.15.1.135:9999 UP
DLINP NOTICE simtrace2_api.c:168 [0] <= osmo_st2_cardem_request_card_insert(inserted=1)
DLINP NOTICE simtrace2_api.c:317 [0] <= _modem_sim_select(remote_sim=1)
DLINP NOTICE simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 00 )
DLINP NOTICE simtrace2_api.c:285 [0] <= _modem_reset(asserted=2, pulse_ms=300)
DLINP NOTICE simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 9f 96 80 1f 87 80 31 e0 73 fe 21 1b 67 4a 4c 75 30 34 05 4b a9 )
DST2 INFO user_simtrace2.c:65 SIMtrace => PTS req: ff 10 96 79 00 00
...
<modem starts, usb enumeration of serials/wwlan>
...
USB OUT transfer failed, status=2
</pre>
<p>later restarts remain the same in behaviour but a bit different in output:</p>
<pre>
root@raspberrypi:~# /usr/bin/osmo-remsim-client-st2 -i 10.15.1.135 -V 1d50 -P 4004 -C 1 -I 0 -H 1-1.3.1 -c 1 -n 0
DRSPRO INFO ../rspro_client_fsm.c:307 RSPRO_CLIENT(server){REESTABLISH}: Creating TCP connection to server at 10.15.1.135:9998
DLINP NOTICE simtrace2_api.c:267 [0] <= osmo_st2_cardem_request_config(features=00000001)
DLINP NOTICE input/ipa.c:128 10.15.1.135:9998 connection done
DRSPRO NOTICE ../rspro_client_fsm.c:125 RSPRO_CLIENT(server){REESTABLISH}: RSPRO link to 10.15.1.135:9998 UP
DRSPRO INFO ../rspro_client_fsm.c:307 RSPRO_CLIENT(bankd){REESTABLISH}: Creating TCP connection to server at 10.15.1.135:9999
DLINP NOTICE input/ipa.c:128 10.15.1.135:9999 connection done
DRSPRO NOTICE ../rspro_client_fsm.c:125 RSPRO_CLIENT(bankd){REESTABLISH}: RSPRO link to 10.15.1.135:9999 UP
DLINP NOTICE simtrace2_api.c:168 [0] <= osmo_st2_cardem_request_card_insert(inserted=1)
DLINP NOTICE simtrace2_api.c:317 [0] <= _modem_sim_select(remote_sim=1)
DLINP NOTICE simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 00 )
DLINP NOTICE simtrace2_api.c:285 [0] <= _modem_reset(asserted=2, pulse_ms=300)
DLINP NOTICE simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 9f 96 80 1f 87 80 31 e0 73 fe 21 1b 67 4a 4c 75 30 34 05 4b a9 )
USB OUT transfer failed, status=2
</pre>
<p>please note that the modem does not seem to reboot on later restarts of osmo-remsim-client-st2, which is odd.</p>
<p>osmo-remsim-client version 1.0.0.18-f5f5<br />qmod firmware 0.8.1.33-9088</p>
<p>osmo-remsim-bankd version 1.0.0.18-f5f5<br />osmo-resmim-server version 1.0.0.18-f5f5</p>
<p>maybe this is a rerun of <a class="issue tracker-1 status-7 priority-1 priority-lowest" title="Bug: osmo-remsim-client-st2 (or firmware?) gets stuck on PTS (Stalled)" href="https://osmocom.org/issues/4409">#4409</a></p>
<p>for this test the server/bankd were on x86_64 and the client was on armv7l (rpi) but i don't think it matters.<br />i have also tried a older qmod firmware (0.7.0.57-f46d) for comparison but i can see no difference in behavior.</p>
<p>please note that i could not reproduce this issue with a modem on st34, only on st12. i suspect it has to do with st12 staying powered all the time and not reset/rebooted on usb-connect properly somehow.</p>
<p>this may as well be a firmware issue on the qmod.</p> Retronetworking - Feature #5488 (In Progress): create DAHDI mirror snifferhttps://osmocom.org/issues/54882022-03-13T21:32:05Zlaforge
<p>For further exploration of a variety of different ISDN equipment and protocols, we need a proper sniffer to trace communication not only on D- but also on B-channels.</p>
Existig systems are not good use cases:
<ul>
<li>osmo-e1-recorder ("owns" the DAHDI devices/channels, for use with passive E1 tap)</li>
<li>dahdi_pcap / dahdi_gsmtap (just for D-channel)</li>
<li>dahdi_monitor doesn't work</li>
<li>dahdi_rawdump works for single B-channel only, and has no signaling integration</li>
</ul>
<p>The high-level functionality would be:</p>
<ul>
<li>open d-channel in RXMIRROR + TXMIRROR</li>
<li>filter out Q.921 I-frames in both directions (ignore everything else)</li>
<li>perform simplistic Q.931 decode of message type, call reference and IE iteration</li>
<li>maintain table with call references, one entry per callref
<ul>
<li>create on SETUP</li>
<li>destroy at RELEASE/RELEASE_COMPLET</li>
<li>destroy after timeout?</li>
</ul>
</li>
<li>decode/track ChannelID IE
<ul>
<li>store B-channel number with call reference</li>
</ul></li>
</ul>
<ul>
<li>start capturing B-channel on CONNECT</li>
<li>stop capturing B-channel when call is destroyed</li>
</ul>
<ul>
<li>optional: add software HDLC for B channel to avoid transmitting large amounts of flag octets?</li>
</ul>
<p>The data storage format could very well be the format of osmo-e1-recorder.</p> OCTOI - Osmocom Community TDM over IP - Feature #5436 (New): BRI variant of OCTOI protocolhttps://osmocom.org/issues/54362022-01-30T13:33:09Zlaforge
<p>right now the protocol is rather E1-centric, or at least assuming that timeslots always have the same bitrate.</p>
For BRI we have
<ul>
<li>2x64k B-channels (exposed to the user)</li>
<li>1x16k D-channel (exposed to the user)</li>
<li>additional management channels (not exposed to the user, normally handled in the NT)</li>
</ul>
<p>We need to find a way to express BRI in our protocol.</p>
<p>Misc note: DAHDI exposes the 2xB+1xD as three channels. Not sure if the D-channel runs at a non-8kHz rate, or if it simply only uses 2 bits of every byte?</p>
<p>The header/packet protocol overhead of course becomes even higher (proportionally) compared to PRI.</p> OCTOI - Osmocom Community TDM over IP - Feature #5417 (Stalled): S/T (S0) ISDN BRI adapter with V...https://osmocom.org/issues/54172022-01-24T19:52:37Zlaforge
<p>So.. As part of the <a class="wiki-page" href="https://osmocom.org/projects/octoi/wiki/Community_TDMSS7_Network">Community_TDMSS7_Network</a>, offering PRI is nice but most people will have BRI equipment (modems, ISDN-TA, small home PBX, ...) that they'd be interested in attaching.</p>
<p>Doing this with COTS ISDN adapters is not an option, as we cannot control their clock to match the master clock of the TDMoIP network.</p>
<p>I've been brainstorming a potential design and validated component availability. Currently I'm thinking of something like this</p>
<ul>
<li>CologneChip XHFC-2SU (2-port S0) controller IC, operated in NT mode
<ul>
<li>available from stock at MOQ-160 from CologneChip</li>
</ul>
</li>
<li>Matching dual magnetics.
<ul>
<li>digikey + mouser have a few pulse parts still in stock (low qty): T5007</li>
<li>Sumida has stopped all production</li>
<li>Talema has 30 weeks lead time</li>
<li>UMEC still has some stock of UT20795-5MTS, I'm putting a 250 unit reel on sysmocom stock right now</li>
</ul>
</li>
<li>clocking
<ul>
<li>10 MHz VCXO (optional external 10 MHz input in case somebody already has GPS-DO around)</li>
<li>some clock divider to bring this down to 8kHz. If we have no other programmable logic or timer/counter blocks that can be used, an ATTiny clocked off 10MHz (no prescaler, counter generating interrupt every 250 cycles, divide-by-5 in software/irq-handler) approach can be used - doen in a lot of DYI 10MHz -> 1PPS designs.</li>
<li>some PWM or DAC to drive the VXCO</li>
</ul></li>
</ul>
<p>The more interesting question is the interface on the "Compute" side.</p>
Possible high-level approaches:
<ol>
<li>USB-attached to some Linux PC
<ul>
<li>more analoguous to icE1usb, but requires an additonal computer</li>
</ul>
</li>
<li>Raspi hat (or beagle or the like)
<ul>
<li>I'm not a big raspi fan, but they are very popular</li>
</ul>
</li>
<li>built-in Ethernet for direct TDMoIP
<ul>
<li>most easy to deploy, would allow people without Linux knowledge to simply plug+play</li>
</ul></li>
</ol>
<p>Right now I'm leaning mostly towards something self-contained with built-in Ethernet.</p>
The major problem right now is availability of uC or FPGA.
<ul>
<li>STM32 are basically vanished off the planet</li>
<li>iCE40 equally not available (yes, <a class="user active" href="https://osmocom.org/users/12">tnt</a> might get 100, but ...)</li>
</ul>
<p>One thought might be to use an SAME5x (sysmocom uses that part in the sysmoOCTSIM and has some stock. It is a bit on the high-end side compared to the requirements).</p> libosmo-sccp + libosmo-sigtran - Bug #3871 (Feedback): osmo_scu_prim conn_id should be scoped per...https://osmocom.org/issues/38712019-03-28T19:58:51Zneelsnhofmeyr@sysmocom.de
In summary:
<ul>
<li>separate osmo_scu_prim.*.conn_id from osmo_sccp_inst->next_id</li>
<li>separate each osmo_sccp_user's conn_ids number spaces</li>
<li>separate incoming from outgoing osmo_scu_prim.*.conn_id number spaces</li>
</ul>
<p>Details:</p>
<p>The osmo_sccp_instance.next_id is responsible for local-reference IDs on the SCCP wire.<br />Currently, this same next_id number space is also used towards the SCU user, i.e. as osmo_scu_prim.*.conn_id.<br />Not only should this conn_id be scoped separately from the osmo_sccp_instance.next_id, but also be a distinct number space per SCU user.</p>
<p>struct sccp_connection in sccp_scoc.c is the place where an SCCP local-reference is correlated to an osmo_sccp_user.conn_id, it must store these IDs separately.<br />The number space for the osmo_scu_prim.*.conn_id should be guarded by some "next_id" counter in osmo_sccp_user.<br />Incoming and outgoing conn_ids must be made sure to not collide, best divide the number space in two for incoming and outgoing conn_ids.</p>
<p>For example, in osmo-msc, there may be two SCCP users connected to the same osmo_sccp_instance: one for OSMO_SCCP_SSN_BSSAP (= GERAN-A = 2G) and one for OSMO_SCCP_SSN_RANAP (= UTRAN-Iu = 3G).<br />Implementations using the SCU API might be completely separate, and it would be a "scoping violation" if these distinct users have to negotiate with each other about unused osmo_scu_prim conn_ids.</p>
<p>Another aspect is that there may be incoming SCCP connections and outgoing SCCP connections.<br />As an example:</p>
<p>From the perspective of osmo-msc, usually the BSC connects to the MSC:</p>
<pre>
BSC MSC AS SCCP-User
| ---N_CONNECT--> | ---osmo_scu_prim.connect.conn_id--> | BSSAP implementation stores new conn_id.
| | |
| <--N_DATA-----> | <---osmo_scu_prim.data.conn_id----> |
</pre>
<p>But in case of an inter-BSC HO, the MSC initiates a connection to the BSC instead:</p>
<pre>
BSC MSC AS SCCP-User
| <--N_CONNECT--- | <--osmo_scu_prim.connect.conn_id--- | BSSAP implementation *invents* new conn_id.
| | |
| <--N_DATA-----> | <---osmo_scu_prim.data.conn_id----> |
</pre>
<p>(Note, this is only relevant for Connection-Oriented Initial messages, i.e. Layer 3 Complete (incoming to MSC) and Handover Request (outgoing from MSC).<br />For example, Paging is done by a connection-less message that has no conn_id at all, after which the BSC establishes a connection when the MS has responded.)</p>
<p>To keep sane layer separation, it is important to maintain the osmo_scu_prim struct as the <strong>only</strong> communication interface between the SCCP-User and the SCCP instance.<br />Hence we cannot iterate all existing conn_ids and pick an unused one: an incoming SCCP connection might asynchronously pick the exact same conn_id.<br />In practice, this cannot happen right now, but the scoping should be such that it would be possible to place the SCCP User in a separate process.</p>
<p>So, a proposal is that for incoming connections, the libosmo-sccp creates new osmo_scu_prim.*.conn_id in the number space 0..0x7fffffff for incoming N-CONNECT,<br />while for outgoing N-CONNECT, the SCCP-User implementation creates new osmo_scu_prim.*.conn_id in the number space 0x80000000..0xffffffff. (Or rather, use the lowest bit to separate for shorter logging)<br />There should be osmo_sccp_user_* API to fetch an unused outgoing SCCP-User conn_id, so SCCP-Users don't need to implement their own.</p> OsmoMSC - Feature #1974 (New): VLR: high water mark on subscriber storagehttps://osmocom.org/issues/19742017-03-08T14:54:50Zneelsnhofmeyr@sysmocom.de
<p>In libvlr, we (will) keep every subscriber in RAM as long as it still has valid auth tuples (3GPP TS 33.102 Annex C.2.3).<br />Most subscribers will still have auth tuples left upon detaching, so we would store <strong>all</strong> subscribers.</p>
<p>Implement a configurable way of limiting the number of subscribers kept in RAM, e.g. a fixed max size.<br />If this is reached, discard those subscribers that have been inactive for the longest time first.</p>