Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092024-02-28T18:34:06ZOpen Source Mobile Communications
Redmine OsmoHNBGW - Bug #6380 (New): VTY transcript tests are broken [again]https://projects.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> OCTOI - Osmocom Community TDM over IP - Bug #6274 (New): yate is eating 260% CPU while doing nothinghttps://projects.osmocom.org/issues/62742023-11-25T14:31:20Zlaforge
<p>Something seems wrong if an idle yate doing nothing consumes about 260% CPU.</p>
<p>Looking at the yate threads, we can see that each <code>Zap Worker</code> consumes 10..12% of CPU while doing nothing:<br /><img src="https://projects.osmocom.org/attachments/download/7154/yate-cpu.png" alt="" /></p>
<p>This is quite weird, especially considering that osmo-e1d with 23 trunkdevs in parallel only uses 20% CPU - while actually processing packets/frames for all of those trunks.</p>
<p>a strace of such a single Zap Worker thread looks like this:<br /><pre>
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
</pre></p>
<p>So basically we're using select to check if data on a single FD has arrived, time-out after 100 microseconds and then call a zero-nanoseconds sleep and start all-over again.</p>
<p>Looking at the source code, this looks like extremely poor programming style:<br /><pre><code class="c++ syntaxhl"><span class="c1">// Process incoming data</span>
<span class="kt">bool</span> <span class="n">ZapInterface</span><span class="o">::</span><span class="n">process</span><span class="p">()</span>
<span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">m_device</span><span class="p">.</span><span class="n">select</span><span class="p">(</span><span class="mi">100</span><span class="p">))</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">m_device</span><span class="p">.</span><span class="n">canRead</span><span class="p">())</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">m_device</span><span class="p">.</span><span class="n">event</span><span class="p">())</span>
<span class="n">checkEvents</span><span class="p">();</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="p">}</span>
<span class="kt">int</span> <span class="n">r</span> <span class="o">=</span> <span class="n">m_device</span><span class="p">.</span><span class="n">recv</span><span class="p">(</span><span class="n">m_buffer</span><span class="p">,</span><span class="n">m_bufsize</span> <span class="o">+</span> <span class="n">ZAP_CRC_LEN</span><span class="p">);</span>
<span class="k">if</span> <span class="p">(</span><span class="n">r</span> <span class="o">==</span> <span class="o">-</span><span class="mi">1</span><span class="p">)</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">m_device</span><span class="p">.</span><span class="n">event</span><span class="p">())</span>
<span class="n">checkEvents</span><span class="p">();</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="p">}</span>
<span class="k">if</span> <span class="p">(</span><span class="n">r</span> <span class="o">&</span><span class="n">lt</span><span class="p">;</span> <span class="n">ZAP_CRC_LEN</span> <span class="o">+</span> <span class="mi">1</span><span class="p">)</span> <span class="p">{</span>
<span class="n">Debug</span><span class="p">(</span><span class="k">this</span><span class="p">,</span><span class="n">DebugMild</span><span class="p">,</span><span class="s">"Short read %u bytes (with CRC) [%p]"</span><span class="p">,</span><span class="n">r</span><span class="p">,</span><span class="k">this</span><span class="p">);</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="p">}</span>
<span class="n">s_ifaceNotifyMutex</span><span class="p">.</span><span class="n">lock</span><span class="p">();</span>
<span class="n">m_notify</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
<span class="n">s_ifaceNotifyMutex</span><span class="p">.</span><span class="n">unlock</span><span class="p">();</span>
<span class="n">DataBlock</span> <span class="n">packet</span><span class="p">(</span><span class="n">m_buffer</span><span class="p">,</span><span class="n">r</span> <span class="o">-</span> <span class="n">ZAP_CRC_LEN</span><span class="p">,</span><span class="nb">false</span><span class="p">);</span>
<span class="cp">#ifdef XDEBUG
</span> <span class="n">String</span> <span class="n">hex</span><span class="p">;</span>
<span class="n">hex</span><span class="p">.</span><span class="n">hexify</span><span class="p">(</span><span class="n">packet</span><span class="p">.</span><span class="n">data</span><span class="p">(),</span><span class="n">packet</span><span class="p">.</span><span class="n">length</span><span class="p">(),</span><span class="sc">' '</span><span class="p">);</span>
<span class="n">Debug</span><span class="p">(</span><span class="k">this</span><span class="p">,</span><span class="n">DebugAll</span><span class="p">,</span><span class="s">"Received data: %s [%p]"</span><span class="p">,</span><span class="n">hex</span><span class="p">.</span><span class="n">safe</span><span class="p">(),</span><span class="k">this</span><span class="p">);</span>
<span class="cp">#endif
</span> <span class="n">receivedPacket</span><span class="p">(</span><span class="n">packet</span><span class="p">);</span>
<span class="n">packet</span><span class="p">.</span><span class="n">clear</span><span class="p">(</span><span class="nb">false</span><span class="p">);</span>
<span class="k">return</span> <span class="nb">true</span><span class="p">;</span>
<span class="p">}</span>
<span class="kt">void</span> <span class="n">ZapWorkerThread</span><span class="o">::</span><span class="n">run</span><span class="p">()</span>
<span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">m_client</span><span class="p">)</span>
<span class="k">return</span><span class="p">;</span>
<span class="n">DDebug</span><span class="p">(</span><span class="o">&</span><span class="n">plugin</span><span class="p">,</span><span class="n">DebugAll</span><span class="p">,</span><span class="s">"%s is running for client (%p): %s"</span><span class="p">,</span>
<span class="n">s_threadName</span><span class="p">,</span><span class="n">m_client</span><span class="p">,</span><span class="n">m_address</span><span class="p">.</span><span class="n">c_str</span><span class="p">());</span>
<span class="k">while</span> <span class="p">(</span><span class="nb">true</span><span class="p">)</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">m_client</span><span class="o">-&</span><span class="n">gt</span><span class="p">;</span><span class="n">process</span><span class="p">())</span>
<span class="n">Thread</span><span class="o">::</span><span class="n">check</span><span class="p">(</span><span class="nb">true</span><span class="p">);</span>
<span class="k">else</span>
<span class="n">Thread</span><span class="o">::</span><span class="n">yield</span><span class="p">(</span><span class="nb">true</span><span class="p">);</span>
<span class="p">}</span>
<span class="p">}</span>
</pre></p>
<p>So basically the thread is continuously calling Thread:yield rather than waiting on some actual I/O to happen.</p></code></pre> OsmoBSC - Bug #6159 (New): use paging queue for PAGING messages that come from the BSC co-located...https://projects.osmocom.org/issues/61592023-08-30T12:38:17Zdexter
<p>When a BSC co-located PCU sends a PAGING message to the BSC via PCUIF, then this message is forwarded immediately via RSL as RSL PAGING COMMAND. This illegally circumvents the paging queue of OsmoBSC. The PAGING messages from the PCU should take the route through the paging queue like any other paging does.</p> OsmoSGSN - Bug #5880 (In Progress): User Manual sections 11.1.1-2 document non-existing (removed?...https://projects.osmocom.org/issues/58802023-01-27T12:08:58Zfixeria
<p>This problem was reported by a user in the IRC:</p>
<pre>
18:55 < PJHarvy> i can't understand: in osmo sgsn manual we use:
18:55 < PJHarvy> encapsulation udp local-ip 127.0.0.1 1
18:55 < PJHarvy> encapsulation udp local-port 23000. but my version doesn't support this commands
</pre>
<p>The current <a class="external" href="https://downloads.osmocom.org/docs/latest/osmosgsn-usermanual.pdf">https://downloads.osmocom.org/docs/latest/osmosgsn-usermanual.pdf</a> indeed lists these commands, which do not exist.</p> osmo-remsim - Bug #5527 (Stalled): warn on duplicate client (id) connectionshttps://projects.osmocom.org/issues/55272022-04-12T17:37:27Zlaforge
<p>Every client must have its own unique tuple of (client_id/slot_nr).</p>
<p>If a remsim-server receives a duplicate connection, it should pring a clear warning message to the log.</p>
<p>This might not always be a bug, as in csae of network outages / restarts a new connection might arrive before the old one is closed.</p>
<p>The same should apply to remsim-bankd.</p> OsmoHNBGW - Bug #5304 (New): Verizon CDMA femtocellhttps://projects.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://projects.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> libosmocore - Bug #5029 (New): vty: optional cases with multiple arguments is undefined behaviourhttps://projects.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://projects.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://projects.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://projects.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> libosmocore - Bug #4797 (Feedback): vty: the output of 'show ns' command is confusinghttps://projects.osmocom.org/issues/47972020-10-09T23:38:34Zfixeria
<p>This looks cryptic, at least to me:</p>
<pre>
OsmoPCU# show ns
UDP bind: 0.0.0.0:22000 dcsp: 0
1 NS-VC:
udp)[0.0.0.0]:22000<1234>[127.0.0.1]:23000
NSEI 1234
:0 <> 127.0.0.1:23000Remote: udp)[0.0.0.0]:22000<1234>[127.0.0.1]:23000 UDP
</pre>
<p>Let's print something more readable.</p> OsmoMSC - Bug #4784 (New): wrong cause code (resources unavailable) in MO-to-MT call without resp...https://projects.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> OsmocomBB - Bug #4658 (Stalled): Wrong burst order in a multi-trx setuphttps://projects.osmocom.org/issues/46582020-07-08T11:45:30Zfixeria
<p>While running the existing test cases from ttcn3-bts-test on hopping channels (see <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: baseband frequency hopping support for osmo-bts-trx (Resolved)" href="https://projects.osmocom.org/issues/4546">#4546</a>), I noticed that sometimes trxcon starts to consume a lot of CPU power. As it turned out, this happens because the burst loss detection logic in trxcon somehow detects that the whole TDMA hyper-frame is lost, so it tries to substitute ~2715647 allegedly lost TDMA frames with a dummy burst. Of course it's a bug, because we're not supposed to compensate more than one TDMA multi-frame period. So the problem was a missing 'return' statement:</p>
<p><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/19183">https://gerrit.osmocom.org/c/osmocom-bb/+/19183</a> trxcon/scheduler: subst_frame_loss(): print current TDMA fn<br /><a class="external" href="https://gerrit.osmocom.org/c/osmocom-bb/+/19184">https://gerrit.osmocom.org/c/osmocom-bb/+/19184</a> trxcon/scheduler: fix subst_frame_loss(): do not compensate too much</p>
<p>However, I was interested to know what exactly tricks the burst detection logic to think that so many frames are lost.</p>
<pre><code class="c syntaxhl"><span class="cm">/*! Return the difference of two specified TDMA frame numbers (subtraction) */</span>
<span class="cp">#define GSM_TDMA_FN_SUB(a, b) \
((a + GSM_TDMA_HYPERFRAME - b) % GSM_TDMA_HYPERFRAME)
</span>
<span class="cm">/* How many frames elapsed since the last one? */</span>
<span class="n">elapsed</span> <span class="o">=</span> <span class="n">GSM_TDMA_FN_SUB</span><span class="p">(</span><span class="n">fn</span><span class="p">,</span> <span class="n">lchan</span><span class="o">-></span><span class="n">tdma</span><span class="p">.</span><span class="n">last_proc</span><span class="p">);</span>
<span class="k">if</span> <span class="p">(</span><span class="n">elapsed</span> <span class="o">></span> <span class="n">mf</span><span class="o">-></span><span class="n">period</span><span class="p">)</span> <span class="p">{</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DSCHD</span><span class="p">,</span> <span class="n">LOGL_NOTICE</span><span class="p">,</span> <span class="s">"Too many (>%u) contiguous TDMA frames elapsed (%u) "</span>
<span class="s">"since the last processed fn=%u (current %u)</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span>
<span class="n">mf</span><span class="o">-></span><span class="n">period</span><span class="p">,</span> <span class="n">elapsed</span><span class="p">,</span> <span class="n">lchan</span><span class="o">-></span><span class="n">tdma</span><span class="p">.</span><span class="n">last_proc</span><span class="p">,</span> <span class="n">fn</span><span class="p">);</span>
<span class="k">return</span> <span class="o">-</span><span class="n">EIO</span><span class="p">;</span>
<span class="p">}</span> <span class="k">else</span> <span class="nf">if</span> <span class="p">(</span><span class="n">elapsed</span> <span class="o">==</span> <span class="mi">0</span><span class="p">)</span> <span class="p">{</span>
<span class="n">LOGP</span><span class="p">(</span><span class="n">DSCHD</span><span class="p">,</span> <span class="n">LOGL_ERROR</span><span class="p">,</span> <span class="s">"No TDMA frames elapsed since the last processed "</span>
<span class="s">"fn=%u, must be a bug?</span><span class="se">\n</span><span class="s">"</span><span class="p">,</span> <span class="n">lchan</span><span class="o">-></span><span class="n">tdma</span><span class="p">.</span><span class="n">last_proc</span><span class="p">);</span>
<span class="k">return</span> <span class="o">-</span><span class="n">EIO</span><span class="p">;</span>
<span class="p">}</span>
</code></pre>
<p>And slightly more informative logging message gives us a hint:</p>
<pre>
sched_trx.c:640 Too many (>104) contiguous TDMA frames elapsed (2715647) since the last processed fn=633 (current fn=632)
</pre>
<p>so, a burst with TDMA fn=632 is for some reason received <strong>late</strong>, since we already received a burst with TDMA fn=633.</p>
<p>This is definitely unexpected, and of course subtraction would result in a huge number: ((632 + 2715648) - 633) % 2715648 == 2715647.</p> OsmoMSC - Bug #4451 (New): vty 'show stats level': different stats levels yield identical resultshttps://projects.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> OsmoHLR - Bug #4303 (New): various minor issues about evaluation of rc = db_subscr_get_by_*()https://projects.osmocom.org/issues/43032019-12-03T22:56:57Zneelsnhofmeyr@sysmocom.de
<p>vty function 'subscriber imsi IDENT create':</p>
<p>We create the subscriber, and then db_subscr_get_by_imsi(), which might produce an error.<br />It's unlikely since creationg rc is evaluated just before that, but still.<br />If the rc returns an error, we should echo that to the VTY user.</p>
<pre>
rc = db_subscr_get_by_imsi(g_hlr->dbc, imsi, &subscr);
vty_out(vty, "%% Created subscriber %s%s", imsi, VTY_NEWLINE);
subscr_dump_full_vty(vty, &subscr);
return CMD_SUCCESS;
}
</pre> SIMtrace 2 - Bug #4118 (New): VCC_PHONE strong pull on SIMtrace boardhttps://projects.osmocom.org/issues/41182019-07-18T11:54:10Ztsaitgaist
<p>A complex behavior I identified while testing card emulation:<br />- although the phone does not power the card (the SIMtrace board, v1.4) through VCC_PHONE, VCC_PHONE was at 3.2V (after power up)<br />- VCC_PHONE should be pulled down by R19 (100k resistor)<br />- VCC_PHONE is also connected to the FLAGB output of the FPF2109. but this output is only an open-drain (can't drive high), and connected through a 100k resistor R22 (driving high could not be strong enough to set VCC_PHONE to 3.2V)<br />- when VCC_PHONE is briefly shorted to ground (pulling low with less than 1kR), VCC_PHONE then goes and stays at 0.6V</p>
<p>the issue comes from the FPF2109.<br />VCC_PHONE is connected to VIN, which should only be an input. VCC_SIM is connected to VOUT, which should only be an output.<br />VCC_SIM is also the output of the AP7332 voltage regulator.<br />the output from AP7332 goes in FPF2109 as VCC_SIM, through the FPF2109 internal MOSFET body diode (presumably), back out to VCC_PHONE.<br />the FPF2109 has an internal reverse blocking mechanism. this is probably kicking in when VIN is shorted to ground. 0.6V still pass through.</p>
<p>this is an issue because holding VCC_PHONE high prevents the firmware to properly detect activation (power up) and cold reset of the card.<br />some card readers pull/drive VCC low (omnikey 6321), but I'm not sure all modems do.</p>
<p>TODOs:<br />- R22 is not needed and can be removed (the FLAGB output is not used)<br />- the R19 pull down resistor is also not needed since R20+R21 (resistor divider) already form a 20k pull down resistor<br />- ensure the on-board regulator for VCC_SIM is switched off<br />- switching the regulator off would prevent using SIMtrace as independent card reader while card emulation is used (this is not an issue for MitM since the phone powers the card when needed)<br />- better find out/test how the reverse current protection works</p> osmo-sip-connector - Bug #3724 (New): Wrong media format used in SIP INVITE causes one-way audiohttps://projects.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://projects.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> OsmoSGSN - Bug #3224 (New): verify ciphering after UMTS AKAhttps://projects.osmocom.org/issues/32242018-04-30T23:07:18Zneelsnhofmeyr@sysmocom.de
<p>Depending on whether UMTS or GSM AKA was established, ck or kc must be used as ciphering key.<br />In osmo-sgsn, I cannot find any bit of code that would use the UMTS ck. All I can find is:<br />osmo-sgsn/src/gprs/gprs_llc.c:<br /><pre>
if (llme->cksn != mm->auth_triplet.key_seq &&
mm->auth_triplet.key_seq != GSM_KEY_SEQ_INVAL) {
memcpy(llme->kc, mm->auth_triplet.vec.kc,
gprs_cipher_key_length(mm->ciph_algo));
</pre></p>
<p>Verify in practical tests that ciphering works with UMTS AKA.<br />Also verify that when the MS responds with GSM AKA to a UMTS AKA challenge, the GSM AKA key is used.<br />(The same issue has been solved in the MSC not too long ago.)</p> SDR (Software Defined Radio) - Bug #3126 (New): Windows 10 Pro 1709: crash of rtl_test.exehttps://projects.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://projects.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://projects.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> linmodem - Bug #2797 (New): X11 support is 16bit plane onlyhttps://projects.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> osmo-qcdiag - Bug #1906 (Feedback): wireshark: fix decoding of (E)GPRS RLC/MAC frameshttps://projects.osmocom.org/issues/19062017-01-11T12:20:09Zlaforge
<p>The RLC/MAC frames contained in DIAG are currently not correctly displayed, I assume it is some kind of bit alignment/padding issue.</p>
<p>dissect_qcdiag_log_gmac() in <a class="external" href="http://git.osmocom.org/wireshark/tree/epan/dissectors/packet-qcdiag_log.c?h=laforge/qcdiag">http://git.osmocom.org/wireshark/tree/epan/dissectors/packet-qcdiag_log.c?h=laforge/qcdiag</a> maybe needs the same kind of bit-fucking like implemented in <a class="external" href="http://git.osmocom.org/wireshark/commit/?h=laforge/qcdiag&id=270c4e66fee78aa1a79f6b3ff4dc445a2521e6dd">http://git.osmocom.org/wireshark/commit/?h=laforge/qcdiag&id=270c4e66fee78aa1a79f6b3ff4dc445a2521e6dd</a> and the related code should thus be added to the rlc/mac dissector (registering a new dissector for differently aligned frames?) rather than to packet-gsmtap.c, packet-qcdiag_log.c and packet-gsm_abis_pgsl.c</p> OsmoBTS - Bug #1898 (Feedback): Wrong handover detection with l1sap on wrong ss=0/ts=0https://projects.osmocom.org/issues/18982016-12-27T12:24:04Zzecke
<p>So handover being detected on TS=0, SS=0... which is unlikely to be the right channel.. Need input validation and checking if the channel is allocated? But verify it.. not sure why it detects it like that.. Happens frequently at the 33C3</p>
<pre>
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<0006> l1_if.c:700 SACCH for pchan 9?
<000a> handover.c:111 (bts=0,trx=0,ts=0,ss=0) RACH on dedicated channel received with TA=0
<0007> l1sap.c:1205 modifying channel chan_nr=0x20 trx=0
<000a> oml.c:1852 (bts=0,trx=0,ts=0,ss=0) modifying channel for handover
<0006> oml.c:1077 (bts=0,trx=0,ts=0,ss=0) MPH-ACTIVATE.req (hL2=0x000000bb, SDCCH TxDL)
<0007> l1_if.c:166 Tx L1 prim MPH-ACTIVATE.req
<0000> rsl.c:578 Sending HANDOver DETect
Program received signal SIGSEGV, Segmentation fault.
rslms_rx_rll_udata_req (msg=msg@entry=0xc0748, dl=dl@entry=0xb6fc14b0) at lapdm.c:855
855 lapdm.c: No such file or directory.
(gdb) bt
#0 rslms_rx_rll_udata_req (msg=msg@entry=0xc0748, dl=dl@entry=0xb6fc14b0) at lapdm.c:855
#1 0x4fcacb00 in rslms_rx_rll (lc=0xb6fc133c, msg=0xc0748) at lapdm.c:1154
#2 lapdm_rslms_recvmsg (msg=msg@entry=0xc0748, lc=lc@entry=0xb6fc1294) at lapdm.c:1223
#3 0x000279d4 in ho_tx_phys_info (lchan=lchan@entry=0xb6fc11ec) at handover.c:61
#4 0x00027cbc in handover_rach (lchan=0xb6fc11ec, ra=<optimized out>, acc_delay=acc_delay@entry=0 '\000') at handover.c:131
#5 0x0002a680 in l1sap_handover_rach (l1sap=<optimized out>, rach_ind=<optimized out>, rach_ind=<optimized out>,
rach_ind=<optimized out>, trx=0xb6fbd038) at l1sap.c:659
#6 l1sap_ph_rach_ind (rach_ind=0xbf4fc, l1sap=0xbf4ec, trx=0xb6fbd038) at l1sap.c:974
#7 l1sap_up (trx=trx@entry=0xb6fbd038, l1sap=l1sap@entry=0xbf4ec) at l1sap.c:1022
#8 0x0000d690 in handle_ph_ra_ind (l1p_msg=0xbf428, ra_ind=<optimized out>, fl1=0xbf428) at l1_if.c:1064
#9 l1if_handle_ind (fl1=<optimized out>, msg=msg@entry=0xbf428) at l1_if.c:1090
#10 0x0000dfc8 in l1if_handle_l1prim (wq=<optimized out>, fl1h=<optimized out>, msg=msg@entry=0xbf428) at l1_if.c:1144
#11 0x00017e48 in read_dispatch_one (queue=<optimized out>, msg=0xbf428, fl1h=<optimized out>) at l1_transp_hw.c:190
#12 l1if_fd_cb (ofd=0xb86d0, what=<optimized out>) at l1_transp_hw.c:224
#13 0x4fcd6330 in osmo_fd_disp_fds (_eset=0xbefffb48, _wset=0xbefffac8, _rset=0xbefffa48) at select.c:149
#14 osmo_select_main (polling=polling@entry=0) at select.c:189
#15 0x0002bf84 in bts_main (argc=<optimized out>, argv=<optimized out>) at main.c:349
#16 0x4fa61684 in __libc_start_main (main=0xbefffd84, argc=1337463808, argv=0x4fa61684 <__libc_start_main+276>,
init=<optimized out>, fini=0x2ec70 <__libc_csu_fini>, rtld_fini=0x4fa27dc4 <_dl_fini>, stack_end=0xbefffd84) at libc-start.c:269
#17 0x0000b8a4 in _start () at ../ports/sysdeps/arm/start.S:124
(gdb) frame 5
#5 0x0002a680 in l1sap_handover_rach (l1sap=<optimized out>, rach_ind=<optimized out>, rach_ind=<optimized out>,
rach_ind=<optimized out>, trx=0xb6fbd038) at l1sap.c:659
659 l1sap.c: No such file or directory.
#17 0x0000b8a4 in _start () at ../ports/sysdeps/arm/start.S:124
(gdb) frame 5
#5 0x0002a680 in l1sap_handover_rach (l1sap=<optimized out>, rach_ind=<optimized out>, rach_ind=<optimized out>,
rach_ind=<optimized out>, trx=0xb6fbd038) at l1sap.c:659
659 l1sap.c: No such file or directory.
(gdb) p lc
No symbol "lc" in current context.
(gdb) p lc^CQuit
(gdb) p *lchan
value has been optimized out
(gdb) p *rach_ind
value has been optimized out
(gdb) p rach_ind->chan_nr
value has been optimized out
(gdb) frame 6
#6 l1sap_ph_rach_ind (rach_ind=0xbf4fc, l1sap=0xbf4ec, trx=0xb6fbd038) at l1sap.c:974
974 in l1sap.c
(gdb) p *rach_ind
$1 = {chan_nr = 64 '@', ra = 0, acc_delay = 0 '\000', fn = 2107, is_11bit = 0 '\000', burst_type = GSM_L1_BURST_TYPE_ACCESS_0}
(gdb) frame 3
#3 0x000279d4 in ho_tx_phys_info (lchan=lchan@entry=0xb6fc11ec) at handover.c:61
61 handover.c: No such file or directory.
(gdb) p *lchan
$2 = {ts = 0xb6fc08f8, nr = 0 '\000', type = GSM_LCHAN_SDCCH, rsl_cmode = 0, tch_mode = GSM48_CMODE_SIGN, csd_mode = LCHAN_CSD_M_NT,
state = LCHAN_S_NONE, broken_reason = 0x0, bs_power = 0 '\000', ms_power = 0 '\000', encr = {alg_id = 0 '\000',
key_len = 0 '\000', key = '\000' <repeats 15 times>}, mr_ms_lv = "\000\000\000\000\000\000",
mr_bts_lv = "\000\000\000\000\000\000", sapis = "\000\000\000\000\000\000\000", sacch_deact = 0, abis_ip = {bound_ip = 0,
connect_ip = 0, bound_port = 0, connect_port = 0, conn_id = 0, rtp_payload = 0 '\000', rtp_payload2 = 0 '\000',
speech_mode = 0 '\000', rtp_socket = 0x0}, rqd_ta = 0 '\000', name = 0x6b778 "(bts=0,trx=0,ts=0,ss=0)", sapi_cmds = {
next = 0xc0150, prev = 0xc0240}, sapis_dl = '\000' <repeats 22 times>, sapis_ul = '\000' <repeats 22 times>, lapdm_ch = {list = {
next = 0x0, prev = 0x0}, name = 0x0, lapdm_acch = {datalink = {{dl = {send_dlsap = 0x0, send_ph_data_req = 0x0,
update_pending_frames = 0x0, cr = {loc2rem = {cmd = 0 '\000', resp = 0 '\000'}, rem2loc = {cmd = 0 '\000',
resp = 0 '\000'}}, mode = LAPD_MODE_USER, use_sabme = 0, reestablish = 0, n200 = 0, n200_est_rel = 0, lctx = {
dl = 0x0, n201 = 0, cr = 0 '\000', sapi = 0 '\000', tei = 0 '\000', lpd = 0 '\000', format = 0 '\000', p_f = 0 '\000',
n_send = 0 '\000', n_recv = 0 '\000', s_u = 0 '\000', length = 0, more = 0 '\000'}, maxf = 0, k = 0 '\000',
v_range = 0 '\000', v_send = 0 '\000', v_ack = 0 '\000', v_recv = 0 '\000', state = 0, seq_err_cond = 0,
own_busy = 0 '\000', peer_busy = 0 '\000', t200_sec = 0, t200_usec = 0, t203_sec = 0, t203_usec = 0, t200 = {node = {
rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0,
tv_usec = 0}, active = 0, cb = 0x0, data = 0x0}, t203 = {node = {rb_parent_color = 0, rb_right = 0x0,
rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0,
data = 0x0}, retrans_ctr = 0 '\000', tx_queue = {next = 0x0, prev = 0x0}, send_queue = {next = 0x0, prev = 0x0},
send_buffer = 0x0, send_out = 0, tx_hist = 0x0, range_hist = 0 '\000', rcv_buffer = 0x0, cont_res = 0x0}, mctx = {
dl = 0x0, lapdm_fmt = 0, chan_nr = 0 '\000', link_id = 0 '\000', ta_ind = 0 '\000', tx_power_ind = 0 '\000'},
entity = 0x0}, {dl = {send_dlsap = 0x0, send_ph_data_req = 0x0, update_pending_frames = 0x0, cr = {loc2rem = {
cmd = 0 '\000', resp = 0 '\000'}, rem2loc = {cmd = 0 '\000', resp = 0 '\000'}}, mode = LAPD_MODE_USER,
use_sabme = 0, reestablish = 0, n200 = 0, n200_est_rel = 0, lctx = {dl = 0x0, n201 = 0, cr = 0 '\000', sapi = 0 '\000',
tei = 0 '\000', lpd = 0 '\000', format = 0 '\000', p_f = 0 '\000', n_send = 0 '\000', n_recv = 0 '\000',
s_u = 0 '\000', length = 0, more = 0 '\000'}, maxf = 0, k = 0 '\000', v_range = 0 '\000', v_send = 0 '\000',
v_ack = 0 '\000', v_recv = 0 '\000', state = 0, seq_err_cond = 0, own_busy = 0 '\000', peer_busy = 0 '\000',
t200_sec = 0, t200_usec = 0, t203_sec = 0, t203_usec = 0, t200 = {node = {rb_parent_color = 0, rb_right = 0x0,
rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0,
data = 0x0}, t203 = {node = {rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0},
timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0, data = 0x0}, retrans_ctr = 0 '\000', tx_queue = {
next = 0x0, prev = 0x0}, send_queue = {next = 0x0, prev = 0x0}, send_buffer = 0x0, send_out = 0, tx_hist = 0x0,
range_hist = 0 '\000', rcv_buffer = 0x0, cont_res = 0x0}, mctx = {dl = 0x0, lapdm_fmt = 0, chan_nr = 0 '\000',
link_id = 0 '\000', ta_ind = 0 '\000', tx_power_ind = 0 '\000'}, entity = 0x0}}, last_tx_dequeue = 0, tx_pending = 0,
mode = LAPDM_MODE_MS, flags = 0, l1_ctx = 0x0, l3_ctx = 0x0, l1_prim_cb = 0x0, l3_cb = 0x0, lapdm_ch = 0x0, ta = 0 '\000',
tx_power = 0 '\000'}, lapdm_dcch = {datalink = {{dl = {send_dlsap = 0x0, send_ph_data_req = 0x0, update_pending_frames = 0x0,
cr = {loc2rem = {cmd = 0 '\000', resp = 0 '\000'}, rem2loc = {cmd = 0 '\000', resp = 0 '\000'}}, mode = LAPD_MODE_USER,
use_sabme = 0, reestablish = 0, n200 = 0, n200_est_rel = 0, lctx = {dl = 0x0, n201 = 0, cr = 0 '\000', sapi = 0 '\000',
tei = 0 '\000', lpd = 0 '\000', format = 0 '\000', p_f = 0 '\000', n_send = 0 '\000', n_recv = 0 '\000',
s_u = 0 '\000', length = 0, more = 0 '\000'}, maxf = 0, k = 0 '\000', v_range = 0 '\000', v_send = 0 '\000',
v_ack = 0 '\000', v_recv = 0 '\000', state = 0, seq_err_cond = 0, own_busy = 0 '\000', peer_busy = 0 '\000',
t200_sec = 0, t200_usec = 0, t203_sec = 0, t203_usec = 0, t200 = {node = {rb_parent_color = 0, rb_right = 0x0,
rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0,
data = 0x0}, t203 = {node = {rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0},
timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0, data = 0x0}, retrans_ctr = 0 '\000', tx_queue = {
next = 0x0, prev = 0x0}, send_queue = {next = 0x0, prev = 0x0}, send_buffer = 0x0, send_out = 0, tx_hist = 0x0,
range_hist = 0 '\000', rcv_buffer = 0x0, cont_res = 0x0}, mctx = {dl = 0x0, lapdm_fmt = 0, chan_nr = 0 '\000',
link_id = 0 '\000', ta_ind = 0 '\000', tx_power_ind = 0 '\000'}, entity = 0x0}, {dl = {send_dlsap = 0x0,
send_ph_data_req = 0x0, update_pending_frames = 0x0, cr = {loc2rem = {cmd = 0 '\000', resp = 0 '\000'}, rem2loc = {
cmd = 0 '\000', resp = 0 '\000'}}, mode = LAPD_MODE_USER, use_sabme = 0, reestablish = 0, n200 = 0,
n200_est_rel = 0, lctx = {dl = 0x0, n201 = 0, cr = 0 '\000', sapi = 0 '\000', tei = 0 '\000', lpd = 0 '\000',
format = 0 '\000', p_f = 0 '\000', n_send = 0 '\000', n_recv = 0 '\000', s_u = 0 '\000', length = 0, more = 0 '\000'},
maxf = 0, k = 0 '\000', v_range = 0 '\000', v_send = 0 '\000', v_ack = 0 '\000', v_recv = 0 '\000', state = 0,
seq_err_cond = 0, own_busy = 0 '\000', peer_busy = 0 '\000', t200_sec = 0, t200_usec = 0, t203_sec = 0, t203_usec = 0,
t200 = {node = {rb_parent_color = 0, rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {
tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0, data = 0x0}, t203 = {node = {rb_parent_color = 0, rb_right = 0x0,
rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0,
data = 0x0}, retrans_ctr = 0 '\000', tx_queue = {next = 0x0, prev = 0x0}, send_queue = {next = 0x0, prev = 0x0},
send_buffer = 0x0, send_out = 0, tx_hist = 0x0, range_hist = 0 '\000', rcv_buffer = 0x0, cont_res = 0x0}, mctx = {
dl = 0x0, lapdm_fmt = 0, chan_nr = 0 '\000', link_id = 0 '\000', ta_ind = 0 '\000', tx_power_ind = 0 '\000'},
entity = 0x0}}, last_tx_dequeue = 0, tx_pending = 0, mode = LAPDM_MODE_MS, flags = 0, l1_ctx = 0x0, l3_ctx = 0x0,
l1_prim_cb = 0x0, l3_cb = 0x0, lapdm_ch = 0x0, ta = 0 '\000', tx_power = 0 '\000'}}, dl_tch_queue = {next = 0xb6fc16c0,
prev = 0xb6fc16c0}, si = {valid = 0, last = 0, buf = {'\000' <repeats 22 times> <repeats 24 times>}}, meas = {flags = 0 '\000',
res_nr = 0 '\000', bts_tx_pwr = 0 '\000', num_ul_meas = 0 '\000', uplink = {{ber10k = 0, ta_offs_qbits = 0, c_i = 0,
is_sub = 0 '\000', inv_rssi = 0 '\000'} <repeats 104 times>}, l1_info = "\000", ul_res = {full = {rx_lev = 0 '\000',
rx_qual = 0 '\000'}, sub = {rx_lev = 0 '\000', rx_qual = 0 '\000'}}}, tch = {amr_mr = {gsm48_ie = "\000", ms_mode = {{
mode = 0 '\000', threshold = 0 '\000', hysteresis = 0 '\000'}, {mode = 0 '\000', threshold = 0 '\000',
hysteresis = 0 '\000'}, {mode = 0 '\000', threshold = 0 '\000', hysteresis = 0 '\000'}, {mode = 0 '\000',
threshold = 0 '\000', hysteresis = 0 '\000'}}, bts_mode = {{mode = 0 '\000', threshold = 0 '\000', hysteresis = 0 '\000'},
{mode = 0 '\000', threshold = 0 '\000', hysteresis = 0 '\000'}, {mode = 0 '\000', threshold = 0 '\000',
hysteresis = 0 '\000'}, {mode = 0 '\000', threshold = 0 '\000', hysteresis = 0 '\000'}}, num_modes = 0 '\000'}, dtx = {
dl_amr_fsm = 0x0, cache = '\000' <repeats 19 times>, facch = '\000' <repeats 22 times>, len = 0 '\000', fn = 0,
is_update = false, ul_sid = false, dl_active = false}, last_cmr = 0 '\000', last_fn = 0}, ciph_state = 0 '\000',
ciph_ns = 0 '\000', loopback = 0 '\000', ho = {active = 2 '\002', ref = 0 '\000', t3105 = {node = {rb_parent_color = 0,
rb_right = 0x0, rb_left = 0x0}, list = {next = 0x0, prev = 0x0}, timeout = {tv_sec = 0, tv_usec = 0}, active = 0, cb = 0x0,
data = 0x0}, phys_info_count = 1}, s = 0, rel_act_kind = 0, rtp_tx_marker = false, ms_power_ctrl = {current = 0 '\000',
fixed = 0 '\000'}}
(gdb) frame 4
#4 0x00027cbc in handover_rach (lchan=0xb6fc11ec, ra=<optimized out>, acc_delay=acc_delay@entry=0 '\000') at handover.c:131
131 in handover.c
(gdb) p ra
$3 = <optimized out>
(gdb)
$4 = <optimized out>
(gdb) c
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
(gdb)
</pre> OsmoSGSN - Bug #1768 (Stalled): VTY show llc displays State TLLI Unassigned permanentlyhttps://projects.osmocom.org/issues/17682016-07-07T11:48:18Zdexter
<p>Expecting at least some assigned TLLI states in in SAPI list on globally Assigned TLLI state.</p>
<pre>
TLLI e625e4fb (Old TLLI ffffffff) BVCI=2 NSEI=101 Age=0: State TLLI Assigned
SAPI 1 State TLLI Unassigned (1) VUsend=4, VUrecv=5 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=400, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 2 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 3 State TLLI Unassigned (1) VUsend=91, VUrecv=64 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=5, N200=3, N201-U=500, N201-I=1503, mD=1520, mU=1520, kD=16, kU=16
SAPI 5 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=10, N200=3, N201-U=500, N201-I=1503, mD=760, mU=760, kD=8, kU=8
SAPI 7 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 8 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=270, N201-I=0, mD=0, mU=0, kD=0, kU=0
SAPI 9 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=20, N200=3, N201-U=500, N201-I=1503, mD=380, mU=380, kD=4, kU=4
SAPI 11 State TLLI Unassigned (1) VUsend=0, VUrecv=0 Vsent=0 Vack=0 Vrecv=0, RetransCtr=0
T200=40, N200=3, N201-U=500, N201-I=1503, mD=190, mU=190, kD=2, kU=2
</pre>
<p>Already checked if the get_value_string(gprs_llc_state_strs, lle->state) returns the right string. Seems to work, numerical state is always 1 as well.</p> OsmoPCU - Bug #1759 (Stalled): Wrong calculation of DL window size for DL assignmenthttps://projects.osmocom.org/issues/17592016-06-28T10:27:21Zarvind.sirsikar
<p>Hi,</p>
<p>When we create DOWNLINK TBF without existing UPLINK TBF i.e DL assignment on PCH case, The calculation of window size is found to be incorrect.</p>
<p>Description:<br /> 4 time slots is configured for DL and osmo-pcu.cfg is configured as window-size 64 104.</p>
<pre><code>When we try to do IPERF in DL direction, PCU allocates window-size as 160 but configures 4 time slots<br /> as seen by PCU VTY. Below is the result of VTY output.</code></pre>
<pre><code>DL TBFs<br /> TBF: TFI=0 TLLI=0xf73d2ece (valid) DIR=DL IMSI=901555000001280<br /> created=1095 state=0000000a 1st_TS=4 1st_cTS=6 ctrl_TS=6 MS_CLASS=0/1<br /> TS_alloc=4 5 6! 7 CS=MCS-9 WS=160 V(A)=12 V(S)=12 nBSN=138</code></pre>
<pre><code>But we see proper calculation of window-size when DL assignement is done on PACCH. as seen by VTY interface below</code></pre>
<pre><code>DL TBFs<br /> TBF: TFI=0 TLLI=0xf73d2ece (valid) DIR=DL IMSI=901555000001280<br /> created=1095 state=0000000a 1st_TS=4 1st_cTS=6 ctrl_TS=6 MS_CLASS=0/1<br /> TS_alloc=4 5 6! 7 CS=MCS-9 WS=480 V(A)=138 V(S)=139 nBSN=138</code></pre>
<p>Thanks,<br />Aravind Sirsikar</p> SDR (Software Defined Radio) - Bug #1678 (New): Use -undefined dynamic_lookup when using Python a...https://projects.osmocom.org/issues/16782016-03-30T23:25:04Zmot
<a name="Description"></a>
<h2 >Description<a href="#Description" class="wiki-anchor">¶</a></h2>
<p>Building GrOsmoSDR on Mac OS X should use the <code>-undefined dynamic_lookup</code> as value for the Python library instead of the <code>-lpython</code> and/or <code>-framework /path/to/python/framework</code> to ensure Python gets linked dynamically without having all symbols resolved at link time.</p>
<p>More information: <a class="external" href="http://blog.tim-smith.us/2015/09/python-extension-modules-os-x/">http://blog.tim-smith.us/2015/09/python-extension-modules-os-x/</a></p>
<a name="Possible-fix"></a>
<h2 >Possible fix<a href="#Possible-fix" class="wiki-anchor">¶</a></h2>
<p>Set the PYTHON_LIBRARY variable to <code>-undefined dynamic_lookup</code> when running CMake.<br />I've attached a patch which I'm already using for the package in Homebrew. Unfortunately this patch does not work with the latest version of CMake (3.5.0) therefore I'm using it in conjunction with an older version of CMake (3.3.2).</p>
<a name="Additional-information"></a>
<h2 >Additional information<a href="#Additional-information" class="wiki-anchor">¶</a></h2>
<p>Operating system: Mac OS 10.11.4<br />GrOsmoSDR: 0.1.4<br />CMake: 3.3.2</p> Mobile (in)Security - Bug #1483 (New): USSD state is not reset when switching cellshttps://projects.osmocom.org/issues/14832016-02-19T22:51:58Z
<p>USSD support on a phone can be disabled by sending ussdNotify and not sending a releaseComplete. Other USSD commands will not be processed by the phone until the releaseComplete command is send.</p>
<p>The Phone Stack assumes that all USSD operations originate/termate from/at its HLR.</p> OsmoNITB - Bug #21 (New): we don't see CHANnel ReQireD from motorola EZX phones at call setuphttps://projects.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>