Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-26T11:40:28ZOpen Source Mobile Communications
Redmine OsmoGGSN (former OpenGGSN) - Bug #6420 (New): osmo-ggsn + pre-configured tun device seems to be b...https://osmocom.org/issues/64202024-03-26T11:40:28Zosmith
<p>When using a pre-configured tun device with OsmoGGSN as described in the user manual, in combination with <code>gtpu-mode kernel-gtp</code>, osmo-ggsn fails to configure the kernel GTP device:</p>
<pre>
<0002> ggsn.c:210 APN(internet): Skipping APN start
<000d> gsn.c:465 GTP: gtp_newgsn() started at 10.23.24.2
<000d> gsn.c:386 State information file (/tmp/gsn_restart) not found. Creating new file.
<0002> ggsn.c:854 GGSN(ggsn0): Successfully started
<0002> gtp-kernel.c:79 Initialized GTP kernel mode (genl ID is 34)
<0001> tun.c:213 cannot create GTP tunnel device: File exists
<0002> ggsn.c:215 APN(internet): Failed to configure Kernel GTP device
</pre> OsmoGGSN (former OpenGGSN) - Bug #6419 (New): osmo-ggsn removes tun devices it did not createhttps://osmocom.org/issues/64192024-03-26T11:26:04Zosmith
<p>From the <a href="https://ftp.osmocom.org/docs/osmo-ggsn/master/osmoggsn-usermanual.pdf" class="external">user manual</a>:</p>
<blockquote>
<p>It’s possible to run OsmoGGSN without root privileges if the tun devices are already configured.<br />The interface creation + configuration must then happen before osmo-ggsn starting up.<br />[...]<br />With the tun device pre-configured in one of the ways outlined above, the main changes in your osmo-ggsn.cfg file are:<br />• remove ip ifconfig directive,<br />• make sure that no shutdown is present in the apn section as well as no shutdown ggsn in the ggsn section.</p>
</blockquote>
<p>With this configuration, a tun device created by <code>/etc/network/interfaces</code> will be removed when osmo-ggsn shuts down and <code>ifup -f apn0</code> must be used to recreate it, before starting osmo-ggsn again.</p> E1/T1 Hardware Interface (including icE1usb) - Bug #6415 (New): osmo_panic after truncated packethttps://osmocom.org/issues/64152024-03-22T17:44:25Zpfassberg
<p>I'm running icE1usb connected to a Raspberry CM3 module.</p>
<p>A few times a day osmo-e1d crashes with the following output:<br /><pre>
Fri Mar 22 17:16:59 2024 DLINP octoi_clnt_fsm.c:242 OCTOI_CLIENT(N11MD)[0x55a37878e0]{ACCEPTED}: Rx OCTOI ECHO_RESP (seq=690, rtt=777)
Fri Mar 22 17:17:02 2024 DE1D usb.c:150 (I0:L0) IN EP 82 ISO packet truncated: len-4 = 173
Assert failed size % 32 == 0 mux_demux.c:450
backtrace() returned 19 addresses
/usr/local/lib/libosmocore.so.21(osmo_generate_backtrace+0x18) [0x7f83880f60]
/usr/local/lib/libosmocore.so.21(+0x30aa0) [0x7f838a0aa0]
/usr/local/lib/libosmocore.so.21(osmo_panic+0xd4) [0x7f838a0b78]
osmo-e1d(+0x6e8c) [0x557f4a6e8c]
osmo-e1d(+0x787c) [0x557f4a787c]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(+0xb1b4) [0x7f8381b1b4]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(+0x116ec) [0x7f838216ec]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(+0x1271c) [0x7f8382271c]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(+0xabc8) [0x7f8381abc8]
/lib/aarch64-linux-gnu/libusb-1.0.so.0(libusb_handle_events_timeout_completed+0x218) [0x7f8381c09c]
/usr/local/lib/libosmousb.so.0(+0x1908) [0x7f83901908]
/usr/local/lib/libosmocore.so.21(+0x34398) [0x7f838a4398]
/usr/local/lib/libosmocore.so.21(+0x3450c) [0x7f838a450c]
/usr/local/lib/libosmocore.so.21(osmo_select_main+0x14) [0x7f838a4528]
osmo-e1d(+0x39a4) [0x557f4a39a4]
/lib/aarch64-linux-gnu/libc.so.6(+0x27780) [0x7f83627780]
/lib/aarch64-linux-gnu/libc.so.6(__libc_start_main+0x98) [0x7f83627858]
osmo-e1d(+0x3bf0) [0x557f4a3bf0]
signal 6 received
</pre></p>
<p>As the packet is truncated something has gone wrong in the USB communication or maybe in the firmware, but I think that the process should not do abort but try to continue.</p>
<p>// Peter</p> OsmoBSC - Bug #6378 (New): Ericsson DUG 20 rejects SI2quaterhttps://osmocom.org/issues/63782024-02-28T00:28:49Zkeith
<p>Sending SI2quater to the DUG20 results in</p>
<pre>
ERROR REPORT (cause=Radio Resource not available [ 21 01 80 ])
</pre>
<p>For what it may be worth, the SI and the error are in the attached pcap.</p>
<p>Maybe the BTS software version I have simply does not support it?</p> pySim - Bug #6340 (New): exception when using osmo-smdpp with python 3.9https://osmocom.org/issues/63402024-01-24T09:43:35Zdexter
<p>There is an exception when starting osmo-smdpp with python 3.9. This exception does not occur with python 3.10.</p>
<pre>
owner@osmotest:~/git_master/pysim$ python3.9 ./osmo-smdpp.py
Traceback (most recent call last):
File "/home/owner/git_master/pysim/./osmo-smdpp.py", line 100, in <module>
class SmDppHttpServer:
File "/home/owner/git_master/pysim/./osmo-smdpp.py", line 196, in SmDppHttpServer
def initiateAutentication(self, request: IRequest, content: dict) -> dict:
TypeError: 'staticmethod' object is not callable
</pre>
<p>Commit hash: af87cd544f784e51a41cea303cb57001d9954d9c</p> pySim - Bug #6322 (New): ATR type annotationhttps://osmocom.org/issues/63222024-01-03T21:55:30Zmerlinchlosta
<p>There's a small mixup in the ATR type annotations (<code>Hexstr</code> vs. <code>List[int]</code>) in <code>PcscSimLink</code>:</p>
<pre>
def get_atr(self) -> Hexstr:
return self._con.getATR()
</pre>
<p><code>pyscard</code> actually returns <code>List[int]</code> for an ATR. Depending code seems to convert using <code>i2h</code>.<br /><code>SerialSimLink</code> mimics the behavior (writing <code>self._atr</code> as <code>List[int]</code> in <code>_reset_card</code>).</p> OsmoMSC - Bug #6321 (New): SMS not delivered from corrupted SMS databasehttps://osmocom.org/issues/63212024-01-02T13:07:31Zjolly
<p>When osmo-msc is started with corrupted "sms.db", no SMS is delivered.</p>
<p>Only the earliest SMS is delivered on a location update. All other SMS are not delivered until the next location update triggers the next earliest SMS delivery.</p>
<p>The problem was solved by removing the "sms.db" file and restarting osmo-msc. All queued SMS were delivered instantly. A newly queued SMS was delivered instantly.</p>
<p>To reproduce and debug the problem, I keept the corrupt database file. It is not included with this issue, because it may contain private information. Ask me for it. (/files/auftraege/sysmocom-MSC_SMS_BUG/sms.db_buggy)</p> pySim - Bug #6314 (New): pySim-trace doesn't support ARA-Mhttps://osmocom.org/issues/63142023-12-23T09:31:02Zlaforge
<p>during execution of our pySim-shell test, even with the included pcap we're getting:</p>
<pre>
WARNING pySim.apdu.ts_102_221: SELECT UNKNOWN AID a00000015141434c00
</pre>
<p>the AID is that of the ARA-M applet. We do support ARA-M in pySim-shell. However, we do not appear to use that code from pySim-shell, probably related to the AID auto-detection missing.</p> OCTOI - Osmocom Community TDM over IP - Bug #6274 (New): yate is eating 260% CPU while doing nothinghttps://osmocom.org/issues/62742023-11-25T14:31:20Zlaforge
<p>Something seems wrong if an idle yate doing nothing consumes about 260% CPU.</p>
<p>Looking at the yate threads, we can see that each <code>Zap Worker</code> consumes 10..12% of CPU while doing nothing:<br /><img src="https://osmocom.org/attachments/download/7154/yate-cpu.png" alt="" /></p>
<p>This is quite weird, especially considering that osmo-e1d with 23 trunkdevs in parallel only uses 20% CPU - while actually processing packets/frames for all of those trunks.</p>
<p>a strace of such a single Zap Worker thread looks like this:<br /><pre>
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
select(11, [10], NULL, [10], {tv_sec=0, tv_usec=100}) = 0 (Timeout)
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=0}, NULL) = 0
</pre></p>
<p>So basically we're using select to check if data on a single FD has arrived, time-out after 100 microseconds and then call a zero-nanoseconds sleep and start all-over again.</p>
<p>Looking at the source code, this looks like extremely poor programming style:<br /><pre><code class="c++ syntaxhl"><span class="c1">// Process incoming data</span>
<span class="kt">bool</span> <span class="n">ZapInterface</span><span class="o">::</span><span class="n">process</span><span class="p">()</span>
<span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">m_device</span><span class="p">.</span><span class="n">select</span><span class="p">(</span><span class="mi">100</span><span class="p">))</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">m_device</span><span class="p">.</span><span class="n">canRead</span><span class="p">())</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">m_device</span><span class="p">.</span><span class="n">event</span><span class="p">())</span>
<span class="n">checkEvents</span><span class="p">();</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="p">}</span>
<span class="kt">int</span> <span class="n">r</span> <span class="o">=</span> <span class="n">m_device</span><span class="p">.</span><span class="n">recv</span><span class="p">(</span><span class="n">m_buffer</span><span class="p">,</span><span class="n">m_bufsize</span> <span class="o">+</span> <span class="n">ZAP_CRC_LEN</span><span class="p">);</span>
<span class="k">if</span> <span class="p">(</span><span class="n">r</span> <span class="o">==</span> <span class="o">-</span><span class="mi">1</span><span class="p">)</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">m_device</span><span class="p">.</span><span class="n">event</span><span class="p">())</span>
<span class="n">checkEvents</span><span class="p">();</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="p">}</span>
<span class="k">if</span> <span class="p">(</span><span class="n">r</span> <span class="o">&</span><span class="n">lt</span><span class="p">;</span> <span class="n">ZAP_CRC_LEN</span> <span class="o">+</span> <span class="mi">1</span><span class="p">)</span> <span class="p">{</span>
<span class="n">Debug</span><span class="p">(</span><span class="k">this</span><span class="p">,</span><span class="n">DebugMild</span><span class="p">,</span><span class="s">"Short read %u bytes (with CRC) [%p]"</span><span class="p">,</span><span class="n">r</span><span class="p">,</span><span class="k">this</span><span class="p">);</span>
<span class="k">return</span> <span class="nb">false</span><span class="p">;</span>
<span class="p">}</span>
<span class="n">s_ifaceNotifyMutex</span><span class="p">.</span><span class="n">lock</span><span class="p">();</span>
<span class="n">m_notify</span> <span class="o">=</span> <span class="mi">0</span><span class="p">;</span>
<span class="n">s_ifaceNotifyMutex</span><span class="p">.</span><span class="n">unlock</span><span class="p">();</span>
<span class="n">DataBlock</span> <span class="n">packet</span><span class="p">(</span><span class="n">m_buffer</span><span class="p">,</span><span class="n">r</span> <span class="o">-</span> <span class="n">ZAP_CRC_LEN</span><span class="p">,</span><span class="nb">false</span><span class="p">);</span>
<span class="cp">#ifdef XDEBUG
</span> <span class="n">String</span> <span class="n">hex</span><span class="p">;</span>
<span class="n">hex</span><span class="p">.</span><span class="n">hexify</span><span class="p">(</span><span class="n">packet</span><span class="p">.</span><span class="n">data</span><span class="p">(),</span><span class="n">packet</span><span class="p">.</span><span class="n">length</span><span class="p">(),</span><span class="sc">' '</span><span class="p">);</span>
<span class="n">Debug</span><span class="p">(</span><span class="k">this</span><span class="p">,</span><span class="n">DebugAll</span><span class="p">,</span><span class="s">"Received data: %s [%p]"</span><span class="p">,</span><span class="n">hex</span><span class="p">.</span><span class="n">safe</span><span class="p">(),</span><span class="k">this</span><span class="p">);</span>
<span class="cp">#endif
</span> <span class="n">receivedPacket</span><span class="p">(</span><span class="n">packet</span><span class="p">);</span>
<span class="n">packet</span><span class="p">.</span><span class="n">clear</span><span class="p">(</span><span class="nb">false</span><span class="p">);</span>
<span class="k">return</span> <span class="nb">true</span><span class="p">;</span>
<span class="p">}</span>
<span class="kt">void</span> <span class="n">ZapWorkerThread</span><span class="o">::</span><span class="n">run</span><span class="p">()</span>
<span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="o">!</span><span class="n">m_client</span><span class="p">)</span>
<span class="k">return</span><span class="p">;</span>
<span class="n">DDebug</span><span class="p">(</span><span class="o">&</span><span class="n">plugin</span><span class="p">,</span><span class="n">DebugAll</span><span class="p">,</span><span class="s">"%s is running for client (%p): %s"</span><span class="p">,</span>
<span class="n">s_threadName</span><span class="p">,</span><span class="n">m_client</span><span class="p">,</span><span class="n">m_address</span><span class="p">.</span><span class="n">c_str</span><span class="p">());</span>
<span class="k">while</span> <span class="p">(</span><span class="nb">true</span><span class="p">)</span> <span class="p">{</span>
<span class="k">if</span> <span class="p">(</span><span class="n">m_client</span><span class="o">-&</span><span class="n">gt</span><span class="p">;</span><span class="n">process</span><span class="p">())</span>
<span class="n">Thread</span><span class="o">::</span><span class="n">check</span><span class="p">(</span><span class="nb">true</span><span class="p">);</span>
<span class="k">else</span>
<span class="n">Thread</span><span class="o">::</span><span class="n">yield</span><span class="p">(</span><span class="nb">true</span><span class="p">);</span>
<span class="p">}</span>
<span class="p">}</span>
</pre></p>
<p>So basically the thread is continuously calling Thread:yield rather than waiting on some actual I/O to happen.</p></code></pre> OsmoSGSN - Bug #6176 (New): build failure (dependency / concurrency issue)https://osmocom.org/issues/61762023-09-13T15:02:17Zlaforge
<p>when trying <code>make -j8 check</code> in current master (which is also 1.11.0):</p>
<pre>
...
Making check in src
make[4]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[2]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[5]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[5]: Nothing to be done for 'install-exec-am'.
make[5]: Nothing to be done for 'install-data-am'.
make[5]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[4]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include/osmocom'
Making check in gprs
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[4]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[4]: Nothing to be done for 'install-exec-am'.
make[4]: Nothing to be done for 'install-data-am'.
make[4]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/include'
Making install in src
make[2]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
CC crc24.lo
CC gprs_llc_parse.lo
CC gprs_utils.lo
Making install in gprs
CC sgsn_ares.lo
make[3]: Entering directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
CC gprs_llc_parse.lo
CC crc24.lo
CC gprs_utils.lo
CC sgsn_ares.lo
mv: cannot stat '.deps/crc24.Tpo': No such file or directory
make[3]: *** [Makefile:454: crc24.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
mv: cannot stat 'gprs_utils.loT': No such file or directory
mv: cannot stat '.deps/gprs_utils.Tpo': No such file or directory
make[3]: *** [Makefile:454: gprs_utils.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
make[2]: *** [Makefile:393: install-recursive] Error 1
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[1]: *** [Makefile:461: install-recursive] Error 1
make[1]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn'
make: *** [Makefile:765: install] Error 2
make: *** Waiting for unfinished jobs....
make[3]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src/gprs'
make[2]: *** [Makefile:393: check-recursive] Error 1
make[2]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn/src'
make[1]: *** [Makefile:461: check-recursive] Error 1
make[1]: Leaving directory '/space/home/laforge/projects/git/osmo-sgsn'
make: *** [Makefile:760: check] Error 2
</pre>
<p>doing that with <code>-j1</code> works, though.</p> Cellular Network Infrastructure - Bug #6122 (New): remove big endian supporthttps://osmocom.org/issues/61222023-07-31T09:46:32Zosmith
<p>Follow-up to <a class="external" href="https://lists.osmocom.org/hyperkitty/list/openbsc@lists.osmocom.org/thread/ORBO2FWVVPCHTAXSPZTQLSSM4YB76ITB/">https://lists.osmocom.org/hyperkitty/list/openbsc@lists.osmocom.org/thread/ORBO2FWVVPCHTAXSPZTQLSSM4YB76ITB/</a></p> pySim - Bug #6120 (New): select MF raise an exception after selecting ADF.ARA-Mhttps://osmocom.org/issues/61202023-07-28T23:02:32Zlynxis
<p>Steps to reproduce:<br />Version: git/master 6c5c3f8b2b49a56b6204be83ded918bec0c5826f<br />Simcard: SysmocomSJA2</p>
<pre>
Welcome to pySim-shell!
pySIM-shell (MF)> select ADF.ARA-M
""
pySIM-shell (MF/ADF.ARA-M)> select MF
EXCEPTION of type 'RuntimeError' occurred with message: 6e00: ARA-M - Invalid class
To enable full traceback, run the following command: 'set debug true'
pySIM-shell (MF/ADF.ARA-M)> set debug true
debug - was: False
now: True
pySIM-shell (MF/ADF.ARA-M)> select MF
Traceback (most recent call last):
File "/home/lynxis/projects/osmocom/repos/pysim/pySim/runtime.py", line 347, in select
(data, sw) = self.rs.card._scc.select_file(f.fid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/lynxis/projects/osmocom/repos/pysim/pySim/commands.py", line 144, in select_file
return self._tp.send_apdu_checksw(self.cla_byte + "a4" + self.sel_ctrl + "02" + fid)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/lynxis/projects/osmocom/repos/pysim/pySim/transport/__init__.py", line 213, in send_apdu_checksw
raise SwMatchError(rv[1], sw.lower(), self.sw_interpreter)
pySim.exceptions.SwMatchError: SW match failed! Expected 9000 and got 6e00: ARA-M - Invalid class
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/lynxis/.local/share/virtualenvs/pysim-C216Z-pe/lib/python3.11/site-packages/cmd2/cmd2.py", line 2399, in onecmd_plus_hooks
stop = self.onecmd(statement, add_to_history=add_to_history)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/lynxis/.local/share/virtualenvs/pysim-C216Z-pe/lib/python3.11/site-packages/cmd2/cmd2.py", line 2852, in onecmd
stop = func(statement)
^^^^^^^^^^^^^^^
File "/home/lynxis/projects/osmocom/repos/pysim/./pySim-shell.py", line 814, in do_select
fcp_dec = self._cmd.lchan.select(path, self._cmd)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/lynxis/projects/osmocom/repos/pysim/pySim/runtime.py", line 353, in select
raise RuntimeError("%s: %s - %s" % (swm.sw_actual, k[0], k[1]))
RuntimeError: 6e00: ARA-M - Invalid class
EXCEPTION of type 'RuntimeError' occurred with message: 6e00: ARA-M - Invalid class
</pre> OsmoMGW - Bug #6060 (New): osmo-mgw: Implement MGCP RestartInProgress (RSIP)https://osmocom.org/issues/60602023-06-13T12:02:02Zpespin
<p>We could delay exit() of the osmo-mgw process during SIGINT, to transmit RestartInProgress to all active endpoints, so that the call agent (bsc, msc, etc.) knows it has to terminate the calls.<br />This could perhaps even be used by Call agent to keep calls working by signalling peer BSC/BTS/MSC/etc. to change to another MGW if there's an MGW pool with more available MGW, providing higher reliability?</p>
<p>This could also be used to signal disconnect or temporary unavailability to E1 timeslots, etc.</p>
<p><a class="external" href="https://datatracker.ietf.org/doc/html/rfc3435#section-2.3.12">https://datatracker.ietf.org/doc/html/rfc3435#section-2.3.12</a><br /><a class="external" href="https://datatracker.ietf.org/doc/html/rfc3435#section-3.3.8">https://datatracker.ietf.org/doc/html/rfc3435#section-3.3.8</a><br /><a class="external" href="https://datatracker.ietf.org/doc/html/rfc3435#appendix-F.10">https://datatracker.ietf.org/doc/html/rfc3435#appendix-F.10</a></p>
<pre>
* The Gateway can use the RestartInProgress command to notify the
Call Agent that a group of endpoints managed by the gateway is
being taken out-of-service or is being placed back in-service.
</pre>
<pre>
2.3.12 RestartInProgress
The RestartInProgress command is used by the gateway to signal that
an endpoint, or a group of endpoints, is put in-service or out-of-
service.
</pre>
<pre>
Gateways SHOULD send a "graceful" or "forced" RestartInProgress
message (for the relevant endpoints) as a courtesy to the Call Agent
when they are taken out-of-service, e.g., by being shutdown, or taken
out-of-service by a network management system, however the Call Agent
cannot rely on always receiving such a message. Gateways MUST send a
"restart" RestartInProgress message (for the relevant endpoints) with
a null delay to their Call Agent when they are back in-service
according to the restart procedure specified in Section 4.4.6 - Call
Agents can rely on receiving this message. Also, gateways MUST send
a "disconnected" RestartInProgress message (for the relevant
endpoints) to their current "notified entity" according to the
"disconnected" procedure specified in Section 4.4.7.
The RestartInProgress message will be sent to the current "notified
entity" for the EndpointId in question. It is expected that a
default Call Agent, i.e., "notified entity", has been provisioned so
that after a reboot/restart, the default Call Agent will always be
the "notified entity" for the endpoint. Gateways SHOULD take full
advantage of wild-carding to minimize the number of RestartInProgress
messages generated when multiple endpoints in a gateway restart and
the endpoints are managed by the same Call Agent.
</pre>
<pre>
8) RestartInProgress MUST always be the first command sent by an
endpoint as defined by the restart procedure. Any other command
or non-restart response (see Section 4.4.6), except for responses
to auditing, MUST be delivered after this RestartInProgress
command (piggybacking allowed).
</pre>
<pre>
In some cases, many gateways may decide to restart operation at the
same time. This may occur, for example, if an area loses power or
transmission capability during an earthquake or an ice storm. When
power and transmission are reestablished, many gateways may decide to
send "RestartInProgress" commands simultaneously, leading to very
unstable operation.
</pre>
<pre>
A virtual endpoint may be created as the result of using the "any of"
wildcard. Similarly, a virtual endpoint may cease to exist once the
last connection on the virtual endpoint is deleted. The definition
of the virtual endpoint MUST detail both of these aspects.
When a <virtual-endpoint-type> creates and deletes virtual endpoints
automatically, there will be cases where no virtual endpoints exist
at the time a RestartInProgress command is to be issued. In such
cases, the gateway SHOULD simply use the "all of" wildcard in lieu of
any specific <endpoint-#> as in, e.g.:
ann/*@mygateway.whatever.net
If the RestartInProgress command refers to all endpoints in the
gateway (virtual or not), the <virtual-endpoint-id> can be omitted as
in, e.g.:
*@mygateway.whatever.net
</pre>
<p>It seems we must also be sending that message for each available endpoint at startup AFAIU (or 1 with wildcard "*"). We seem to be missing a "default Call Agent" in osmo-mgw though":<br /><pre>
It is expected that a
default Call Agent, i.e., "notified entity", has been provisioned so
that after a reboot/restart, the default Call Agent will always be
the "notified entity" for the endpoint.
....
Note that as mentioned earlier, the default "notified entity" is
provisioned and may include both domain name and port. For small
gateways, provisioning may be done on a per endpoint basis. For much
larger gateways, a single provisioning element may be provided for
multiple endpoints or even for the entire gateway itself. In either
case, once the gateway powers up, each endpoint MUST have its own
"notified entity", so provisioned values for an aggregation of
endpoints MUST be copied to the "notified entity" for each endpoint
in the aggregation before operation proceeds. Where possible, the
RestartInProgress command on restart SHOULD be sent to the
provisioned "notified entity" based on an aggregation that allows the
"all of" wild-card to be used. This will reduce the number of
RestartInProgress messages.
</pre></p> libosmocore - Bug #6021 (New): map file breaks recent lld buildshttps://osmocom.org/issues/60212023-05-02T08:49:54ZHoernchen
<p>lld defaults to --no-undefined-version since <a class="external" href="https://reviews.llvm.org/D135402">https://reviews.llvm.org/D135402</a> which breaks building if not all symbols mentioned in the map file exist, i.e. by building libosmocore without systemd. Fix: add -Wl,--undefined-version to the LDFLAGS.</p> OsmoBTS - Bug #5995 (New): osmo-bts printing log line 'OC=GPRS-NSE(f0) INST=(00,ff,ff): Tx unkno...https://osmocom.org/issues/59952023-04-04T18:16:58Zpespin
<p>osmo-bts fails to log properly name string of NM_MT_IPACC_SET_ATTR_ACK in oml_mo_send_msg():</p>
<pre>
DEBUGPFOH(DOML, foh, "Tx %s\n", get_value_string(abis_nm_msgtype_names, foh->msg_type));
</pre>
<p>This is because IPACCESS specific messages (enum abis_nm_msgtype_ipacc) are not included in "abis_nm_msgtype_names".</p>
<p>We need to discuss whether we want them added to "abis_nm_msgtype_names" or have some way to also translate those.<br />The problem is that there can be other vendors providing other extensions which may reuse same enum values, such as enum abis_nm_msgtype_bs11.<br />So ideally we should add a function to first check abis_nm_msgtype_names() and if it fails (or within expected range for vendor-implementation) then translte from "enum abis_nm_msgtype_ipacc".</p> OsmoBTS - Bug #5957 (New): not all osmo-bts variants respond to abisip-findhttps://osmocom.org/issues/59572023-03-22T09:20:14Zlaforge
<p>The abisip-find utility uses brodcast UDP packets to obtain a list of all BTSs reachable via the local network segment using the <code>abisip-find</code> utility (part of osmo-bsc source code).</p>
<p>For some reason unknown to me, this functionality is implemented as part of osmobts-{sysmo,lc15,oc2g}-mgr, and not part of the normal osm-bts-* program. This means that osmo-bts-trx doesn't suppport the feature.</p>
<p>Looking at <code>{oc2g,lc15,sysmo}bts_mgr_nl.c</code> in the sourec code, the only difference is the code obtaining parameters such as serial number, BTS model name and Ethernet MAC adress.</p>
IMHO, the code could be unified to have
<ul>
<li>one common/shared implementation, that
<ul>
<li>becomes part of the normal osmo-bts binary</li>
<li>gets passed in the model-specific information via some struct from the model-specific part when initialized</li>
</ul></li>
</ul>
<p>Assigning to <a class="user active" href="https://osmocom.org/users/42">jolly</a> (for after april 1st)</p>
<p>Afterwards, <a class="external" href="https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/32004">https://gerrit.osmocom.org/c/osmo-gsm-manuals/+/32004</a> can be merged to update documentation</p> Core testing infrastructure - Bug #5919 (New): osmo-python-tests: Update/fix README or setup processhttps://osmocom.org/issues/59192023-02-22T18:25:53Zarehbein
<p><code>osmo-python-tests/README</code> states three ways of installation. Two of these failed for me:</p>
<pre>
$ pip3 install --verbose --user -e .
...
Installing collected packages: osmopython
Running setup.py develop for osmopython
Running command /usr/bin/python3 -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/home/somedir/osmo-python-tests/setup.py'"'"'; __file__='"'"'/home/somedir/osmo-python-tests/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop --no-deps --user --prefix=
running develop
running egg_info
error: [Errno 13] Permission denied
ERROR: Command errored out with exit status 1: /usr/bin/python3 -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/home/somedir/osmo-python-tests/setup.py'"'"'; __file__='"'"'/home/somedir/osmo-python-tests/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' develop --no-deps --user --prefix= Check the logs for full command output.
Exception information:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/pip/_internal/cli/base_command.py", line 223, in _main
status = self.run(options, args)
File "/usr/lib/python3/dist-packages/pip/_internal/cli/req_command.py", line 180, in wrapper
return func(self, options, args)
File "/usr/lib/python3/dist-packages/pip/_internal/commands/install.py", line 421, in run
installed = install_given_reqs(
File "/usr/lib/python3/dist-packages/pip/_internal/req/__init__.py", line 82, in install_given_reqs
requirement.install(
File "/usr/lib/python3/dist-packages/pip/_internal/req/req_install.py", line 800, in install
install_editable_legacy(
File "/usr/lib/python3/dist-packages/pip/_internal/operations/install/editable_legacy.py", line 49, in install_editable
call_subprocess(
File "/usr/lib/python3/dist-packages/pip/_internal/utils/subprocess.py", line 261, in call_subprocess
raise InstallationSubprocessError(proc.returncode, command_desc)
</pre>
<p>Seems like the command is throwing an error, because the prefix option is passed with an empty argument, but I don't know.</p>
<p>For checkinstall, the Debian package isn't built if one leaves the default value for version (<code>test</code>), since it hast to begin with a digit:</p>
<pre>
dpkg-deb: error: parsing file '/var/tmp/tmp.6EyaipPJOV/package/DEBIAN/control' near line 7 package 'osmo-python':
'Version' field value 'tests-1': version number does not start with digit
</pre>
<p>Outputs for each command are attached.</p> libosmocore - Bug #5915 (New): gprs: ns2: convert timers into osmo-timershttps://osmocom.org/issues/59152023-02-20T22:01:55Zlynxis
<p>gprs_ns2 isn't using osmo-timers for the internal timers.</p>
<pre>
# libosmocore/src/gb/gprs_ns2_vty.c:93
/* TODO: this should into osmo timer */
static const struct value_string gprs_ns_timer_strs[] = {
{ 0, "tns-block" },
{ 1, "tns-block-retries" },
{ 2, "tns-reset" },
{ 3, "tns-reset-retries" },
{ 4, "tns-test" },
{ 5, "tns-alive" },
{ 6, "tns-alive-retries" },
{ 7, "tsns-prov" },
{ 8, "tsns-size-retries" },
{ 9, "tsns-config-retries" },
{10, "tsns-procedures-retries" },
{ 0, NULL }
};
</pre> libosmo-sccp + libosmo-sigtran - Bug #5899 (New): ttcn3-sccp-test-latest is actually running code...https://osmocom.org/issues/58992023-02-09T16:40:05Zosmith
<p>In jenkins.sh:</p>
<pre>
# Always require osmo-stp-master since is the only with sccp_demo_user installed
docker_images_require \
"osmo-stp-master" \
"ttcn3-sccp-test"
</pre>
<p>A way to resolve this would be packaging the demo programs sccp_demo_user (and _server?) in a -demos subpackage.</p>
<p>We only have one test in the testsuite, so this doesn't have much of an impact, just noting for future reference.</p> OsmoBTS - Bug #5895 (New): LC15: Audio Quality Problem sometime after cf7a7fcebf625a14fd764355c3b...https://osmocom.org/issues/58952023-02-07T03:11:09Zkeith
<p>Writing this up now while it's a bit fresh...</p>
<p>I have spent the last 12 hours or so working with people on site to try to track down these problems:</p>
<p>Fierce complaints about audio quality (no audio, unintelligible, intermittent, chopped)</p>
<p>Observation of a lot of very variable Q in meas reps, especially on downlink (associated with bad audio) and more pronounced when the call B-leg was using another codec such as G.729 on the other side of the PBX, - in fact not transcoding at site and sending AMR to our data centre and trancoding there to PCMA/U for the upstream VoIP was giving better results most of the time.</p>
<p>However, today I discovered the extent of how bad this was on local MS to MS calls.</p>
<p>After exhausting everything I could think of, we went back to the timeline and there were some opinions that this started around a date last year which seemed to be around the time I changed this site away from osmo-nitb. Given I wasn't seeing any signalling problems, I had been looking for problems with maybe the MGW or something with RTP that would have changed. but I could find nothing.</p>
<p>Of course none of that was at fault, what happened was that along with the move to osmo-bsc, I built v1.4.0 of osmo-bts - I think not 1.5.0 because at the time 1.4.0 built against the libs I had on the BTS, anyway, going back to the binary I had built before from cf7a7fce "solves" the problem.</p>
<p>Given the current somewhat tense situation I don't envisage "test"-ing anything at this site for the time being so I can't exactly try to dissect between cf7a7fce and 1.4.0 not that it would be very easy to run each commit against a bunch of manual tests that annoy the local people, asking them to make calls to each other.</p>
<p>So what to do? Well note it at least. I don't have another lc15 to test on. <br />Maybe shout-out to the main devs who committed code that touched lc15 or common, (which seems to have to do with power control, interference measurements) to see if they have any ideas. My feeling is that something that was done is not happy on the LC15 PHY.</p>
<p>There's the chance that this was fixed since 1.4.0 or in another lib.</p>
<p><em>Trivia: cf7a7fce is the last commit that can do RSL/OML bring-up against osmo-nitb.. that's why that one.</em></p> Cellular Network Infrastructure - Bug #5887 (New): coverity: build everything in docker container...https://osmocom.org/issues/58872023-02-01T10:25:23Zosmith
<p>Currently the coverity scripts are not automatically tested before merging, and when they fail it is quite some effort to reproduce the errors as one has to manually install all dependencies (and missing ones only show up half-way through the build when something fails). Also libusrp requires sdcc 3, while e.g. on this system I have sdcc 4 installed.</p> Cellular Network Infrastructure - Bug #5819 (New): Gerrit/gitiles: Parent links don't workhttps://osmocom.org/issues/58192022-12-08T13:28:35Zarehbein
<p>When clicking the parent link in a Gitiles commit view, I get an error message</p>
<pre><code>Secure Connection Failed<br />An error occurred during a connection to gerrit.osmocom.org:80. SSL received a record that exceeded the maximum permissible length.<br />Error code: SSL_ERROR_RX_RECORD_TOO_LONG</code></pre>
<p>I have encountered this before and now again, for example here<br /><a class="external" href="https://gerrit.osmocom.org/plugins/gitiles/osmo-upf/+/2430533206004a8d9c29dc837cd08efe0d264dfb">https://gerrit.osmocom.org/plugins/gitiles/osmo-upf/+/2430533206004a8d9c29dc837cd08efe0d264dfb</a></p> OsmoBSC - Bug #5744 (New): sysmobts: when a BTS is rf_locked and doesn't support BTS_FEAT_MULTI_T...https://osmocom.org/issues/57442022-11-07T16:15:02Zlynxis
<p>I need to validate and reproduce this issue.</p>
<ul>
<li>Use a osmo-bsc with a sysmobts 1020.</li>
<li>Configure the bts on the bsc as `rf_locked 1`</li>
<li>Configure a BSIC != 0</li>
<li>Start/Power up the BTS 1020.</li>
<li>The OML connection will be dropped by the BSC after the BTS answered invalid configuration.</li>
</ul>
<p>The problem is the BSIC configuration. The sysmobts 1020 doesn't support BTS_FEAT_MULTI_TSC. The BSIC isn't set on the BTS MO (because of the rf_locked 1), but the TSC is set on the channel.</p>
<p>A fix would be always configuring the BSIC on BTS MO or delay the <del>TRX</del> channel configuration.</p> osmo-remsim - Bug #5628 (New): client-st2: error mesasges when mapping is removedhttps://osmocom.org/issues/56282022-07-24T07:14:57Zlaforge
<pre>
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DLINP NOTICE simtrace2_api.c:168 [0] <= osmo_st2_cardem_request_card_insert(inserted=0)
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DLINP NOTICE simtrace2_api.c:317 [0] <= _modem_sim_select(remote_sim=0)
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DLINP NOTICE simtrace2_api.c:285 [0] <= _modem_reset(asserted=2, pulse_ms=300)
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DRSPRO ERROR ../rspro_client_fsm.c:359 RSPRO_CLIENT(bankd){CONNECTED}: Event SRVC_E_KA_TERMINATED not permitted
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DRSPRO INFO ../rspro_client_fsm.c:363 RSPRO_CLIENT(bankd){CONNECTED}: Destroying existing connection to server
Jul 24 08:13:17 remsim-client osmo-remsim-client-st2[1258]: DMAIN ERROR ../rspro_client_fsm.c:279 CLIENT_MAIN(main){UNCONFIGURED}: Event MF_E_BANKD_LOST not permitted
</pre>
<p>not a big deal, but removing a mapping is normal business, it shoulnd't result in error messages.</p> OsmoCBC - Bug #5585 (New): CBC should not send WRITE-REPLACE to cells that had sent FAILUREhttps://osmocom.org/issues/55852022-06-21T09:41:51Zlaforge
<p>TS 48.049 states about the CBC behaviour :</p>
<blockquote>
<p>Upon receipt of the FAILURE message, the CBC shall not initiate further WRITE-REPLACE messages for concerned cell(s) until the CBC is informed, by the RESTART message, that the cell(s) have resumed CBS message operational state or emergency message operational state again.</p>
</blockquote>
<p>However, osmo-cbc is currently still sending WRITE-REPLACE in such situations.</p> libosmo-sccp + libosmo-sigtran - Bug #5561 (New): pc=0=0.0.0 / RCOC-ERROR.ind not permittedhttps://osmocom.org/issues/55612022-05-13T18:03:28Zlaforge
<p>On a rhizomatica deployment of osmo-msc + osmo-bsc I saw a series of bursts of these after some hours of operation:</p>
<pre>
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3456)[0x555555e9f740]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3455)[0x555555e9f9a0]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3463)[0x555555d2d450]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3462)[0x555555d1d860]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3461)[0x555555a5d200]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3460)[0x555555836d20]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3459)[0x555555a1c7b0]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3466)[0x555555ba5830]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3465)[0x555555a2c140]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3464)[0x555555d91620]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3454)[0x555555c235d0]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
DLSCCP ERROR sccp_scoc.c:1698 SCCP-SCOC(3453)[0x555555d42630]{DISCONN_PEND}: Event RCOC-ERROR.ind not permitted
</pre>
<p>The BSC side for this is:</p>
<pre>
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
May 13 12:59:16 huautla-bsc osmo-bsc[5253]: DLSCCP NOTICE sccp_scoc.c:1597 Received message for opc=185=0.23.1 on conn with mismatching remote pc=0=0.0.0
</pre>
<p>Unfortunately I have no pcap file.</p>
<p>The error disappeared automatically just as it appeared...</p> osmo-e1d - Bug #5521 (New): don't attempt OCTOI connection of no TDM data from driver (icE1usb)https://osmocom.org/issues/55212022-04-10T10:40:32Zlaforge
<p>If there is no TDM data from the icE1usb device (loss of signal, ...) the octoi client should not attempt to connect. Basically it gets stuck in an indefinite loop of connect, timeout (due to no TDM frames), connect, timeout, ...</p> Retronetworking - Bug #5512 (New): Idea: L1OIP driver for DAHDIhttps://osmocom.org/issues/55122022-04-03T11:46:45Zlaforge
<p>mISDN has <code>l1oip</code> as a protocol to use to establish virtual PRI or BRI trunks between different machines using mISDN.</p>
<p>Implementing L1OIP support in DAHDI would allow a virtual PRI/BRI line between a DAHDI machine and a mISDN machine, making it easier to user mISDN applications without the related hardware.</p> osmo-e1d - Bug #5499 (New): octoi client binds to specific IP even if 0.0.0.0 is specifiedhttps://osmocom.org/issues/54992022-03-28T10:38:46Zlaforge
<p>Even if the config file specifies 0.0.0.0 as the local address for the client, the socket apparently still gets bound to a specifid address at the time of the bind/connect.</p>
<pre>
udp 0 0 192.168.2.6:3333 90.187.70.153:10010 VERBUNDEN
</pre>
<p>This means that the OCTOI connection breaks as soon as the client gets a different IP address (e.g. by DHCP).</p>
<p>The odd part is that this doesn't happen on the server side. My socket looks like this:<br /><pre>
udp 0 0 0.0.0.0:10010 0.0.0.0:*
</pre></p> OsmoMSC - Bug #5491 (New): MT CSFB calls fail (only) first time after Airplane mode toggle (proba...https://osmocom.org/issues/54912022-03-19T02:49:20Zkeith
<p>To reproduce:</p>
<p>With working EUTRAN and GERAN networks, toggle airplane mode. Phone (re)-ATTACHes to LTE network.</p>
<p>Call the phone:</p>
<p>In osmo-msc: (i've attached the entire debug log)</p>
<pre>
20220319023547480 DMM DEBUG msc_a(TMSI-0x2F655780:GERAN-A-50:LU)[0x55b8e91359b0]{MSC_A_ST_VALIDATE_L3}: LOCATION UPDATING REQUEST: MI=TMSI-0x2F655780 LU-type=NORMAL (gsm_04_
20220319023547480 DMM DEBUG msc_a(TMSI-0x2F655780:GERAN-A-50:LU)[0x55b8e91359b0]{MSC_A_ST_VALIDATE_L3}: USIM: old LAI: 334-07-101 (gsm_04_08.c:407)
20220319023547480 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 for MNCC: establish call: Paging Response action (expired) (paging.c:154)
20220319023547480 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 for MNCC: establish call: Removing Paging Request (paging.c:127)
20220319023547480 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 callref-0x13ad tid-255) Paging expired (gsm_04_08_cc.c:339)
20220319023547480 DMNCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 callref-0x13ad tid-255) tx MNCC_REL_IND (gsm_04_08_cc.c:237)
20220319023547480 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x2F655780 callref-0x0 tid-255) Freeing transaction (transaction.c:230)
</pre>
<p>After this 1st try, the subsequent try succeeds:</p>
<pre>
20220319024811027 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 callref-0x13af tid-255) New transaction (transaction.c:218)
20220319024811027 DMNCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 callref-0x13af tid-255) rx MNCC_SETUP_REQ (gsm_04_08_cc.c:1979)
20220319024811027 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 for MNCC: establish call: Starting paging (paging.c:101)
20220319024814102 DMM DEBUG Tx AUTH REQ (rand = 07e7f2e89f5782be2bac726d7d90914a) (gsm_04_08.c:642)
20220319024814102 DMM DEBUG AUTH REQ (autn = e6ab0ad9e6a7000050ffb868d2a25996) (gsm_04_08.c:644)
20220319024815042 DMM DEBUG msc_a(IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684:GERAN-A-52:PAGING_RESP)[0x55b8e913d250]{MSC_A_ST_AUTH_CIPH}: MM UMTS AUTHENTICATION RESPONSE (res = 6ce1b1df36c7c61f) (gsm_04_08.c:1119)
20220319024815749 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 for MNCC: establish call: Paging Response action (success) (paging.c:154)
20220319024815749 DPAG DEBUG Paging: IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 for MNCC: establish call: Removing Paging Request (paging.c:127)
20220319024815749 DCC DEBUG trans(CC:NULL IMSI-334070000000968:MSISDN-12345174747:TMSI-0x24706684 callref-0x13af tid-255) Paging succeeded (gsm_04_08_cc.c:316)
</pre>
<p>There's a difference in show subscriber cache after an ATTACH via SGS as opposed to a complete LUR on GERAN (we have auth data):</p>
<pre>
show subscriber cache
Subscriber #00:
MSISDN: 12345174747
LAC / cell ID: 101 / 100
RAN type: EUTRAN-SGs
IMSI: 334070000000968
TMSI: 1E460BB7
IMEI: 35729207588080
IMEISV: 3572920758808001
Flags:
IMSI detached: false
Conf. by radio contact: true
Subscr. data conf. by HLR: true
Location conf. in HLR: true
Subscriber dormant: false
Received cancel location: false
MS not reachable: false
LA allowed: true
A3A8 last tuple (used 1 times):
seq # : 4
RAND : 17 8a 18 c2 62 8e 85 a5 fe a1 1b 03 c2 51 37 9a
SRES : a0 10 84 9a
Kc : 01 1d 45 1b 6c 47 74 00
Expires: never
Paging: not paging for 0 requests
SGs-state: SGs-ASSOCIATED
SGs-MME: mmec01.mmegi0002.mme.epc.mnc007.mcc334.3gppnetwork.org
Use count total: 1
Use count: 1 (attached)
</pre>
<pre>
show subscriber cache
Subscriber #00:
MSISDN: 12345174747
LAC / cell ID: 101 / 0
RAN type: EUTRAN-SGs
IMSI: 334070000000968
TMSI: 2F655780
Flags:
IMSI detached: false
Conf. by radio contact: true
Subscr. data conf. by HLR: true
Location conf. in HLR: true
Subscriber dormant: false
Received cancel location: false
MS not reachable: false
LA allowed: true
Expires: never
Paging: not paging for 0 requests
SGs-state: SGs-ASSOCIATED
SGs-MME: mmec01.mmegi0002.mme.epc.mnc007.mcc334.3gppnetwork.org
Use count total: 1
Use count: 1 (attached)
</pre>
<p>Assigning to myself; I do intend to fix it.</p>
<p>Would appreciate confirmation all the same from anybody else who has a working setup, or even some static analysis by those more familiar with this code.</p>