Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-06T12:08:24ZOpen Source Mobile Communications
Redmine 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> OsmoHNBGW - Bug #6380 (New): VTY transcript tests are broken [again]https://osmocom.org/issues/63802024-02-28T18:34:06Zfixeria
<p>The <a href="https://jenkins.osmocom.org/jenkins/view/master/job/master-osmo-hnbgw/" class="external">master-osmo-hnbgw</a> Jenkins job is broken since Feb 27th.</p>
<pre>
Error during transcript step 3:
[
OsmoHNBGW# show cs7 config
cs7 instance 0
point-code 0.23.5
asp asp-clnt-msc-0 2905 0 m3ua
local-ip localhost
remote-ip localhost
role asp
sctp-role client
as as-clnt-msc-0 m3ua
asp asp-clnt-msc-0
routing-key 0 0.23.5
]
Error while verifying transcript file './config//defaults.vty'
Traceback (most recent call last):
File "/usr/local/lib/python3.11/dist-packages/osmopython-0.2.1-py3.11.egg/osmopy/osmo_interact/common.py", line 357, in verify_application
interact.verify_transcript_file(transcript_file)
File "/usr/local/lib/python3.11/dist-packages/osmopython-0.2.1-py3.11.egg/osmopy/osmo_interact/common.py", line 111, in verify_transcript_file
result = self.verify_transcript(content)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/dist-packages/osmopython-0.2.1-py3.11.egg/osmopy/osmo_interact/common.py", line 199, in verify_transcript
raise Exception('Result mismatch:\n%s\n\nExpected:\n[\n%s\n]\n\nGot:\n[\n%s\n%s\n]'
Exception: Result mismatch:
Mismatch:
Expect:
' sctp-role client'
Got:
' transport-role client'
Expected:
[
OsmoHNBGW# show cs7 config
cs7 instance 0
point-code 0.23.5
asp asp-clnt-msc-0 2905 0 m3ua
local-ip localhost
remote-ip localhost
role asp
sctp-role client
as as-clnt-msc-0 m3ua
asp asp-clnt-msc-0
routing-key 0 0.23.5
]
Got:
[
OsmoHNBGW# show cs7 config
cs7 instance 0
point-code 0.23.5
asp asp-clnt-msc-0 2905 0 m3ua
local-ip localhost
remote-ip localhost
role asp
transport-role client
as as-clnt-msc-0 m3ua
asp asp-clnt-msc-0
routing-key 0 0.23.5
]
RESULTS:
FAIL: ./config//defaults.vty
</pre>
<p>This is a side effect of my patch that has been merged to libosmo-sccp.git:</p>
<p><a class="external" href="https://cgit.osmocom.org/libosmo-sccp/commit/?id=4d7e20193c264585080b9edc91eb630dd005e396">https://cgit.osmocom.org/libosmo-sccp/commit/?id=4d7e20193c264585080b9edc91eb630dd005e396</a></p>
<pre>
commit 4d7e20193c264585080b9edc91eb630dd005e396
Author: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Date: Thu Feb 15 05:29:14 2024 +0700
VTY: rename 'sctp-role' to 'transport-role', add an alias
</pre> OsmocomBB - Feature #6348 (New): virtphy: add Circuit Switched Data (CSD) supporthttps://osmocom.org/issues/63482024-01-26T22:03:21Zfixeria
<p>Since recently, Calypso PHY and trxcon support data traffic channels needed for CSD:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/34694">https://gerrit.osmocom.org/c/osmocom-bb/+/34694</a> firmware/layer1: handle CSD related channel modes<br /><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/32922">https://gerrit.osmocom.org/c/osmocom-bb/+/32922</a> trxcon/l1sched: implement CSD scheduling support</p>
<p>For the sake of completeness, let's add data traffic channel support to virtphy.</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> Cellular Network Infrastructure - Feature #6243 (New): vty cfg: make changing startup defaults of...https://osmocom.org/issues/62432023-11-01T00:56:38Zneelsnhofmeyr@sysmocom.de
<p>Sometimes our recommendation of what the usual/good setting should be for a given vty config item changes.<br />Then we have the problem that we cannot change it without endangering running installations,<br />and/or creating hassle for admins.</p>
<p>So how about a general mechanism in all of our config files in form of a vty command, maybe like this:</p>
<p>osmo-foo.cfg:<br /><pre>
defaults (v0|v1.5|v1.6)
</pre></p>
<p>so a user can decide when to make the cfg upgrade, independently from binary upgrades.</p>
<p>When 'defaults' is not specified, we would have to assume like 'defaults v0'.<br />(A bit more convenient for new users would be to add the newest available 'defaults' setting automatically somehow,<br />but I guess that also breaks the entire feature then, unless someone can think of an elegant way.)</p> 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> OsmoPCU - Feature #5834 (New): VTY option "two-phase-access" is misleadinghttps://osmocom.org/issues/58342022-12-19T18:54:58Zpespin
<p>the option "two-phase-access" doesn't "enable" the MS to use two-phase-access, but actually forces it to do 2phase even if it requrested 1phase.<br />Hence, the VTY command should contain the name "force" in it, ie force-two-phase-access.</p>
<p>We could even change the VTY command to be two-phase-access (forbid|allow|enforce). This would allow also forcing MS to always do 1phase access (mostly useful for testing purposes or if a bug in 2phase is found).</p> Open Source IMS Client - Feature #5482 (New): VoWiFi client for creating [outer] IPsec tunnel to ...https://osmocom.org/issues/54822022-03-07T11:00:19Zlaforge
For <a class="wiki-page" href="https://osmocom.org/projects/foss-ims-client/wiki/VoWiFi">VoWiFi</a>, we need an IPsec implementation that has been extended with the requirements for the 3GPP SWu interface, specifically
<ul>
<li>the EAP-AKA mechanism for UMTS-AKA based authentication</li>
<li>some external interface to access a USIM for authentication</li>
</ul>
<p>We've been evaluating two different paths here:</p>
<ul>
<li><a class="external" href="https://github.com/fasferraz/SWu-IKEv2">https://github.com/fasferraz/SWu-IKEv2</a> - rather hackish python codebase, <a class="user active" href="https://osmocom.org/users/7">laforge</a> had difficulties getting it to work with at least two IMS operators</li>
<li>a slightly modified version of strongswan. <a class="user active" href="https://osmocom.org/users/291299">domi</a> has been doing some development about this. <a class="user active" href="https://osmocom.org/users/7">laforge</a> had more success with this, at least to establish the SWu tunnel successfully once - it then failed in subsequent operations.</li>
</ul> OsmoHNBGW - Bug #5304 (New): Verizon CDMA femtocellhttps://osmocom.org/issues/53042021-11-10T15:32:33Zcopslock
<p>Verizon Samsung SCS-2U01 is a very famous target for many hackers,while as Harald said in 32C3,none of them even thought about running a local network upon it.Verizon is phasing out its CDMA network,it's time to play with these valuable blackbox<br /><img src="https://scache.vzw.com/content/dam/support/images/network_extender.png" alt="" /><br />It looks like the IS95 core network is a bit simpler than 3GPP network,however,there is no project about IS95 at all,Neither the data PDSN nor the IS95 MSC.</p> OsmoMSC - Bug #5196 (New): Verify several "event not permitted" log lines in unit testshttps://osmocom.org/issues/51962021-07-12T11:48:53Zpespin
<pre>
pespin ~/dev/sysmocom/git/osmo-msc $ ag "not permitted" tests/msc_vlr/ | grep Event
tests/msc_vlr/msc_vlr_test_gsm_authen.err:60:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:649:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:1480:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:1793:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:2058:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:2324:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_gsm_authen.err:3242:DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A:LU){VLR_ULA_S_WAIT_AUTH}: Event VLR_ULA_E_HLR_LU_RES not permitted
tests/msc_vlr/msc_vlr_test_ms_timeout.err:814:DMSC msc_a(IMSI-901700000004620:GERAN-A:LU){MSC_A_ST_WAIT_CLASSMARK_UPDATE}: Event MSC_A_EV_UNUSED not permitted
</pre>
<p>We should check whether those events are indeed not expected and only triggered by tests, or whether they can happen and hence we should allow them and handle them properly in the FSM.</p>
<p>Similar to:<br /><a class="external" href="https://gerrit.osmocom.org/c/osmo-msc/+/24916">https://gerrit.osmocom.org/c/osmo-msc/+/24916</a> msc_a.c: Allow MSC_A_EV_CN_CLOSE in state MSC_A_ST_RELEASING</p> Cellular Network Infrastructure - Feature #5045 (New): write libversion "major" on build files au...https://osmocom.org/issues/50452021-02-24T12:41:58Zpespin
<p>As a reminder:<br /><a class="external" href="https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html">https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html</a></p>
<p>LIBVERSION = current:revision:age<br />LIBVERSION_MAJOR = current - age</p>
Right now we usually use the form "{*_}LIBVERSION = 1:2:3" in Makefile.am, and we hardcode the resulting LIBVERSION_MAJOR in lots of files, namely:
<ul>
<li>debian/control</li>
<li>debian/rules</li>
<li>contrib/*.spec.in</li>
</ul>
<p>The idea here would be to generate LIBVERSION_MAJOR automatically as a autconf/automake variable which can be fed into those files automatically, so we don't have to update them every time LIBCERSION_MAJOR changes (and hence potentially avoid breakage during release time).</p>
So, I'd follow these steps for each project:
<ul>
<li>Normalize the LIBVERSION variable to follow a standardized naming, so that we can track it later better on osmo-release.sh, for instance ${LIBNAME}_LIBVERSION (replacing "-" with "_"). Example: LIBOSMO_NETIF_LIBVERSION. Or even better, LIBVERSION_LIBOSMO_NETIF.</li>
<li>Have LIBVERSION variable be generated out of 3 new variables (also following normalized name with LIBNAME), example: <br /><pre>
LIBVERSION_CURRENT_LIBOSMO_NETIF = 3
LIBVERSION_REVISION_LIBOSMO_NETIF = 2
LIBVERSION_AGE_LIBOSMO_NETIF = 1
LIBVERSION_MAJOR_LIBOSMO_NETIF = LIBVERSION_CURRENT_LIBOSMO_NETIF - LIBVERSION_AGE_LIBOSMO_NETIF
</pre></li>
</ul>
<ul>
<li>Use $LIBVERSION_MAJOR_LIBOSMO_NETIF in the files mentioned above</li>
<li>Update osmo-release.sh to follow new naming</li>
</ul>
Considerations:
<ul>
<li>We may need to move debian/control to debian/control.in so we can template it? That means also configure must be run before generating the package, I guess that's expected?</li>
</ul> libosmocore - Bug #5029 (New): vty: optional cases with multiple arguments is undefined behaviourhttps://osmocom.org/issues/50292021-02-16T21:08:02Zlynxis
<p>E.g.<br /><pre>
DEFUN(cfg_ns_nse_nsvc_udp, cfg_ns_nse_nsvc_udp_cmd, "nsvc udp BIND " VTY_IPV46_CMD " <1-65535> [signalling-weight <0-254> data-weight <0-254>]"
</pre></p>
<p>results in an autocomplete of "[signalling-weigh". The missing <strong>t</strong>. However data-weight is ok again.<br />The follow patch with patchset 9 is showing this bug. <a class="external" href="https://gerrit.osmocom.org/c/libosmocore/+/22900/9/">https://gerrit.osmocom.org/c/libosmocore/+/22900/9/</a></p> Core testing infrastructure - Bug #5011 (New): Warning about unrecognized escape sequence in Osm...https://osmocom.org/issues/50112021-02-05T11:21:22Zpespin
<pre>
Osmocom_CTRL_Types.ttcn:26.39-88: In character string pattern:
Osmocom_CTRL_Types.ttcn:26.44-45: warning: Use of unrecognized escape sequence `\{' is deprecated
Osmocom_CTRL_Types.ttcn:26.46-47: warning: Use of unrecognized escape sequence `\}' is deprecated
</pre>
<p>The code:<br /><pre>
type charstring CtrlVariable (pattern "[^, \{\}\[\]\(\)<>\|~\\\^`'\"\?=;/\+&%$\#!]#(1,)");
</pre></p>
<p>Shall we simply remove the "\" before "{" and "}" ?</p> gr-osmosdr - Bug #4942 (New): XTRX: Unable to compile due to errorhttps://osmocom.org/issues/49422021-01-12T20:29:05ZRFNOD
<p>Is it possible to change the following within gr-osmosdr/lib/xtrx/xtrx_obj.cc, Line 71?</p>
<p>++ int res = xtrx_open_list(path.c_str(), NULL, &_obj);<br />-- int res = xtrx_open_string(path.c_str(), &_obj);</p>
<p>After changing that line, I was able to compile gr-osmosdr.</p> OsmoPCU - Bug #4869 (New): wireshark: Support dissecting LLC frames on top of RLCMAC (E)GPRS data...https://osmocom.org/issues/48692020-11-26T13:00:30Zpespin
<p>Since recently wireshark is able to correctly identify rlcmac data payload (llc frames), and identify padding, spare bits, etc.</p>
Next step is to call the LLC dissector to try to dissect the llc frames of:
<ul>
<li>GPRS UL data blocks</li>
<li>GPRS DL data blocks</li>
<li>EGPRS UL data blocks</li>
<li>EGPRS DL data blocks</li>
</ul>
<p>This will help in quickly finding out if data forwarded from/to RLCMAC has any issue.</p>
<p>I so far have a quick patch which already works for UL and DL GPRS data packets which don't need to be defragmented.<br />So work needs to be done to support fragmentation, and EGPRS as well.<br />Supporting fragmentation probably means we also need to identify TBFs by TFI or something similar, to be able to track the fragments.</p> OsmoHNBGW - Feature #4790 (New): Vodafone HSPA+ femtocell availiable in Deutschlandhttps://osmocom.org/issues/47902020-10-09T08:35:38Zcopslock
<p>Seems like the Vodafone femtocell 3802V widely availiable on ebay sites recently,it's based on broadcom solution and runs on the Standard Iuh interface,better alternative choice than expensive Erricson smallcells<br /><img src="https://i.ebayimg.com/images/g/VVsAAOSwk25cfrfc/s-l1600.jpg" alt="" /><br /><img src="https://i.ebayimg.com/images/g/wskAAOSwpCFcfrfd/s-l1600.jpg" alt="" /></p> OsmoMSC - Bug #4784 (New): wrong cause code (resources unavailable) in MO-to-MT call without resp...https://osmocom.org/issues/47842020-10-08T13:24:35Zlaforge
<p>if a MO-to-MT call is performed using osmo-msc with internal MNCC handler, and the call proceeds up to the "ALERTING" being sent by the MT-leg (but the call is never accepted by the MT side), the CC RELEASE is sent using cause value "resources unavailable, unspecified" (GSM48_CC_CAUSE_RESOURCE_UNAVAIL). This is quite misleading to users, and one is trying to find what kind of resources miight be exhausted. But there is no exhaustion, "B" just never responded the call from "A".</p> OsmoMSC - Bug #4451 (New): vty 'show stats level': different stats levels yield identical resultshttps://osmocom.org/issues/44512020-03-09T22:10:16Zneelsnhofmeyr@sysmocom.de
<p>no matter which stats level I choose on the vty, I always get 100% identical results.</p>
<p>Also, the vty command 'level' doc says "Set the maximum group level" which sounds like it changes osmo-msc's state,<br />which should not be the case for a 'show' command.</p>
<pre>
OsmoMSC> show stats?
level Set the maximum group level
<cr>
OsmoMSC> show stats level?
global Show global groups only
peer Show global and network peer related groups
subscriber Show global, peer, and subscriber groups
OsmoMSC> show stats
Ungrouped counters:
mobile switching center:
Received Location Update (IMSI Attach) requests.: 0 (0/s 0/m 0/h 0/d)
Received Location Update (LAC change) requests.: 200 (0/s 0/m 0/h 0/d)
Received (periodic) Location Update requests.: 0 (0/s 0/m 0/h 0/d)
Received IMSI Detach indications.: 0 (0/s 0/m 0/h 0/d)
Rejected Location Update requests.: 0 (0/s 0/m 0/h 0/d)
Successful Location Update procedures.: 200 (0/s 0/m 0/h 0/d)
Rejected CM Service Requests.: 0 (0/s 0/m 0/h 0/d)
Accepted CM Service Requests.: 0 (0/s 0/m 0/h 0/d)
Rejected Paging Responses.: 0 (0/s 0/m 0/h 0/d)
Accepted Paging Responses.: 0 (0/s 0/m 0/h 0/d)
Total MO SMS received from the MS.: 0 (0/s 0/m 0/h 0/d)
Failed MO SMS delivery attempts (no receiver found).: 0 (0/s 0/m 0/h 0/d)
Total MT SMS delivery attempts.: 0 (0/s 0/m 0/h 0/d)
Failed MT SMS delivery attempts (no memory).: 0 (0/s 0/m 0/h 0/d)
Failed MT SMS delivery attempts (other reason).: 0 (0/s 0/m 0/h 0/d)
Failed MO SMS delivery attempts (other reason).: 0 (0/s 0/m 0/h 0/d)
Received MO SETUP messages (MO call establishment).: 0 (0/s 0/m 0/h 0/d)
Received MO CONNECT messages (MO call establishment).: 0 (0/s 0/m 0/h 0/d)
Sent MT SETUP messages (MT call establishment).: 0 (0/s 0/m 0/h 0/d)
Sent MT CONNECT messages (MT call establishment).: 0 (0/s 0/m 0/h 0/d)
Calls that ever reached the active state.: 0 (0/s 0/m 0/h 0/d)
Calls terminated by DISCONNECT message after reaching the active state.: 0 (0/s 0/m 0/h 0/d)
Calls terminated by any other reason after reaching the active state.: 0 (0/s 0/m 0/h 0/d)
Received MS-initiated call independent SS/USSD requests.: 0 (0/s 0/m 0/h 0/d)
Established MS-initiated call independent SS/USSD sessions.: 0 (0/s 0/m 0/h 0/d)
Received network-initiated call independent SS/USSD requests.: 0 (0/s 0/m 0/h 0/d)
Established network-initiated call independent SS/USSD sessions.: 0 (0/s 0/m 0/h 0/d)
Number of CIPHER MODE REJECT messages processed by BSSMAP layer: 0 (0/s 0/m 0/h 0/d)
Number of CIPHER MODE COMPLETE messages processed by BSSMAP layer: 0 (0/s 0/m 0/h 0/d)
network statistics:
Currently active calls : 0
Currently active SS/USSD sessions: 0
OsmoMSC> show stats l
OsmoMSC> show stats level global
Ungrouped counters:
mobile switching center:
Received Location Update (IMSI Attach) requests.: 0 (0/s 0/m 0/h 0/d)
Received Location Update (LAC change) requests.: 200 (0/s 0/m 0/h 0/d)
Received (periodic) Location Update requests.: 0 (0/s 0/m 0/h 0/d)
Received IMSI Detach indications.: 0 (0/s 0/m 0/h 0/d)
Rejected Location Update requests.: 0 (0/s 0/m 0/h 0/d)
Successful Location Update procedures.: 200 (0/s 0/m 0/h 0/d)
Rejected CM Service Requests.: 0 (0/s 0/m 0/h 0/d)
Accepted CM Service Requests.: 0 (0/s 0/m 0/h 0/d)
Rejected Paging Responses.: 0 (0/s 0/m 0/h 0/d)
Accepted Paging Responses.: 0 (0/s 0/m 0/h 0/d)
Total MO SMS received from the MS.: 0 (0/s 0/m 0/h 0/d)
Failed MO SMS delivery attempts (no receiver found).: 0 (0/s 0/m 0/h 0/d)
Total MT SMS delivery attempts.: 0 (0/s 0/m 0/h 0/d)
Failed MT SMS delivery attempts (no memory).: 0 (0/s 0/m 0/h 0/d)
Failed MT SMS delivery attempts (other reason).: 0 (0/s 0/m 0/h 0/d)
Failed MO SMS delivery attempts (other reason).: 0 (0/s 0/m 0/h 0/d)
Received MO SETUP messages (MO call establishment).: 0 (0/s 0/m 0/h 0/d)
Received MO CONNECT messages (MO call establishment).: 0 (0/s 0/m 0/h 0/d)
Sent MT SETUP messages (MT call establishment).: 0 (0/s 0/m 0/h 0/d)
Sent MT CONNECT messages (MT call establishment).: 0 (0/s 0/m 0/h 0/d)
Calls that ever reached the active state.: 0 (0/s 0/m 0/h 0/d)
Calls terminated by DISCONNECT message after reaching the active state.: 0 (0/s 0/m 0/h 0/d)
Calls terminated by any other reason after reaching the active state.: 0 (0/s 0/m 0/h 0/d)
Received MS-initiated call independent SS/USSD requests.: 0 (0/s 0/m 0/h 0/d)
Established MS-initiated call independent SS/USSD sessions.: 0 (0/s 0/m 0/h 0/d)
Received network-initiated call independent SS/USSD requests.: 0 (0/s 0/m 0/h 0/d)
Established network-initiated call independent SS/USSD sessions.: 0 (0/s 0/m 0/h 0/d)
Number of CIPHER MODE REJECT messages processed by BSSMAP layer: 0 (0/s 0/m 0/h 0/d)
Number of CIPHER MODE COMPLETE messages processed by BSSMAP layer: 0 (0/s 0/m 0/h 0/d)
network statistics:
Currently active calls : 0
Currently active SS/USSD sessions: 0
OsmoMSC> show stats level peer
Ungrouped counters:
mobile switching center:
Received Location Update (IMSI Attach) requests.: 0 (0/s 0/m 0/h 0/d)
Received Location Update (LAC change) requests.: 200 (0/s 0/m 0/h 0/d)
Received (periodic) Location Update requests.: 0 (0/s 0/m 0/h 0/d)
Received IMSI Detach indications.: 0 (0/s 0/m 0/h 0/d)
Rejected Location Update requests.: 0 (0/s 0/m 0/h 0/d)
Successful Location Update procedures.: 200 (0/s 0/m 0/h 0/d)
Rejected CM Service Requests.: 0 (0/s 0/m 0/h 0/d)
Accepted CM Service Requests.: 0 (0/s 0/m 0/h 0/d)
Rejected Paging Responses.: 0 (0/s 0/m 0/h 0/d)
Accepted Paging Responses.: 0 (0/s 0/m 0/h 0/d)
Total MO SMS received from the MS.: 0 (0/s 0/m 0/h 0/d)
Failed MO SMS delivery attempts (no receiver found).: 0 (0/s 0/m 0/h 0/d)
Total MT SMS delivery attempts.: 0 (0/s 0/m 0/h 0/d)
Failed MT SMS delivery attempts (no memory).: 0 (0/s 0/m 0/h 0/d)
Failed MT SMS delivery attempts (other reason).: 0 (0/s 0/m 0/h 0/d)
Failed MO SMS delivery attempts (other reason).: 0 (0/s 0/m 0/h 0/d)
Received MO SETUP messages (MO call establishment).: 0 (0/s 0/m 0/h 0/d)
Received MO CONNECT messages (MO call establishment).: 0 (0/s 0/m 0/h 0/d)
Sent MT SETUP messages (MT call establishment).: 0 (0/s 0/m 0/h 0/d)
Sent MT CONNECT messages (MT call establishment).: 0 (0/s 0/m 0/h 0/d)
Calls that ever reached the active state.: 0 (0/s 0/m 0/h 0/d)
Calls terminated by DISCONNECT message after reaching the active state.: 0 (0/s 0/m 0/h 0/d)
Calls terminated by any other reason after reaching the active state.: 0 (0/s 0/m 0/h 0/d)
Received MS-initiated call independent SS/USSD requests.: 0 (0/s 0/m 0/h 0/d)
Established MS-initiated call independent SS/USSD sessions.: 0 (0/s 0/m 0/h 0/d)
Received network-initiated call independent SS/USSD requests.: 0 (0/s 0/m 0/h 0/d)
Established network-initiated call independent SS/USSD sessions.: 0 (0/s 0/m 0/h 0/d)
Number of CIPHER MODE REJECT messages processed by BSSMAP layer: 0 (0/s 0/m 0/h 0/d)
Number of CIPHER MODE COMPLETE messages processed by BSSMAP layer: 0 (0/s 0/m 0/h 0/d)
network statistics:
Currently active calls : 0
Currently active SS/USSD sessions: 0
OsmoMSC> show stats level sub
OsmoMSC> show stats level subscriber
Ungrouped counters:
mobile switching center:
Received Location Update (IMSI Attach) requests.: 0 (0/s 0/m 0/h 0/d)
Received Location Update (LAC change) requests.: 200 (0/s 0/m 0/h 0/d)
Received (periodic) Location Update requests.: 0 (0/s 0/m 0/h 0/d)
Received IMSI Detach indications.: 0 (0/s 0/m 0/h 0/d)
Rejected Location Update requests.: 0 (0/s 0/m 0/h 0/d)
Successful Location Update procedures.: 200 (0/s 0/m 0/h 0/d)
Rejected CM Service Requests.: 0 (0/s 0/m 0/h 0/d)
Accepted CM Service Requests.: 0 (0/s 0/m 0/h 0/d)
Rejected Paging Responses.: 0 (0/s 0/m 0/h 0/d)
Accepted Paging Responses.: 0 (0/s 0/m 0/h 0/d)
Total MO SMS received from the MS.: 0 (0/s 0/m 0/h 0/d)
Failed MO SMS delivery attempts (no receiver found).: 0 (0/s 0/m 0/h 0/d)
Total MT SMS delivery attempts.: 0 (0/s 0/m 0/h 0/d)
Failed MT SMS delivery attempts (no memory).: 0 (0/s 0/m 0/h 0/d)
Failed MT SMS delivery attempts (other reason).: 0 (0/s 0/m 0/h 0/d)
Failed MO SMS delivery attempts (other reason).: 0 (0/s 0/m 0/h 0/d)
Received MO SETUP messages (MO call establishment).: 0 (0/s 0/m 0/h 0/d)
Received MO CONNECT messages (MO call establishment).: 0 (0/s 0/m 0/h 0/d)
Sent MT SETUP messages (MT call establishment).: 0 (0/s 0/m 0/h 0/d)
Sent MT CONNECT messages (MT call establishment).: 0 (0/s 0/m 0/h 0/d)
Calls that ever reached the active state.: 0 (0/s 0/m 0/h 0/d)
Calls terminated by DISCONNECT message after reaching the active state.: 0 (0/s 0/m 0/h 0/d)
Calls terminated by any other reason after reaching the active state.: 0 (0/s 0/m 0/h 0/d)
Received MS-initiated call independent SS/USSD requests.: 0 (0/s 0/m 0/h 0/d)
Established MS-initiated call independent SS/USSD sessions.: 0 (0/s 0/m 0/h 0/d)
Received network-initiated call independent SS/USSD requests.: 0 (0/s 0/m 0/h 0/d)
Established network-initiated call independent SS/USSD sessions.: 0 (0/s 0/m 0/h 0/d)
Number of CIPHER MODE REJECT messages processed by BSSMAP layer: 0 (0/s 0/m 0/h 0/d)
Number of CIPHER MODE COMPLETE messages processed by BSSMAP layer: 0 (0/s 0/m 0/h 0/d)
network statistics:
Currently active calls : 0
Currently active SS/USSD sessions: 0
OsmoMSC>
</pre> osmo-sip-connector - Bug #3724 (New): Wrong media format used in SIP INVITE causes one-way audiohttps://osmocom.org/issues/37242018-12-11T14:57:28Zmanatails
<p>osmo-sip-connector from the latest git repository specifies wrong audio codec in SIP INVITE message.</p>
<p>When using osmo-sip-connector to bridge a nanoBTS and an asterisk server, osmo-sip-connector sends 0 as the media codec which corresponds to G.711 PCMU, causing asterisk to respond in g711 and nanoBTS is unable to parse it.</p>
<p>Attached is a packet capture between the BSC and Asterisk server.</p> rtl-sdr - Bug #3589 (New): Zerocopy Buffers Unusable Outside Callback Without memcpy()https://osmocom.org/issues/35892018-09-25T12:58:09Zxloem0xloem@gmail.com
<p>1. In May 2018, rtl-sdr was improved to work directly with DMA sample buffers <a class="external" href="http://git.osmocom.org/rtl-sdr/commit/?id=a854ae8b48d42e8dad514c75d3a4c6cfb62707da">http://git.osmocom.org/rtl-sdr/commit/?id=a854ae8b48d42e8dad514c75d3a4c6cfb62707da</a><br /> There is now no need for a memcpy() call if all processing is done in the callback function.</p>
<p>2. Unfortunately, major uses of librtlsdr process the data in another thread rather than the callback function. This is how gr-osmosdr and soapyrtl function.</p>
<p>3. Additionally, tracking buffer backlog requires returning from the callback rapidly, so that buffers can be counted as they are received. This is how gr-osmosdr behaves, outputting 'O' when processing is too slow: <a class="external" href="http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc#n307">http://git.osmocom.org/gr-osmosdr/tree/lib/rtl/rtl_source_c.cc#n307</a><br /> This lets the user of a high-level library know when latency is corrupting their stream, and currently requires the use of an extra memcpy() call.</p>
<p>4. These high-level libraries could take advantage of the DMA buffer improvement if there were a way to get buffers to stay alive after return from the callback.</p>
<p>After managing to listen to some concerns on the chat, I've posted an updated patch to the mailing list for this: <a class="external" href="http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001830.html">http://lists.osmocom.org/pipermail/osmocom-sdr/2018-September/001830.html</a></p> OsmoMSC - Feature #3165 (New): Verify LU Request's LAIhttps://osmocom.org/issues/31652018-04-12T15:09:39Zneelsnhofmeyr@sysmocom.de
<p>In a Location Updating Request, we receive a LAI, see 3GPP 24.008 9.2.15, IE "Location area identification", and 9.2.15.1 saying "The location area identification stored in the SIM/USIM is used." <br />Clarify the meaning of this: is this the last connected cell?<br />Do we need to accept/deny LU depending on validity of this IE, besides verifying the subscriber's IMSI as we already do?</p> SDR (Software Defined Radio) - Bug #3126 (New): Windows 10 Pro 1709: crash of rtl_test.exehttps://osmocom.org/issues/31262018-03-30T14:16:42ZJWS
<p>Hi,<br />I fixed the following crash using rtl_test.exe:</p>
<p>Found 2 device(s):<br /> 0: å, , SN: NÚ@<br /> 1: Realtek, RTL2838UHIDIR, SN: 00000001</p>
<p>Using device 0: Generic RTL2832U OEM<br />usb_open error -12<br />Failed to open rtlsdr device #0.</p>
<p>The fix is, to use version 1.0.22 of libusb.</p> OsmocomBB - Bug #2995 (New): Wrong parsing of PAGING TYPE 3https://osmocom.org/issues/29952018-02-24T23:03:52Zlaforge
<p>See <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: OsmoBTS wrong PAGING TYPE 3 REST OCTETS (Resolved)" href="https://osmocom.org/issues/2994">#2994</a> for the OsmoBTS side of this bug, which is the result of some wrong definition in libosmocore. Fixing it in the library without creating breakage is not easy, so let's try to fix it up manually in OsmocomBB, too.</p> OsmoBTS - Feature #2827 (New): would be nice if logging of the BTS number in osmo-bts matched the...https://osmocom.org/issues/28272018-01-12T01:10:20Zneelsnhofmeyr@sysmocom.de
<p>Looking at a GSMTAP-logging trace where osmo-bsc sends a channel activation to bts 1, followed by osmo-bts reporting the channel activation request received by bts 0 is confusing.<br />Of course the osmo-bts process has only one BTS and thus refers to it as "bts 0", the only indication which BTS the logging came from is the source IP address of the GSMTAP.</p>
<p>Theoretically, osmo-bsc could (in some osmocom-specific way) let the osmo-bts process know which bts number it is in osmo-bsc's perspective, and then the GSMTAP logging from each osmo-bts process would match up with the osmo-bsc GSMTAP logging BTS numbers.</p>
<p>Alternatively, the osmo-bts process could refrain from logging any BTS number at all.</p>
<p>Example: the last message here makes you stop and think: "what, bts=0? that must be wrong" ... not<br /><pre>
10535 127.0.0.1 127.0.0.10 GSMTAP 201 52530 4729 (bts=1,trx=0,ts=4,pchan=TCH/F) Allocating lchan=0 as TCH_F
10537 127.0.0.1 127.0.0.10 GSMTAP 201 52530 4729 (bts=1,trx=0,ts=4,ss=0) state NONE -> ACTIVATION REQUESTED
10541 192.168.0.10 192.168.0.125 RSL 112 CHANnel ACTIVation
10542 192.168.0.125 192.168.0.10 GSMTAP 184 48167 4729 (bts=0,trx=0,ts=4,ss=0) Rx RSL CHAN_ACTIV
</pre></p> linmodem - Bug #2797 (New): X11 support is 16bit plane onlyhttps://osmocom.org/issues/27972018-01-01T12:01:34Zlaforge
<p>Modern Xorg servers don't have 16bit planes anymore, we need to have 24/32bit plane support</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> OsmoMSC - Feature #1973 (New): VLR: efficient subscriber lookuphttps://osmocom.org/issues/19732017-03-08T14:52:10Zneelsnhofmeyr@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.<br />Storing numerous subscribers in a linear list is inefficient, implement a hash table for faster access times.</p> OsmoNITB - Bug #21 (New): we don't see CHANnel ReQireD from motorola EZX phones at call setuphttps://osmocom.org/issues/212016-02-19T22:47:31Zlaforge
<p>This is very weird. The EZX phones like E6, A1200, etc. can do a successful LOCATION UPDATING procedure, but after they are registered they can only process incoming calls.</p>
<p>so paging request is working, and the channel request procedure is working as part of the paging request and the location updating.</p>
<p>IF you want to start a MO call, we never see any channel required (i.e. RACH burst).</p>