Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-02-28T18:34:06ZOpen Source Mobile Communications
Redmine 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> 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> osmo-remsim - Bug #5527 (Stalled): warn on duplicate client (id) connectionshttps://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> Retronetworking - Feature #5463 (In Progress): X.21 hardware interfacehttps://osmocom.org/issues/54632022-02-20T13:34:31Zlaforge
<p>It's surprising how "dead" the X.21 interface seems to be. Apart from some super expensive RS232 to X.21 converters, and the odd FarSync card on ebay, it seems it's very hard to get anything that attaches to a modern computer and implements that interface.</p>
<p>After a bit of research, it seems electrically it's not really more than 6 differential RS-422 style signals. 4 in DCE->DTE direction, and 2 in the other. I'm tempted to do a simple board with a 15pin SUB-D connector and 6 half-duplex RS-422 drivers (so the direction can be switched).</p>
<p>The transceivers of course would be 3.3V supply + logic level, so they can be used with any modern uC/FPGA/...</p>
<p>The board should be configurable for both DTE and DCE role, as well as a passive sniffer, switching all channels to receive-only.</p>
<p>Would anyone be interested in that?</p>
<p>The idea is that such an interface could then be attached to a microcontroller (or fpga) implementing the actual protocol related bits.<br />Given that I'm more of a hardware + software and not a FPGA person, I'd probably try to hook it up to an ARM based uC.</p> OsmoBSC - Feature #5106 (Feedback): Watchdog that would try to un-BORKE BORKen timeslotshttps://osmocom.org/issues/51062021-04-04T20:21:26Zkeith
<p>In <a class="issue tracker-1 status-3 priority-2 priority-default closed behind-schedule" title="Bug: rbs2000 ALL BORKEN Channels (Resolved)" href="https://osmocom.org/issues/5096">#5096</a> that discussed lchans ending up borken on a busy ericsson bts:</p>
<p>"What would probably make sense is some kind of watchdog that would try to un-BORKE BORKen timeslots after a certain time. This can be done by activating a broken sub-slot and releasing it immediately. If the BTS still refuses to activate it, then it's completely BORKen and the second attempt to un-BORKE can be postponed further."</p>
<p>(<a class="external" href="https://osmocom.org/issues/5096#note-12">https://osmocom.org/issues/5096#note-12</a>)</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> libosmocore - Bug #4797 (Feedback): vty: the output of 'show ns' command is confusinghttps://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://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://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://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 - Feature #4200 (In Progress): Work around nano3G-S16 requiring RAB ID to be below 16https://osmocom.org/issues/42002019-09-12T14:07:31Zefistokl
<p>Hardware: ip.access nano3g S16.</p>
<p>Tested against osmo-msc version branches 35c3 and cccamp19 (with Message Class and RAT GSUP IEs stripped out). Reproduced 3 times.</p>
<p>In the trace there are 17 incoming SIP calls. The last 2 failed (around packet 36826 and 37625). In the RAB-AssignmentResponse's for them I see "radioNetwork: failure-in-the-radio-interface-procedure (14)".</p>
<p>If I restart the osmo-msc, I can make another 15 calls.</p>
<p>IPs:<br />10.0.2.247 - nano3g S16<br />10.0.2.244 - RNC:<br /> - 10.0.2.244:5060 osmo-sip-connector<br /> - 10.0.2.244:5064 local PBX (kamailio)<br />172.48.2.1 - Remote PBX (kamailio)<br />172.48.1.5 - GSUP server</p>
<p>Note:<br />Apart from the osmocom software there is Kamailio and rtpengine installed alongside osmo-sip-connector to allow for transcoding. I've set it in a way so that it "sleeps" for 3 seconds before passing SIP INVITE to osmo-sip-connector. (If I don't do this then the UE will not respond to Paging Request (assuming it doesn't have enough time after Iu-Release which happens after USSD))</p> 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> 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> osmo-qcdiag - Bug #1906 (Feedback): wireshark: fix decoding of (E)GPRS RLC/MAC frameshttps://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://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://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://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> 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>