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> 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> 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> 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> 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-e1d - Bug #5386 (New): stop watchdog when LOS is presenthttps://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 #5381 (New): icE1usb DAHDI driver: generate YE...https://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> erlang/osmo_ss7 - Bug #5378 (New): ipa: add support for client applicationhttps://osmocom.org/issues/53782021-12-30T19:23:19Zlynxis
<p>The osmo_dia2gsup is using the ipa module.<br />The ipa module is sending an "Identity Request" after the connection is established. The osmo-hlr will treat this early identity request as invalid and will never answer to it.</p>
<pre>
diff --git a/src/ipa_proto.erl b/src/ipa_proto.erl
index ceb024a..1a6ca4f 100644
--- a/src/ipa_proto.erl
+++ b/src/ipa_proto.erl
@@ -120,10 +120,6 @@ request({ipa_set_ccm_options, Socket, CcmOptions}, _) ->
{ccm_options, CcmOptions};
% server-side handler for unblock()
request({ipa_unblock, Socket}, CcmOptions) ->
- if
- CcmOptions#ipa_ccm_options.initiate_ack -> send_ccm_id_ack(Socket);
- true -> send_ccm_id_get(Socket)
- end,
io:format("Unblocking socket ~p~n", [Socket]),
%[IpaSock] = ets:lookup(ipa_sockets, Socket),
Ret = inet:setopts(Socket, [{active, once}]),
</pre> OsmoBSC - Bug #4683 (New): properly report OM2000 bring-up problemshttps://osmocom.org/issues/46832020-07-30T06:50:59Zlaforge
<p>If there is a mismatch between hardware or IDB configuration and the osmo-bsc configuration, the OM2000 bring-up will fail in various ways. This is not clearly visible at the moment, and in many situations the user will not be aware that anything has been going wrong. In some situations RSL will simply never be initialized successfully - in some other situations even RSL comes up without errors, but the RBS simpyl doesn't transmit.</p>
The most important indications we get from the RBS:
<ul>
<li>some Enable Result, particularly on the TX or TRXC, <em>not according to request</em>, optionally with information which IE is causing the problem</li>
<li>Failure Maps</li>
</ul>
Let's make sure that
<ul>
<li>the related errors are logged at ERROR level (in human-readable form)</li>
<li>the state of the MO is easily available via introspection/VTY</li>
<li>we document how to deal with this in the user manual or wiki</li>
</ul> OsmoBSC - Bug #4649 (New): OM2K SI5ter: abis_rsl.c:1237 (bts=0,trx=0) ERROR REPORT (cause=Service...https://osmocom.org/issues/46492020-07-04T19:05:37Zlaforge
<p>I'm seeing this during every RSL bring-up on my RBS2308:</p>
<pre>
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 01 27 17 55 06 19 8f 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e5 04 00 6b
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 02 27 17 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 0a
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 0b
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 29
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 03 27 17 49 06 1b 00 00 62 f2 24 00 01 c9 03 05 27 5e 00 e5 04 00 29 2b 2b 2b
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 04 27 17 31 06 1c 62 f2 24 00 01 5e 00 e5 04 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
<0017> input/dahdi.c:263 E1TS(0:1) TX: 10 1a 1e 05 0b 00 12 06 1d 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<0017> input/dahdi.c:263 E1TS(0:1) TX: 10 1a 1e 0d
<0017> input/dahdi.c:263 E1TS(0:1) TX: 10 1a 1e 0e
<0003> abis_rsl.c:1237 (bts=0,trx=0) ERROR REPORT (cause=Service or Option not available [ 3f ])
<0017> input/dahdi.c:263 E1TS(0:1) TX: 10 1a 1e 06 0b 00 0c 06 1e 00 00 62 f2 24 00 01 27 ff 3b
</pre>
<p>So I guess one of the BCCH / SACCH filling we send is not appreciated by the RBS2308.</p> OsmoBSC - Bug #4645 (New): OM2K: "Sequence Error" due to too early iniitialization of RSL during ...https://osmocom.org/issues/46452020-07-03T18:47:47Zlaforge
<p>at least on a RBS2380 I see:</p>
<pre>
<0004> abis_om2000.c:2898 Rx MO=IS/00/ff/00 Operational Information Accept (80 80 00 06 00 76 05 00 ff 00 )
<0004> abis_om2000.c:2086 OM2000-MO(0-IS-00-ff-00)[0x6120000e3020]{WAIT-OPINFO-ACCEPT}: Received Event RX-OPINFO-ACCEPT
<0004> abis_om2000.c:1864 OM2000-MO(0-IS-00-ff-00)[0x6120000e3020]{WAIT-OPINFO-ACCEPT}: state_chg to DONE
<0004> abis_om2000.c:1871 OM2000-MO(0-IS-00-ff-00)[0x6120000e3020]{DONE}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
<0004> abis_om2000.c:1871 OM2000-MO(0-IS-00-ff-00)[0x6120000e3020]{DONE}: Removing from parent OM2000-BTS(0)[0x612000010120]
<0004> abis_om2000.c:1871 OM2000-MO(0-IS-00-ff-00)[0x6120000e3020]{DONE}: Freeing instance
<0004> fsm.c:573 OM2000-MO(0-IS-00-ff-00)[0x6120000e3020]{DONE}: Deallocated
<0004> abis_om2000.c:1871 OM2000-BTS(0)[0x612000010120]{WAIT-IS}: Received Event IS-DONE
<0004> abis_om2000.c:2404 OM2000-BTS(0)[0x612000010120]{WAIT-IS}: state_chg to WAIT-TRX-LAPD
<0014> input/lapd.c:660 ((0:1-T0-S0)) LAPD DL-ESTABLISH confirm TEI=0 SAPI=0
<0004> bts_ericsson_rbs2000.c:125 inp_sig_cb(): Input signal 'TEI-UP' received
<0003> osmo_bsc_main.c:299 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 55 using MCC-MNC 262-42 LAC=1 CID=0 BSIC=63
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 01 27 17 55 06 19 00 00 00 00 00 00 00 00 00 40 00 00 00 00 00 00 e5 04 00 2b
<0003> abis_rsl.c:1237 (bts=0,trx=0) ERROR REPORT (cause=Message Sequence Error [ 62 11 ])
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 02 27 17 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00
<0003> abis_rsl.c:1237 (bts=0,trx=0) ERROR REPORT (cause=Message Sequence Error [ 62 11 ])
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 0a
<0003> abis_rsl.c:1237 (bts=0,trx=0) ERROR REPORT (cause=Message Sequence Error [ 62 11 ])
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 0b
<0003> abis_rsl.c:1237 (bts=0,trx=0) ERROR REPORT (cause=Message Sequence Error [ 62 11 ])
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 29
<0003> abis_rsl.c:1237 (bts=0,trx=0) ERROR REPORT (cause=Message Sequence Error [ 62 11 ])
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 03 27 17 49 06 1b 00 00 62 f2 24 00 01 c9 03 05 27 45 00 e5 04 00 29 2b 2b 2b
<0003> abis_rsl.c:1237 (bts=0,trx=0) ERROR REPORT (cause=Message Sequence Error [ 62 11 ])
<0017> input/dahdi.c:263 E1TS(0:1) TX: 0c 11 01 80 1e 04 27 17 31 06 1c 62 f2 24 00 01 45 00 e5 04 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
<0003> abis_rsl.c:1237 (bts=0,trx=0) ERROR REPORT (cause=Message Sequence Error [ 62 11 ])
<0017> input/dahdi.c:263 E1TS(0:1) TX: 10 1a 1e 05 0b 00 12 06 1d 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<0017> input/dahdi.c:263 E1TS(0:1) TX: 10 1a 1e 0d
<0017> input/dahdi.c:263 E1TS(0:1) TX: 10 1a 1e 0e
<0003> abis_rsl.c:1237 (bts=0,trx=0) ERROR REPORT (cause=Service or Option not available [ 3f ])
<0017> input/dahdi.c:263 E1TS(0:1) TX: 10 1a 1e 06 0b 00 0c 06 1e 00 00 62 f2 24 00 01 27 ff 2b
<0004> fsm.c:322 OM2000-BTS(0)[0x612000010120]{WAIT-TRX-LAPD}: Timeout of T0
<0004> abis_om2000.c:2519 OM2000-BTS(0)[0x612000010120]{WAIT-TRX-LAPD}: Received Event TRX-LAPD-UP
<0004> abis_om2000.c:2424 OM2000-BTS(0)[0x612000010120]{WAIT-TRX-LAPD}: state_chg to WAIT-TRX
<0004> fsm.c:461 OM2000-TRX(0-0)[0x6120000eb8a0]{INIT}: Allocated
<0004> abis_om2000.c:65 OM2000-TRX(0-0)[0x6120000eb8a0]{INIT}: is child of OM2000-BTS(0)[0x612000010120]
<0004> abis_om2000.c:2286 OM2000-TRX(0-0)[0x6120000eb8a0]{INIT}: Received Event START
<0004> abis_om2000.c:2139 OM2000-TRX(0-0)[0x6120000eb8a0]{INIT}: state_chg to WAIT-TRXC
<0004> fsm.c:461 OM2000-MO(0-0-TRXC-00-ff-00)[0x6120000eba20]{INIT}: Allocated
<0004> abis_om2000.c:65 OM2000-MO(0-0-TRXC-00-ff-00)[0x6120000eba20]{INIT}: is child of OM2000-TRX(0-0)[0x6120000eb8a0]
<0004> abis_om2000.c:2019 OM2000-MO(0-0-TRXC-00-ff-00)[0x6120000eba20]{INIT}: Received Event START
<0004> abis_om2000.c:1685 OM2000-MO(0-0-TRXC-00-ff-00)[0x6120000eba20]{INIT}: state_chg to WAIT-RES-COMPL
<0004> abis_om2000.c:1114 Tx MO=TRXC/00/ff/00 Reset Command
</pre><br /></pre> OsmoSGSN - Bug #4599 (New): counter group sgsn:pdpctx already exists for index X, instead using Yhttps://osmocom.org/issues/45992020-06-08T18:05:33Zlaforge
<p>When using OsmoSGSN (current nightly) in a setup with 3rd party 2G BSS and 3G RAN, we are running quite often into the following error message:</p>
<pre>
<0020> rate_ctr.c:224 counter group 'sgsn:pdpctx' already exists for index 5, instead using index 8. This is a software bug that needs fixing.
</pre>
<p>I wonder how this happens. It basically means we want to allocate a PDP context for the same NSAPI where we already have a PDP context.</p>
<p>The only path that calls sgsn_pdp_ctx_alloc() is sgsn_create_pdp_ctx() via activate_ggsn() originating from do_act_pdp_req() and the latter actually chekcs if we already have a PDP context fro the NSAPI in sgsn_pdp_ctx_by_nsapi. weird.</p>
<p><a class="user active" href="https://osmocom.org/users/1741">lynxis</a> any ideas?</p> Cellular Network Infrastructure - Bug #4578 (New): Updated slides / presentations / videos on set...https://osmocom.org/issues/45782020-06-03T14:56:52Zlaforge
<p>I just realized that since OsmoCon was discontinued after 2018 didn't result in sufficient turn-out, and only the 2017 incarnation contained some entry-level talks, we actually only have introductory level presentations / videos about a setup that still covers OsmoNITB. (<a class="external" href="https://media.ccc.de/v/osmocon17-4002-running_a_basic_circuit_switched_osmocom_gsm_network">https://media.ccc.de/v/osmocon17-4002-running_a_basic_circuit_switched_osmocom_gsm_network</a>)</p>
<p>This may or may not be a reason why some people still want to set up OsmoNITB in 2020. While our wiki and user manuals all have deprecated OsmoNITB years ago, people who only look for videos might be mislead.</p>
<p>Also, I'm sure that several other presentation (like the one about 3G / osmo-iuh before the CNI split) would similarly benefit from an update.</p>
<p>So I think we should try to create/update some slide decks and record related lectures / tutorials at some point this year. I wouldn't bother setting up a virtual conference or some kind of remote interaction at this point. Recording some talks and/or screencasts allows us to create and release them one-by-one.</p>
<p>Let's use this issue to first collect a list of topics that we think either need an update, or topics that never have been covered so far.</p> OsmoTRX - Bug #4469 (New): osmo-trx-uhd is sending UDP packets to port 49600 at various addresses...https://osmocom.org/issues/44692020-03-22T11:01:19Zlaforge
<pre>
[pid 14332] sendmsg(10, {msg_name={sa_family=AF_INET, sin_port=htons(49600), sin_addr=inet_addr("127.255.255.255")}, msg_namelen=16, msg_iov=[{iov_base="MPM-DISC", iov_len=8}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 8
[pid 14332] sendmsg(10, {msg_name={sa_family=AF_INET, sin_port=htons(49600), sin_addr=inet_addr("192.168.103.255")}, msg_namelen=16, msg_iov=[{iov_base="MPM-DISC", iov_len=8}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 8
[pid 14332] sendmsg(10, {msg_name={sa_family=AF_INET, sin_port=htons(49600), sin_addr=inet_addr("10.8.0.2")}, msg_namelen=16, msg_iov=[{iov_base="MPM-DISC", iov_len=8}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 8
[pid 14332] sendmsg(10, {msg_name={sa_family=AF_INET, sin_port=htons(49600), sin_addr=inet_addr("176.16.222.255")}, msg_namelen=16, msg_iov=[{iov_base="MPM-DISC", iov_len=8}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 8
[pid 14332] sendmsg(10, {msg_name={sa_family=AF_INET, sin_port=htons(49600), sin_addr=inet_addr("176.16.46.255")}, msg_namelen=16, msg_iov=[{iov_base="MPM-DISC", iov_len=8}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 8
</pre> OsmoBTS - Bug #4440 (New): osmo_bts_virtual doesn't detect if mobile/virtphy is gonehttps://osmocom.org/issues/44402020-03-07T15:44:35Zlaforge
<p>With a real physical layer, the BTS detects when the MS is gone. After some time without valid uplink blocks on the SACCH, T200 expires N200+1 times and a related RLL error indication is sent on Abis to the BSC.</p>
<p>When using osmo-bts-virtual, we don't appear to have any such mechanism, leaving channels on the MSC/BSC/BTS open indefinitely even if the related MS is gone.</p> SIMtrace 2 - Bug #4430 (New): firmware can get in endless out-of-memory loop on OUT EP floodhttps://osmocom.org/issues/44302020-03-01T15:06:25Zlaforge
<p>When flooding the OUT EP with too many messages, the firmware can get into an OOM situation from which it doesn't recover anymore. All it will do is print the below messages:</p>
<pre>
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
</pre>
<p>I'm currently reproducing this with a test case that sends 1000 bogus OUT EP transfers to the device.</p> OsmocomBB - Bug #4354 (New): update wiki about GTM-900B compatibilityhttps://osmocom.org/issues/43542020-01-09T21:42:48Zlaforge
<p>Since <a class="external" href="http://git.osmocom.org/osmocom-bb/commit/?id=ad84c7b2f7ca3bebf508c250482e49ba01ae89d6">http://git.osmocom.org/osmocom-bb/commit/?id=ad84c7b2f7ca3bebf508c250482e49ba01ae89d6</a> we've had GTM-900B support, let's list it at <a class="wiki-page" href="https://osmocom.org/projects/baseband/wiki/Phones">Phones</a> and create a wiki page about it, with pcb pictures, manual PDF, etc.</p> libosmocore - Bug #4149 (New): osmo_fsm allows event names to have spaces in themhttps://osmocom.org/issues/41492019-08-13T10:58:36Zlaforge
<p>See <a class="external" href="https://gerrit.osmocom.org/#/c/libosmocore/+/15154/">https://gerrit.osmocom.org/#/c/libosmocore/+/15154/</a></p>
<p>event names, like state names, should be one word <strong>only</strong>.</p> Cellular Network Infrastructure - Bug #4141 (New): No osmux specific code in place during codec n...https://osmocom.org/issues/41412019-08-05T15:57:19Zpespin
<p>Current code in OsmoBSC and OsmoMSC doesn't take into account that Osmux is to be used when codec negotiation goes one. That means that supported codec list needs to be correctly configured manually in VTY in order to avoid selecting incorrect codecs (like non-AMR). Moreover if an MS doesn't support AMR, since we don't have transcoding yet, the call cannot take place.</p>
<p>Different scenarios need to be listed here and think about what we want to do in each case.</p> libosmocore - Bug #4104 (New): support for KASME generationhttps://osmocom.org/issues/41042019-07-12T10:14:52Zlaforge
<p>In an LTE HSS, the normal UMTS AKA is executed up to the point where the vectors/quintuples are generated. However, not the CK+IK is passed back to over Diameter to the MME, but KASME, which is computed from CK+IK, the MCC+MNC of the VPLMN and some other bits.</p>
<p>Let's add support for this to libosmocore</p> SIMtrace 2 - Bug #4041 (New): implement SIMTRACE_CMD_BD_BOARD_INFOhttps://osmocom.org/issues/40412019-06-04T15:57:19Zlaforge
<p>this command is supposed to return the hardware manufacturer, hardware version as well as software version information. It would be very useful to obtain the currently running firmware versin as well as other details.</p> SIMtrace 2 - Bug #3712 (New): TRACE_FATAL not printinghttps://osmocom.org/issues/37122018-11-27T10:57:30Ztsaitgaist
<p>TRACE_FATAL should print and enter an endless loop (until the watchdog bites).<br />currently is only does the later and no debug message is printed.<br />check if it uses the synchronous/un-buffered UART output</p> OsmoBSC - Bug #3020 (New): OsmoBSC PCU socket interface not yet tested by BSC_Tests.ttcnhttps://osmocom.org/issues/30202018-03-01T16:34:00Zlaforge
<p>While the PCU socket of OsmoBTS alreasy has extensive test coverage in BTS_Tests.ttcn, we don't do any testing of the PCU socket in OsmoBSC from BSC_Tests.ttcn so far. This should change.</p> OsmoMSC - Bug #2928 (New): OsmoMSC doesn't do BSSMAP ASSIGNMENT if no MNCC_RTP_CREATE is receivedhttps://osmocom.org/issues/29282018-02-11T10:35:23Zlaforge
When operating OsmoMSC with external MNCC handler, it seems that it "forgets" to
<ul>
<li>perform BSSMAP ASSIGNMENT procedure</li>
<li>perform CRCX/MDCX on MGW endpoint for RAN side<br />if the eternal MNCC handler is not sending the MNCC_RTP_CREATE.</li>
</ul>
<p>This is wrong and indicates the state machines have some trouble.</p>
<p>The voice call should be established towards MS/RAN/MGW as usual, no matter if and when an external MNCC handler decides to actually connect to the MSC-located MGW. The MNCC_RTP_{CREATE,MODIFY} should only be translated to CRCX/MDCX of the mncc-side connection to OsmoMGW, and not anything on the RAN side.</p> OsmoPCU - Bug #2383 (New): incompatibility with some SGSNs during P-TMSI allocationhttps://osmocom.org/issues/23832017-07-20T15:23:17Zlaforge
When OsmoSGSN talks to OsmoPCU during a P-TMSI allocation (e.g. as part of GMM ATTACH ACCEPT), it sends that GMM ATTACH ACCEPT in a BSSGP DL-UNITDATA BSSGP PDU structured as follows:
<ul>
<li>include the IMSI IE (after authentication the SGSN knows the IMSI and shall include it as per TS 08.18)</li>
<li>include the TLLI IE, stating the previous TLLI derived from the old P-TMSI. This makes sense, given the fact that the MS cannot yet know the new P-TMSI which is about to be allocated now</li>
<li>include the MS Radio Access Capability IE filled in with information from the GMM ATTACH REQUEST</li>
<li>does not include any "OLD TLLI" IE</li>
</ul>
When talking to an unknown version of a Quortus SGSN, the behavior is different. The GMM ATTACH ACCEPT in BSSGP DL-UNITDATA
<ul>
<li>does not include the IMSI IE (despite the SGSN knowing the IMSI, i.e. it is a violation of TS 08.18)</li>
<li>includes the TLLI IE with a TLLI derived from the new to-be-communicated P-TMSI</li>
<li>includes no MS Radio Access Capability IE, despite the MS having sent them in the GMM ATTACH REQUEST</li>
<li>includes an OLD TLLI IE with the TLLI derived from the P-TMSI that was in use until now.</li>
</ul>
<p>This results in OsmoPCU not being able to deliver the GMM ATTACH ACCEPT to the MS, and subsequently the ATTACH operation timing out at the SGSN, folowed by several (re-)transmissions of a SGSN-initiated GMM DETACH REQUEST (which is equally not delieverd by OsmoPCU).</p>
We need to investigate
<ul>
<li>which parts of the Quortus behavior are within spec and which are out of spec</li>
<li>whether OsmoSGSN behaves within spec</li>
<li>whether OsmoPCU can be easily extended to comply with both approaches</li>
</ul> libosmo-sccp + libosmo-sigtran - Bug #2259 (New): problem with local referencehttps://osmocom.org/issues/22592017-05-16T13:05:55Zdexter
<p>When a connection attemt (local reference = 2) is made, libosmo-sccp complains with "<000d> sccp_scoc.c:1528 Cannot find connection for local reference 2". Current master is at 872c6b2a8e309ca6739ef295f1fc468c189e4ec9. The problem seems to be introduced with commit 5527df78adc08b76df07c4b682263b5bdd6181d4 (libosmo-sccp.git). When the commit is reverted, the correct functionality of libosmo-sccp seems to be restored.</p>
<p>The problem can be demonstrated by using the client/server example that is shipped with libosmo-sccp. The following VTY-Commands were used to trigger the problem:</p>
<pre>
enable
sccp-user
called-addr-ssn 202
connect-req 2 hello
</pre>
<p>Note: In the good case I can see the normal CR with payload attached and the CC that with the payload that is echoed by the the echo subsystem. The bad case results in an CREF message, which contains an refusal cause code 0x0F (unqalified)</p> libosmocore - Bug #1762 (New): Review LAPD code for race conditions regarding state, particularly...https://osmocom.org/issues/17622016-07-03T20:20:39Zlaforge
<p>See <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: LAPD: segfault in T200 call-back (Closed)" href="https://osmocom.org/issues/1760">#1760</a> and <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: LAPD: segfault when bootstrapping Nokia InSite (Resolved)" href="https://osmocom.org/issues/1761">#1761</a>, there are quite some problems that apparently need a more thorough review and/or testing.</p>
<p>Maybe implementing (part of?) the Q.921bis LAPD conformance tests might be an option to catch all of those kind of bugs?</p>
<p>See <a class="external" href="https://www.itu.int/rec/T-REC-Q.921bis-199303-I/en">https://www.itu.int/rec/T-REC-Q.921bis-199303-I/en</a></p>