Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092023-12-23T15:12:32ZOpen Source Mobile Communications
Redmine pySim - Bug #6317 (Stalled): data driven tests for TLV decodershttps://projects.osmocom.org/issues/63172023-12-23T15:12:32Zlaforge
<p>While we do have the <code>_test_de_encode</code> data driven tests for file definitions, we don't yet have something similar for derived classes of BER_TLV_IE. This means that TLVs used outside of the filesystem context (for example, decoding the SELECT/STATUS response, but also eUICC and other stuff) do not yet have test coverage.</p> Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall) - Bug #6291 (New): 2024 event bringing tog...https://projects.osmocom.org/issues/62912023-12-06T14:31:01Zlaforge
<p>I've been considering this for a number of years, but never actually got aroun to acting on it:</p>
<p>Have an event where the various FOSS mobile communications projects meet, get to know each other and exchange status, plans and ideas.</p>
<p>Matthias Kirschner of the FSFE suggested to <em>attach</em> that event to sfscon (<a class="external" href="https://www.sfscon.it/">https://www.sfscon.it/</a>) and do it a few days ahead (or after) the 2024 incarnation, which is likely happning again in November 2024. The FSFE could help with funding of the related expenses from a donation made by sysmocom to FSFE earmarked to help FOSS in mobile communications.</p>
<p>Let's use this issue to collect a list of projects we'd want to invite, and to generally keep track on status.</p>
<p>For now, I am thinking of the following potential projects:</p>
<a name="cellular-infrastructureprotocol-stacks"></a>
<h2 >cellular infrastructure/protocol stacks<a href="#cellular-infrastructureprotocol-stacks" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://osmocom.org/" class="external">Osmocom</a></li>
<li><a href="https://open5gs.org/" class="external">open5gs</a></li>
<li><a href="https://www.srslte.com/" class="external">srsRAN/srsUE</a></li>
<li><a href="https://free5gc.org/" class="external">free5gc</a></li>
<li><a href="https://github.com/edgecomllc/eupf" class="external">eupf</a></li>
<li><a href="https://github.com/travelping/ergw" class="external">ergw</a></li>
<li><a href="https://magmacore.org/" class="external">Magma</a> + <a href="https://github.com/magma/S1APTester" class="external">S1APTester</a></li>
<li><a href="https://github.com/omec-project" class="external">OMEC</a></li>
<li><a href="https://github.com/wmnsk" class="external">wmnsk</a> and his various go-{gtp,pfcp,m3ua,sccp,tcap} projects</li>
</ul>
<a name="SIM-card-related-projects"></a>
<h2 >SIM card related projects<a href="#SIM-card-related-projects" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://github.com/tomasz-lisowski/swsim" class="external">swsim</a> + <a href="https://github.com/tomasz-lisowski/swicc" class="external">swicc</a></li>
</ul>
<a name="Development-Debugging"></a>
<h2 >Development + Debugging<a href="#Development-Debugging" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://github.com/fgsect/scat" class="external">SCAT</a></li>
<li><a href="https://github.com/P1sec/QCSuper" class="external">QCsuper</a></li>
<li><a href="https://github.com/PentHertz/Modmobmap" class="external">Modmobmap</a></li>
<li><a href="https://github.com/SysSec-KAIST/LTESniffer" class="external">LTESniffer</a></li>
<li><a href="https://github.com/falkenber9/falcon" class="external">FALCON</a></li>
<li><a href="https://github.com/aligungr/UERANSIM" class="external">UERANSIM</a></li>
<li><a href="https://github.com/HewlettPackard/PacketRusher" class="external">PacketRusher</a></li>
<li>the various projects by <a href="https://github.com/fasferraz" class="external">fasferraz</a> (Swu-IKEv2, ...)</li>
<li><a href="https://github.com/P1sec/pycrate" class="external">pycrate</a></li>
</ul>
<a name="FOSS-software-stacks-on-mobile-devices"></a>
<h2 >FOSS software stacks on mobile devices<a href="#FOSS-software-stacks-on-mobile-devices" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://postmarketos.org/" class="external">postmarketos</a></li>
<li><a href="https://replicant.us/" class="external">replicant</a></li>
<li><a href="https://ubuntu-touch.io/" class="external">Ubuntu touch</a></li>
</ul>
<p>I'm very happy to accept further suggestions for projects/people to add to the invite list.</p> osmo-e1d - Bug #6169 (New): Frame masking against network frame ordering, not frame numbershttps://projects.osmocom.org/issues/61692023-09-06T08:33:34Zmanawyrm
<p>The osmo-e1d code includes functionality to save bandwidth by not transmitting timeslots, which haven't changed since the last frame.</p>
<p><a class="external" href="https://gitea.osmocom.org/Manawyrm/osmo-e1d/src/branch/master/src/octoi/e1oip.c#L263">https://gitea.osmocom.org/Manawyrm/osmo-e1d/src/branch/master/src/octoi/e1oip.c#L263</a></p>
<p>Later in development, the frame_rifo was introduced to combat packet reordering in real-world networks (like DOCSIS).<br />The code unpacking the timeslots into full E1 frames is currently unpacking against the last frame in the incoming buffer, not the last frame in the RIFO (random in, first out) buffer.<br />This means that frames will get filled with random data from other frames in the event of a re-ordering.</p>
<p>Unpacking/Unmasking should be done after the RIFO mechanism.</p> pySim - Bug #6119 (In Progress): aram_get_config runs into an exception on a sysmocomSJA2https://projects.osmocom.org/issues/61192023-07-28T22:48:14Zlynxis
<ul>
<li>Use a SysmocomSJA2</li>
<li>pysim master / 791f80a44f8110f478a632cd2bcde5944ad4bd96</li>
</ul>
<pre>
pySIM-shell (MF)> select ADF.ARA-M
pySIM-shell (MF/ADF.ARA-M)> aram_get_config
EXCEPTION of type 'ValueError' occurred with message: auto_collection_DeviceConfigDO(<class 'pySim.ara_m.DeviceInterfaceVersionDO'>): Unknown TLV Class DeviceInterfaceVersionDO in [{'DeviceInterfaceVersionDO': {'major': 0, 'minor': 0, 'patch': 1}}]; expected dict_keys(['device_interface_version_do'])
To enable full traceback, run the following command: 'set debug true'
pySIM-shell (MF/ADF.ARA-M)>
pySIM-shell (MF/ADF.ARA-M)> set debug true
debug - was: False
now: True
pySIM-shell (MF/ADF.ARA-M)> aram_get_config
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/ara_m.py", line 315, in do_aram_get_config
res_do = ADF_ARAM.get_config(self._cmd.card._scc._tp)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/lynxis/projects/osmocom/repos/pysim/pySim/ara_m.py", line 298, in get_config
cmd_do.from_dict([{'DeviceInterfaceVersionDO': {
File "/home/lynxis/projects/osmocom/repos/pysim/pySim/tlv.py", line 161, in from_dict
self.children = self.nested_collection.from_dict(decoded)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/lynxis/projects/osmocom/repos/pysim/pySim/tlv.py", line 406, in from_dict
raise ValueError('%s: Unknown TLV Class %s in %s; expected %s' %
ValueError: auto_collection_DeviceConfigDO(<class 'pySim.ara_m.DeviceInterfaceVersionDO'>): Unknown TLV Class DeviceInterfaceVersionDO in [{'DeviceInterfaceVersionDO': {'major': 0, 'minor': 0, 'patch': 1}}]; expected dict_keys(['device_interface_version_do'])
EXCEPTION of type 'ValueError' occurred with message: auto_collection_DeviceConfigDO(<class 'pySim.ara_m.DeviceInterfaceVersionDO'>): Unknown TLV Class DeviceInterfaceVersionDO in [{'DeviceInterfaceVersionDO': {'major': 0, 'minor': 0, 'patch': 1}}]; expected dict_keys(['device_interface_version_do'])
pySIM-shell (MF/ADF.ARA-M)>
pySIM-shell (MF/ADF.ARA-M)> aram_get_all
[
{
"response_all_ref_ar_do": [
{
"ref_ar_do": [
{
"ref_do": [
{
"aid_ref_do": "ffffffffffff"
},
{
"dev_app_id_ref_do": "550f1a164ccd48d27a5ea3b765957493cd830171"
}
]
},
{
"ar_do": [
{
"perm_ar_do": {
"permissions": "0000000000000001"
}
}
]
}
]
}
]
}
]
</pre> SIMtrace 2 - Bug #5921 (In Progress): simtrace2 cardem vs. Linux kernel USB autosuspendhttps://projects.osmocom.org/issues/59212023-02-23T17:40:01Zlaforge
<p>(at least) after the following patch was merged, simtrace2-cardem doesn't work with Linux kernels' USB autosuspend anymore:<br /><pre>
commit a5d537973db9359804e82a506057f3dd6d53fab9
Author: Harald Welte <laforge@osmocom.org>
Date: Mon Jul 25 19:59:08 2022 +0200
cardem: reset the uC in case of USB disconnect
</pre></p>
<p>The problem is that the USB kernel notices the simtrace2 device is not in use (no application using it), which in turn means it will power-down the device after 5s. The device then recognizes this as USB disconnect, and we use that to reset the firmware:</p>
<pre>
=============================================================================
SIMtrace2 firmware 0.8.1.58-773d, BOARD=simtrace, APP=cardem
(C) 2010-2019 by Harald Welte, 2018-2019 by Kevin Redon
=============================================================================
-I- Chip ID: 0x299b0a60 (Ext 0x00000000)
-I- Serial Nr. 44203020-48574336-30303931-32323032
-I- Reset Cause: software reset (processor reset required by the software)
-I- USB init...
USBD_Init
SetAddr(22) -W- Sta 0x888A8 [0] -W- _ -W- Sta 0x888A8 [0] -W- _ -W- Sta 0x888A8 [0] -W- _ SetCfg(1) cfgChanged1 -I- calling configure of all configurations...
-I- calling init of config 1...
-I- Modem 0: physical SIM
-I- 0: Use local/physical SIM
-I- entering main loop...
-I- USB is now configured
-I- Resetting uC on USB disconnect
=============================================================================
SIMtrace2 firmware 0.8.1.58-773d, BOARD=simtrace, APP=cardem
(C) 2010-2019 by Harald Welte, 2018-2019 by Kevin Redon
=============================================================================
-I- Chip ID: 0x299b0a60 (Ext 0x00000000)
-I- Serial Nr. 44203020-48574336-30303931-32323032
-I- Reset Cause: software reset (processor reset required by the software)
-I- USB init...
USBD_Init
SetAddr(23) -W- Sta 0x888A8 [0] -W- _ -W- Sta 0x888A8 [0] -W- _ -W- Sta 0x888A8 [0] -W- _ SetCfg(1) cfgChanged1 -I- calling configure of all configurations...
-I- calling init of config 1...
-I- Modem 0: physical SIM
-I- 0: Use local/physical SIM
-I- entering main loop...
-I- USB is now configured
-I- Resetting uC on USB disconnect
</pre>
<p>This in turn will make the device enumerate and re-enumerate in 5s cycles:</p>
<pre>
[585591.174222] usb 1-1: new full-speed USB device number 84 using xhci_hcd
[585591.330180] usb 1-1: New USB device found, idVendor=1d50, idProduct=60e3, bcdDevice= 0.02
[585591.330216] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=11
[585591.330231] usb 1-1: Product: SIMtrace 2
[585591.330242] usb 1-1: Manufacturer: sysmocom - s.f.m.c. GmbH
[585591.330253] usb 1-1: SerialNumber: 44203020485743363030393132323032
[585594.759881] usb 1-1: USB disconnect, device number 84
[585595.530214] usb 1-1: new full-speed USB device number 85 using xhci_hcd
[585595.682690] usb 1-1: New USB device found, idVendor=1d50, idProduct=60e3, bcdDevice= 0.02
[585595.682697] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=11
[585595.682701] usb 1-1: Product: SIMtrace 2
[585595.682704] usb 1-1: Manufacturer: sysmocom - s.f.m.c. GmbH
[585595.682706] usb 1-1: SerialNumber: 44203020485743363030393132323032
[585598.802549] usb 1-1: USB disconnect, device number 85
[585602.158170] usb 1-1: new full-speed USB device number 86 using xhci_hcd
[585602.313720] usb 1-1: New USB device found, idVendor=1d50, idProduct=60e3, bcdDevice= 0.02
[585602.313757] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=11
[585602.313772] usb 1-1: Product: SIMtrace 2
[585602.313784] usb 1-1: Manufacturer: sysmocom - s.f.m.c. GmbH
[585602.313795] usb 1-1: SerialNumber: 44203020485743363030393132323032
[585606.602416] usb 1-1: USB disconnect, device number 86
</pre> libosmo-abis - Bug #5896 (Feedback): libosmo-abis built withtout --enable-e1d in deb and rpm pack...https://projects.osmocom.org/issues/58962023-02-07T11:06:06Zpespin
<p>I see there's a "--enable-e1d" which then makes libosmo-abis depend on osmo-e1d.git, but I see that not being enabled for deb nor rpm builds, the dependencies are missing there. (debian/* and contrib/*.spec.in)</p>
<p>First we need to find out whether we want to have that enabled in package repositories. Then pass --enable-e1d and update the dependencies.</p> osmo-remsim - Bug #5891 (New): bankd: potential pthread deadlock reported by coverityhttps://projects.osmocom.org/issues/58912023-02-03T19:35:22Zlaforge
<pre>
*** CID 307529: Program hangs (ORDER_REVERSAL)
/source-Osmocom/osmo-remsim/src/server/rspro_server.c: 782 in event_fd_cb()
776 }
777
778 LOGP(DMAIN, LOGL_INFO, "Event FD arrived, checking for any pending work\n");
779
780 pthread_rwlock_rdlock(&srv->rwlock);
781 llist_for_each_entry(conn, &srv->banks, list) {
>>> CID 307529: Program hangs (ORDER_REVERSAL)
>>> Calling "pthread_rwlock_rdlock" acquires lock "slotmaps.rwlock" while holding lock
"rspro_server.rwlock" (count: 2 / 5).
782 slotmaps_rdlock(srv->slotmaps);
783 non_empty_new = llist_empty(&conn->bank.maps_new);
784 non_empty_del = llist_empty(&conn->bank.maps_delreq);
785 slotmaps_unlock(srv->slotmaps);
786
787 /* trigger FSM to send any pending new/deleted maps */
</pre> osmo-e1d - Bug #5824 (Feedback): Line dead message in the log after starthttps://projects.osmocom.org/issues/58242022-12-12T20:57:41Zperformer
<p>In half cases I have next message in the log:<br /><0000> intf_line.c:95 (I0:L0) Received Only 0 bytes/s (expected: 262144): Line dead?</p>
<p>Also no traffic on client socket. Restart of e1d helps.</p> OCTOI - Osmocom Community TDM over IP - Bug #5694 (Stalled): BERT testinghttps://projects.osmocom.org/issues/56942022-10-01T06:59:48Zlaforge
<p>Soem initial tests with a PrTel93i doing BERT testing on a single B-channel indicates we have some problems to investigate.</p>
<p>This ticket serves as log of the various tests/attempts so far</p>
<ul>
<li>PrTel93i against same PrTel93i doing internal call through Auerswald COMmander2 PBX
<ul>
<li>0 errors in several 1min and 15min calls. So the PrTel and the wiring are good.</li>
</ul></li>
</ul>
<ul>
<li>PrTel93i against same PrTel93i doing external call through same PBX but going out via icE1usb to OCTOI hub and calling back through the same path:
<ul>
<li>first 1min call was with 0 errors</li>
<li>first 15min call was with 6.62 E-2 BER</li>
<li>second 15min call was with 5.92 E-2 BER</li>
<li>no lost / reordered OCTOI frames observed during that time</li>
</ul></li>
</ul>
<ul>
<li>PrTel93i against bchan_loop from capi-hacks (hfc-usb, mISDN, CAPI20) doing internal call through Auerswald COMmander2 PBX
<ul>
<li>1min call with 4.25 E-1 BER</li>
<li>so clearly there are some problems in the misdn/capi integration</li>
</ul></li>
</ul> Retronetworking - Bug #5681 (New): Figure out suitable connectors for EKSOShttps://projects.osmocom.org/issues/56812022-09-15T15:47:06Zlaforge
<p>While we did receive a few cables for EKSOS, many of them are missing, so I am looking for suitable alternative cables.</p>
<ul>
<li>EKSOS shelf DC power connector is confirmed to be a TE 350766-1 (contacts for 2.5mm2 wire: 640310-3)</li>
<li>EKSOS NCU E1 connector is <em>almost</em> a Harting 09232326824. Almost in that the clip-on frame has some notches, so the clip-on guide would have to be removed.</li>
<li>EKSOS POTS/ISDN line card subscriber line conncetor is <strong>not</strong> a typical 32pin 3-row DIN "C" connector. While both the EKSOS and this connector have pins every second position in the outer two rows, the order is exactly reversed: The standard DIN Connector has pins where EKSOS has none, and vice versa. A 64pos DIN C connector should work, assuming one then simply doesn't use every second pin present.</li>
</ul>
<p>The original manfacturer of those connectors (Perlos corporation of Joensuu, Finland) <a href="https://www.thefreelibrary.com/Finland%27s+Perlos+Corporation+sells+Special+Products+and+Connectors...-a0163748830" class="external">sold the connector business to Valuukumpu/M2 LTD in 2007</a></p>
<p><a href="https://www.cambridgeelectronics.com/DIN-41612-connectors" class="external">Cambridge Electronics</a> seems to be selling compatible connectors for at least some configurations, using seemingly the same retention lock / frame construction as featured on the EKSOS units.</p> pySim - Bug #5630 (Stalled): pySim-trace doesn't support decoding classic SIM cards (TS 11.11 / T...https://projects.osmocom.org/issues/56302022-07-24T11:06:35Zlaforge
<p>pySim-trace currently doesn't support decoding APDUs of classic SIM cards (TS 11.11 / TS 51.011) with CLA=A0.</p>
<p>I have some WIP code implementing the related ApduCommand.</p>
<p>However, there's a more critical underlying constraint in ApduCommandSet: There can only be one ApduCommand for each INS. This needs to be modified so that any number of ApduCommand can handle an INS, just as long as they each deal with their own CLA.</p> OsmoMSC - Bug #5564 (Stalled): blocking database I/O by SMS databasehttps://projects.osmocom.org/issues/55642022-05-15T14:18:42Zlaforge
<p>when OsmoMSC was split from OsmoNITB, we externalized the HLR database and removed the database-stored counters. This leaves the internal SMS queue / database code as the only remaining part of code which performs potentailly blocking disk I/O.</p>
<p>As seen in <a class="issue tracker-1 status-7 priority-3 priority-high3" title="Bug: OsmoMSC sometimes stalls for dozens of seconds in a production deployment (Stalled)" href="https://projects.osmocom.org/issues/5563">#5563</a> this is a real issue.</p>
I spent half a day on reviewing the code in detail and playing with different ideas, including
<ol>
<li>ripping out the sms_queue.c / db.c code completely into an external osmo-smsc which then uses GSUP</li>
<li>just moving db.c into a separate thread; make DB operations asynchronous</li>
<li>move sms_queue + db.c into a separate thread</li>
</ol>
<a name="moving-sms_queue-DB-code-to-new-osmo-smsc-intrfaced-via-GSUP"></a>
<h2 >moving sms_queue + DB code to new osmo-smsc, intrfaced via GSUP<a href="#moving-sms_queue-DB-code-to-new-osmo-smsc-intrfaced-via-GSUP" class="wiki-anchor">¶</a></h2>
<p>osmo-msc already contains code to do SMS via GSUP, so there's no mandatory modification to osm-msc expected in this approach.</p>
the major disadvantages of this appraoch are:
<ul>
<li>SMPP code would have to move to SMSC, and it is more tied into the MSC/VLR codebase -> extra effort</li>
<li>GSUP SMS interface is at a lower level than current sms_queue intrface -> extra effort of migrating/reimplementing that stuff in SMSC</li>
</ul>
<a name="SMS-related-VTY-commands-not-an-issue-SMSC-would-have-its-own-VTY"></a>
<h3 >SMS related VTY commands (not an issue, SMSC would have its own VTY)<a href="#SMS-related-VTY-commands-not-an-issue-SMSC-would-have-its-own-VTY" class="wiki-anchor">¶</a></h3>
<p>this would cover the following API parts</p>
<ul>
<li>sms_queue_clear</li>
<li>sms_queue_set_max_failure</li>
<li>sms_queue_set_max_pending</li>
<li>sms_queue_stats</li>
<li>sms_queue_sms_is_pending</li>
<li>sms_queue_trigger</li>
<li>vty_out</li>
</ul>
<a name="incoming-signals-into-sms_queue"></a>
<h3 >incoming signals into sms_queue<a href="#incoming-signals-into-sms_queue" class="wiki-anchor">¶</a></h3>
<ul>
<li>SS_SUBSCR / S_SUBSCR_ATTACHED
<ul>
<li>FIXME: unclear how this is handled in the GSUP case?</li>
</ul>
</li>
<li>SS_SMS / S_SMS_DELIVERED
<ul>
<li>-> gsm411_gsup_mt_fwd_sm_res()</li>
</ul>
</li>
<li>SS_SMS / S_SMS_MEM_EXCEEDED
<ul>
<li>-> gsm411_gsup_mt_fwd_sm_err()</li>
</ul>
</li>
<li>SS_SMS / S_SMS_UNKNOWN_ERROR
<ul>
<li>-> gsm411_gsup_mt_fwd_sm_err()</li>
</ul>
</li>
<li>SS_SMS / S_SMS_SUBMITTED
<ul>
<li>-> gsm411_gsup_mo_fwd_sm_req()</li>
</ul>
</li>
<li>SS_SMS / S_SMS_SMMA
<ul>
<li>-> gsm411_gsup_mo_ready_for_sm_req()</li>
</ul></li>
</ul>
<a name="DB-not-an-issue-DB-code-would-then-run-in-SMSC"></a>
<h3 >DB (not an issue, DB code would then run in SMSC)<a href="#DB-not-an-issue-DB-code-would-then-run-in-SMSC" class="wiki-anchor">¶</a></h3>
<ul>
<li>db_sms_delete_oldest_expired_message</li>
<li>db_sms_delete_sent_message_by_id</li>
<li>db_sms_get</li>
<li>db_sms_get_next_unsent_rr_msisdn</li>
<li>db_sms_get_unsent_for_subscr</li>
<li>db_sms_inc_deliver_attempts</li>
</ul>
<a name="SMS-transmission"></a>
<h3 >SMS transmission<a href="#SMS-transmission" class="wiki-anchor">¶</a></h3>
<ul>
<li>gsm411_send_sms calls by sms_queue
<ul>
<li>would have to be mapped to OSMO_GSUP_MSGT_MT_FORWARD_SM_REQUEST</li>
</ul>
</li>
<li>sms_free
<ul>
<li>FIXME: what about vsub pointer/references?</li>
</ul>
</li>
<li>vlr_subscr_msisdn_or_name
<ul>
<li>just for logging, can be avoided</li>
</ul></li>
</ul>
<a name="making-just-the-DB-code-async-run-in-separate-thread"></a>
<h2 > making just the DB code async / run in separate thread<a href="#making-just-the-DB-code-async-run-in-separate-thread" class="wiki-anchor">¶</a></h2>
Is not easy as all of the call sites are assuming synchronous return/results<br />db_sms_get
<ul>
<li>sms_resend_pending
<ul>
<li>resend_pending timer
<ul>
<li>sms_queue_start
<ul>
<li>=> can be executed from separate thread</li>
</ul></li>
</ul></li>
</ul></li>
</ul>
db_sms_get_next_unsent_rr_msisdn
<ul>
<li>smsq_take_next_sms
<ul>
<li>sms_submit_pending
<ul>
<li>sms_send_next
<ul>
<li>sms_sms_cb / S_SMS_DELIVERED
<ul>
<li>=> happens from the send_next it_Q completion handler</li>
</ul>
</li>
</ul>
</li>
<li>push_queue_timer
<ul>
<li>sms_queue_start
<ul>
<li>=> can be executed from separate thread</li>
</ul></li>
</ul></li>
</ul></li>
</ul></li>
</ul>
db_sms_get_unsent_for_subscr
<ul>
<li>sms_send_next
<ul>
<li>sms_sms_cb / S_SMS_DELIVERED
<ul>
<li>=> request to it_Q; completion then might add SMS to pending + gsm411_send_sms</li>
</ul>
</li>
</ul>
</li>
<li>sub_ready_for_sm
<ul>
<li>sms_subscr_cb / S_SUBSCR_ATTACHED
<ul>
<li>=> request to it_Q; completion then might add SMS to pending + gsm411_send_sms</li>
</ul></li>
</ul></li>
</ul>
db_sms_delete_sent_message_by_id
<ul>
<li>sms_sms_cb / S_SMS_DELIVERED
<ul>
<li>=> no return value, no success check: async it_Q</li>
</ul></li>
</ul>
db_sms_inc_deliver_attempts
<ul>
<li>sms_sms_cb / S_SMS_UNKNOWN_ERROR
<ul>
<li>=> no return value, no success check: async it_Q</li>
</ul></li>
</ul>
db_sms_delete_oldest_expired_message
<ul>
<li>sms_sms_cb / any signal
<ul>
<li>=> no return value, no success check: async it_Q</li>
</ul></li>
</ul>
<a name="moving-sms_queue-DB-code-to-separate-thread"></a>
<h2 >moving sms_queue + DB code to separate thread<a href="#moving-sms_queue-DB-code-to-separate-thread" class="wiki-anchor">¶</a></h2>
<a name="access-to-pending_sms-linked-list"></a>
<h3 >access to pending_sms linked list<a href="#access-to-pending_sms-linked-list" class="wiki-anchor">¶</a></h3>
<p>There are quite a number of accesses to the pending_sms linked list. Given most ar read, and only some are write, we might use a rwlock?</p>
<ul>
<li>sms_find_pending [R]
<ul>
<li>sms_sms_cb</li>
<li>sms_queue_sms_is_pending</li>
</ul></li>
</ul>
<ul>
<li>sms_queue_sms_is_pending [R]
<ul>
<li>sms_submit_pending
<ul>
<li>timer</li>
</ul>
</li>
<li>vty</li>
</ul></li>
</ul>
<ul>
<li>sms_subscriber_find_pending [R]
<ul>
<li>sub_ready_for_sm
<ul>
<li>SS_SUBSCR / S_SUBSCR_ATTACHED</li>
</ul>
</li>
<li>sms_subscriber_is_pending
<ul>
<li>sms_submit_pending
<ul>
<li>timer</li>
</ul>
</li>
<li>sms_send_next
<ul>
<li>sms_sms_cb / S_SMS_DELIVERED</li>
</ul></li>
</ul></li>
</ul></li>
</ul>
<ul>
<li>sms_pending_from [R]
<ul>
<li>sms_submit_pending
<ul>
<li>timer</li>
</ul>
</li>
<li>sms_send_next
<ul>
<li>sms_sms_cb / S_SMS_DELIVERED</li>
</ul></li>
</ul></li>
</ul>
<ul>
<li>sms_pending_free [W]
<ul>
<li>sms_pending_failed
<ul>
<li>sms_sms_cb / S_SMS_UNKNOWN_ERROR</li>
</ul>
</li>
<li>sms_resend_pending
<ul>
<li>sms_sms_cb / S_SMS_DELIVERED</li>
<li>sms_sms_cb / S_SMS_MEM_EXCEEDED</li>
</ul>
</li>
<li>sms_queue_clear
<ul>
<li>vty</li>
</ul></li>
</ul></li>
</ul>
<ul>
<li>sms_resend_pending [R]
<ul>
<li>timer</li>
</ul></li>
</ul>
<ul>
<li>sms_queue_stats [R]
<ul>
<li>vty</li>
</ul></li>
</ul>
<ul>
<li>sms_queue_clear [W]
<ul>
<li>vty</li>
</ul></li>
</ul>
<a name="Conclusion"></a>
<h2 >Conclusion<a href="#Conclusion" class="wiki-anchor">¶</a></h2>
I think the following approach is best:
<ul>
<li>have a separate "SMS" thread</li>
<li>all database access happens <strong>from that thread only</strong></li>
<li>inter-thread message queues (libosmocore it_q) between main thread and SMS thread</li>
<li>sms_queue timers (push_queue_timer, resend_pending_timer) run in that thread</li>
<li>other input (mainly signals today) are serialized via it_q in main -> SMS direction</li>
<li>other output (mainly gsm411_send_sms) are serialized via it_q in SMS -> main direction</li>
</ul>
<a name="Serialize-SS_SMS-signals"></a>
<h3 >Serialize SS_SMS signals<a href="#Serialize-SS_SMS-signals" class="wiki-anchor">¶</a></h3>
<ul>
<li>we really only need to serialize paging_result and sms->id</li>
<li>submit them into it_q to SMS thread</li>
</ul>
<a name="serialize-SS_SUBSCR-signal"></a>
<h3 >serialize SS_SUBSCR signal<a href="#serialize-SS_SUBSCR-signal" class="wiki-anchor">¶</a></h3>
<ul>
<li>sms_subscriber_find_pending() can be done in main thread before serialization</li>
<li>check for vsub->lu_complete and zero MSISDN before serialization</li>
<li>we really only need to serialize the MSISDN</li>
<li>db_sms_get_unsent_for_subscr() then happens from SMS thread</li>
</ul>
<a name="move-push_queue_timer-resend_pending_timer-to-SMS-thread"></a>
<h3 >move push_queue_timer + resend_pending_timer to SMS thread<a href="#move-push_queue_timer-resend_pending_timer-to-SMS-thread" class="wiki-anchor">¶</a></h3>
<a name="serialize-db_sms_store-MO-SMS-SMPP"></a>
<h3 >serialize db_sms_store() (MO-SMS, SMPP)<a href="#serialize-db_sms_store-MO-SMS-SMPP" class="wiki-anchor">¶</a></h3>
<ul>
<li>failure to store in database would only be known asynchronously!</li>
<li>we can probably just ignore that.</li>
</ul>
<a name="serialize-db_sms_mark_delivered"></a>
<h3 >serialize db_sms_mark_delivered()<a href="#serialize-db_sms_mark_delivered" class="wiki-anchor">¶</a></h3>
<ul>
<li>we don't care about success right now anyway, so async is no problem</li>
</ul>
<a name="VTY"></a>
<h3 >VTY<a href="#VTY" class="wiki-anchor">¶</a></h3>
<ul>
<li>remove 'sms send pending' or implement different command via it_Q</li>
<li>remove 'sms delete expired' or implement different command via it_Q</li>
<li>serialize 'subscriber ... sms ...' via it_Q</li>
</ul> OsmoMSC - Bug #5563 (Stalled): OsmoMSC sometimes stalls for dozens of seconds in a production dep...https://projects.osmocom.org/issues/55632022-05-14T07:02:28Zlaforge
<p>When we take a long-term (8 hours) bpftrace showing us the delay between subsequent calls to <code>poll()</code> (by libosmocore/src/select.c) in osmo-msc, we get the following histogram (units in milli-seconds):</p>
<pre>
@poll:
[0] 532245 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[1] 13088 |@ |
[2, 4) 5621 | |
[4, 8) 5566 | |
[8, 16) 2746 | |
[16, 32) 5282 | |
[32, 64) 5262 | |
[64, 128) 6139 | |
[128, 256) 14273 |@ |
[256, 512) 18357 |@ |
[512, 1K) 13806 |@ |
[1K, 2K) 4222 | |
[2K, 4K) 1331 | |
[4K, 8K) 450 | |
[8K, 16K) 0 | |
[16K, 32K) 0 | |
[32K, 64K) 5 | |
[64K, 128K) 17 | |
[128K, 256K) 2 | |
</pre>
So as we can see
<ul>
<li>the majority is very low (sub-second to 128ms)</li>
<li>there is a smaller peak in the order of 128ms to 1s (surprisingly long)</li>
<li>there are still several thousand of instances where the delay isn the 1s..4s. interval (too long!)</li>
<li>there ar rare occasions where we don't return to poll for 32, 64, or evne more than 128 seconds (crazy!)</li>
</ul>
<p>If we contrast this with the amount of time we spent in <code>dbi_conn_queryf</code>, this is clearly not the culprit:</p>
<pre>
@dbi_query:
[0] 37008 |@ |
[1] 1640233 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@|
[2, 4) 1245771 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ |
[4, 8) 21406 | |
[8, 16) 325 | |
[16, 32) 71 | |
[32, 64) 17 | |
</pre>
<p>So the longest duration DB query was in the order of 32..63 ms. Not good, but not a problem either with all the MSC (MM, CC, SMS, BSSAP, SCCP, ...) time-outs being in the multiple-second range.</p>
<p>So now we have to find out if the stalls are</p>
<ol>
<li>due to excessive system load (like I/O) outside of osmo-msc, or</li>
<li>due to something osmo-msc is doing by itself (like calling thousands of database queries of several milli-seconds each) without going through the libosmocore poll main loop.</li>
</ol> OsmoMSC - Bug #5559 (Stalled): OsmoMSC at 100% CPU and unresponsive for up to several minutes!https://projects.osmocom.org/issues/55592022-05-12T23:22:09Zkeith
<p>Not much more to say than the title I'm afraid.</p>
<p>So far, I've actually only noticed it on a system using the RBS and osmo-e1d. But I do not have conclusive proof that it is exclusively happening here.</p>
<p>I'm assuming a culprit might be the sms queue, but I'm not convinced because I'm not seeing it on other systems with more messages in the queue in the sqlite db - and this can be upwards of 1,000 SMS queued.</p> osmo-remsim - Bug #5527 (Stalled): warn on duplicate client (id) connectionshttps://projects.osmocom.org/issues/55272022-04-12T17:37:27Zlaforge
<p>Every client must have its own unique tuple of (client_id/slot_nr).</p>
<p>If a remsim-server receives a duplicate connection, it should pring a clear warning message to the log.</p>
<p>This might not always be a bug, as in csae of network outages / restarts a new connection might arrive before the old one is closed.</p>
<p>The same should apply to remsim-bankd.</p> SIMtrace 2 - Bug #5464 (In Progress): cardem firmware unable to attach to cardhttps://projects.osmocom.org/issues/54642022-02-21T19:07:57Zk_o_
<p>I'm using a Nexus 5 phone. I have a permanent problem that the remote SIM cannot be attached. I always see several RESETs after the phone is restarted. The trace firmware together with the command line works. The adapter cable is in a prepared SIM tray and works. What could be the issue?</p>
<pre>
simtrace2-cardem-pcsc --usb-vendor 1d50 --usb-product 60e3 --usb-path 2-1.4 --usb-config 1 -n 2
simtrace2-cardem-pcsc - Using PC/SC reader as SIM
(C) 2010-2020, Harald Welte <laforge@gnumonks.org>
(C) 2018, sysmocom -s.f.m.c. GmbH, Author: Kevin Redon <kredon@sysmocom.de>
<0002> simtrace2_api.c:267 [0] <= osmo_st2_cardem_request_config(features=00000001)
<0002> simtrace2_api.c:168 [0] <= osmo_st2_cardem_request_card_insert(inserted=1)
<0002> simtrace2_api.c:317 [0] <= _modem_sim_select(remote_sim=1)
<0002> simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 9f 96 80 1f c7 80 31 e0 73 f6 21 13 67 56 03 27 00 89 01 02 28 )
<0002> simtrace2_api.c:284 [0] <= _modem_reset(asserted=2, pulse_ms=300)
Entering main loop
-> 01 08 00 00 00 00 0d 00 01 00 00 00 00
SIMtrace IRQ 01 04 00 00 00 00 15 00 00 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x0, fi=1, di=1, wi=10 wtime=9600 ()
SIMtrace IRQ 01 04 00 00 00 00 15 00 10 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x10, fi=1, di=1, wi=10 wtime=9600 (RESET )
SIMtrace IRQ 01 04 00 00 00 00 15 00 00 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x0, fi=1, di=1, wi=10 wtime=9600 ()
SIMtrace IRQ 01 04 00 00 00 00 15 00 10 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x10, fi=1, di=1, wi=10 wtime=9600 (RESET )
</pre> SIMtrace 2 - Bug #5419 (Stalled): cardem errors with higher baud ratehttps://projects.osmocom.org/issues/54192022-01-25T18:27:00Zlaforge
Setup is as follows:
<ul>
<li>sysmoISIM-SJA2 in built-in CCID reader of my Thinkpad x260</li>
<li>SIMtrace2 with cardem firmware 'master' (0.8.1.7-ea9a) hooked up via FPC to</li>
<li>CCID reader "Identive CLOUD 2700 F" </li>
<li><code>simtrace2-cardem-pcsc</code> to forward request from IdentiveCCID -> SIMtrace -> st2-cardem-pcsc -> builtin-CCID</li>
</ul>
<p>This works fine with F/D ratio 372, and also works fine in most cases with F/D ratio 16.</p>
<p>However, sometimes with ratio 16, things break down at some point.</p>
<a name="log-output-of-cardem-firmware"></a>
<h2 >log output of cardem firmware<a href="#log-output-of-cardem-firmware" class="wiki-anchor">¶</a></h2>
<pre>
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 9d 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 9e 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 9f 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 b2 a0 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
-I- 0: send_tpdu_header: 00 c0 00 00 23
-I- 0: flush_rx_buffer (5)
N-I- 0: send_tpdu_header: 00 b2 a1 04 22
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 00 a4 00 04 02
-I- 0: flush_rx_buffer (5)
-I- 0: flush_rx_buffer (2)
N-I- 0: send_tpdu_header: 00 c0 00 00 60
-I- 0: flush_rx_buffer (5)
-I- 0: send_tpdu_header: 02 00 a4 00 04
-I- 0: flush_rx_buffer (5)
</pre>
two things noticable:
<ul>
<li>the 'N' being printed by card_emu as waiting time extension</li>
<li>the last TPDU header <code>02 00 a4 00 04</code> doesn't look like a TPDU header: The 02 seems wrong, the TPDU likely starts with <code>00 a4</code>.</li>
</ul>
<a name="situation-on-Identive-CCID-reader-side"></a>
<h2 >situation on "Identive CCID reader" side<a href="#situation-on-Identive-CCID-reader-side" class="wiki-anchor">¶</a></h2>
<p>pySim-shell "export" shows:<br /><pre>
update_record 159 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
update_record 160 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
update_record 161 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
# bad file: MF/DF.TELECOM/EF.ADN, Failed to transmit with protocol T0. Transaction failed.
EXCEPTION of type 'RuntimeError' occurred with message: '6881: Functions in CLA not supported - Logical channel not supported'
To enable full traceback, run the following command: 'set debug true'
</pre></p>
<a name="simtrace2-cardem-pcsc"></a>
<h2 >simtrace2-cardem-pcsc<a href="#simtrace2-cardem-pcsc" class="wiki-anchor">¶</a></h2>
<pre>
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 9d 04 22
=> DATA: flags=1, 00 b2 9d 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 9e 04 22
=> DATA: flags=1, 00 b2 9e 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 9f 04 22
=> DATA: flags=1, 00 b2 9f 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 a0 04 22
=> DATA: flags=1, 00 b2 a0 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 23
=> DATA: flags=1, 00 c0 00 00 23 : SW=0x9000, len_rx=35
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 b2 a1 04 22
=> DATA: flags=1, 00 b2 a1 04 22 : SW=0x9000, len_rx=34
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 a4 00 04 02
=> DATA: flags=1, 00 a4 00 04 02 : -> 01 06 00 00 00 00 10 00 02 00 00 00 02 00 6f 3a
=> DATA: flags=2, 6f 3a : SW=0x6123, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 00 c0 00 00 60
=> DATA: flags=1, 00 c0 00 00 60 : SW=0x6c23, len_rx=0
-> 01 06 00 00 00 00 13 00 01 00 00 00 05 00 02 00 a4 00 04
<0000> apdu_dispatch.c:112 Unknown APDU case 0
=> DATA: flags=1, 02 00 a4 00 04 : SW=0x6881, len_rx=0
</pre>
<p>it also agrees that this last APDU is somehow wrong and cannot determine the APDU case.</p>
<a name="USB-communication"></a>
<h2 >USB communication<a href="#USB-communication" class="wiki-anchor">¶</a></h2>
<p>last message from SIMtrace to host is "RX DATA" with header flag set and 0200a40004. The card still responds with SW 6881 to that, as obviously the APDU header is invalid.</p>
<p><img src="https://projects.osmocom.org/attachments/download/4852/wireshark.png" alt="" /></p> erlang/osmo_ss7 - Bug #5378 (New): ipa: add support for client applicationhttps://projects.osmocom.org/issues/53782021-12-30T19:23:19Zlynxis
<p>The osmo_dia2gsup is using the ipa module.<br />The ipa module is sending an "Identity Request" after the connection is established. The osmo-hlr will treat this early identity request as invalid and will never answer to it.</p>
<pre>
diff --git a/src/ipa_proto.erl b/src/ipa_proto.erl
index ceb024a..1a6ca4f 100644
--- a/src/ipa_proto.erl
+++ b/src/ipa_proto.erl
@@ -120,10 +120,6 @@ request({ipa_set_ccm_options, Socket, CcmOptions}, _) ->
{ccm_options, CcmOptions};
% server-side handler for unblock()
request({ipa_unblock, Socket}, CcmOptions) ->
- if
- CcmOptions#ipa_ccm_options.initiate_ack -> send_ccm_id_ack(Socket);
- true -> send_ccm_id_get(Socket)
- end,
io:format("Unblocking socket ~p~n", [Socket]),
%[IpaSock] = ets:lookup(ipa_sockets, Socket),
Ret = inet:setopts(Socket, [{active, once}]),
</pre> osmo-e1d - Bug #4916 (Stalled): USB unplug / replug renders e1d unusablehttps://projects.osmocom.org/issues/49162020-12-18T10:28:45Zlaforge
right now the behavior on USB unplug (or - god forbid - a firmware crash) is not very user friendly:
<ul>
<li>e1d keeps running</li>
<li>e1d does not re-open the device when it comes back</li>
</ul>
IMHO, we have the following options
<ol>
<li>fail fast - simply exit when the device is lost, assume systemd or some other management instance will keep respawning us until the device is back
<ul>
<li>but what about client programs like osmo-bsc / osmo-mgw ?</li>
</ul>
</li>
<li>implement re-opening of a single icE1usb device, knowing our blocking control transfers would corrupt any other ongoing communication
<ul>
<li>is it worth the effort, assuming this is only an interim solution</li>
</ul>
</li>
<li>go for a full-blown hot-plug capable architecture lined out in <a class="issue tracker-2 status-1 priority-1 priority-lowest" title="Feature: consider a one-thread-per-line architecture (New)" href="https://projects.osmocom.org/issues/4915">#4915</a>
<ul>
<li>will probably take significant effort</li>
</ul></li>
</ol>
<p>I think right now we mostly have to worry about situations with a single icE1usb, so I'm tempted to go for the fail-fast approach, assuming osmo-bsc/osmo-mgw recover in some way.</p> OsmocomBB - Bug #4829 (Stalled): OsmocomBB Rx bit errors in dedicated modehttps://projects.osmocom.org/issues/48292020-10-24T03:09:38Zlaforge
<p>I'm observing quite a number of bit errors when receiving in dedicated mode.</p>
<p>Those bit errors are not present while in receive-only mode (CCCH/BCCH camping.</p>
<p>The bit errors can be observed on SDCCH/4, SDCCH/8 and TCH/F (didn't try TCH/H).</p>
<p>I've tried to roll back to old OsmocomBB firmware versions as old as 2012 (using old gnuarm-4.0.x toolchain) - the problem even exists in those old versions, so it doesn't look like a regression.</p>
<p>I've tested with perfect RF signals (coaxial connection via attenuators) to exclude any real-world impact.</p>
<p>I've tested both with sysmoBTS 1002 as well as with a commercial cellular network.</p>
<p>I've tested with C118, C121, C123 and C140.</p>
<p>In all situations, the problem persists and looks like this:</p>
<p>Camping with good signal level 0 BER / fire_crc = 2<br /><pre>
<000c> l1ctl.c:237 BCCH on TS0 (0301/13/02) -56 dBm 0/0: 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00
<000c> l1ctl.c:237 PCH/AGCH on TS0 (0301/17/06) -56 dBm 0/0: 03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
<000c> l1ctl.c:237 PCH/AGCH on TS0 (0301/23/12) -56 dBm 0/0: 15 06 21 00 01 f0 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
<000c> l1ctl.c:237 PCH/AGCH on TS0 (0301/01/16) -56 dBm 0/0: 2d 06 3f 03 41 e3 67 00 68 8f 00 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
</pre></p>
<p>Once switched to dedicated channel:<br /><pre>
<000c> l1ctl.c:237 SDCCH/8(0) on TS1 (0301/10/00) -56 dBm 0/0: 03 03 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b
<000c> l1ctl.c:237 SDCCH/8(0) on TS1 (0301/16/32) -56 dBm 66/2: a3 4b 33 0a 38 66 2a a4 57 cc 2e db 60 f7 e2 7e 9e cd ac d8 ee dc bd
<000c> l1ctl.c:300 Dropping frame with 66 bit errors
<000c> l1ctl.c:237 SDCCH/8(0) on TS1 (0301/09/00) -56 dBm 74/2: a3 35 0f 0a b8 79 13 2a 6b 5e c2 da 60 f7 e2 7e 9e cd ac d8 ee dc fd
<000c> l1ctl.c:300 Dropping frame with 74 bit errors
<000c> l1ctl.c:237 SDCCH/8(0) on TS1 (0301/08/00) -56 dBm 82/2: a3 35 0f 14 f1 f7 17 aa 57 cc 2e 12 67 f7 e2 7e 9e cd ac d8 7e 29 85
<000c> l1ctl.c:300 Dropping frame with 82 bit errors
<000c> l1ctl.c:237 SDCCH/8(0) on TS1 (0301/14/32) -56 dBm 77/2: a3 4b 33 0a 38 66 2a a4 57 cc 2e 92 44 f8 e2 7e 9e cd ac d8 fe 85 2f
<000c> l1ctl.c:300 Dropping frame with 77 bit errors
<000c> l1ctl.c:237 SDCCH/8(0) on TS1 (0301/07/00) -56 dBm 74/2: a3 4b 33 0a 38 66 2a 24 6b 5e c2 da 60 f7 e2 7e 9e cd ac d8 fe 85 2f
<000c> l1ctl.c:300 Dropping frame with 74 bit errors
</pre></p>
<p>so as we can see, he very first block is still received well, all other blocks have massive bit errors (typically in he 70..95 erroneous bit range)</p>
<p>Playing with the source code I could narrow it down to whether or not we are enabling the PA in the <code>rffe_mode()</code> function by means of <code>tspact | PA_ENABLE</code></p>
<p>If I enable the PA only for RACH / access burst, but not for any normal bursts, the SDCCH bit errors are not reported anymore.</p>
<p>I've played a lot with l1s_tx_win_ctrl in terms of ordering, etc. but the problem persists.</p>
<p>It cannot be a general scheduling problem, as the TX window duration is not affected by whether or not we enable the PA. There are just as many TPU instructions etc. even without that one bit.</p> OsmoBSC - Bug #4683 (New): properly report OM2000 bring-up problemshttps://projects.osmocom.org/issues/46832020-07-30T06:50:59Zlaforge
<p>If there is a mismatch between hardware or IDB configuration and the osmo-bsc configuration, the OM2000 bring-up will fail in various ways. This is not clearly visible at the moment, and in many situations the user will not be aware that anything has been going wrong. In some situations RSL will simply never be initialized successfully - in some other situations even RSL comes up without errors, but the RBS simpyl doesn't transmit.</p>
The most important indications we get from the RBS:
<ul>
<li>some Enable Result, particularly on the TX or TRXC, <em>not according to request</em>, optionally with information which IE is causing the problem</li>
<li>Failure Maps</li>
</ul>
Let's make sure that
<ul>
<li>the related errors are logged at ERROR level (in human-readable form)</li>
<li>the state of the MO is easily available via introspection/VTY</li>
<li>we document how to deal with this in the user manual or wiki</li>
</ul> OsmoSGSN - Bug #4599 (New): counter group sgsn:pdpctx already exists for index X, instead using Yhttps://projects.osmocom.org/issues/45992020-06-08T18:05:33Zlaforge
<p>When using OsmoSGSN (current nightly) in a setup with 3rd party 2G BSS and 3G RAN, we are running quite often into the following error message:</p>
<pre>
<0020> rate_ctr.c:224 counter group 'sgsn:pdpctx' already exists for index 5, instead using index 8. This is a software bug that needs fixing.
</pre>
<p>I wonder how this happens. It basically means we want to allocate a PDP context for the same NSAPI where we already have a PDP context.</p>
<p>The only path that calls sgsn_pdp_ctx_alloc() is sgsn_create_pdp_ctx() via activate_ggsn() originating from do_act_pdp_req() and the latter actually chekcs if we already have a PDP context fro the NSAPI in sgsn_pdp_ctx_by_nsapi. weird.</p>
<p><a class="user active" href="https://projects.osmocom.org/users/1741">lynxis</a> any ideas?</p> Cellular Network Infrastructure - Bug #4578 (New): Updated slides / presentations / videos on set...https://projects.osmocom.org/issues/45782020-06-03T14:56:52Zlaforge
<p>I just realized that since OsmoCon was discontinued after 2018 didn't result in sufficient turn-out, and only the 2017 incarnation contained some entry-level talks, we actually only have introductory level presentations / videos about a setup that still covers OsmoNITB. (<a class="external" href="https://media.ccc.de/v/osmocon17-4002-running_a_basic_circuit_switched_osmocom_gsm_network">https://media.ccc.de/v/osmocon17-4002-running_a_basic_circuit_switched_osmocom_gsm_network</a>)</p>
<p>This may or may not be a reason why some people still want to set up OsmoNITB in 2020. While our wiki and user manuals all have deprecated OsmoNITB years ago, people who only look for videos might be mislead.</p>
<p>Also, I'm sure that several other presentation (like the one about 3G / osmo-iuh before the CNI split) would similarly benefit from an update.</p>
<p>So I think we should try to create/update some slide decks and record related lectures / tutorials at some point this year. I wouldn't bother setting up a virtual conference or some kind of remote interaction at this point. Recording some talks and/or screencasts allows us to create and release them one-by-one.</p>
<p>Let's use this issue to first collect a list of topics that we think either need an update, or topics that never have been covered so far.</p> libosmo-abis - Bug #4464 (In Progress): "osmo_rtp_socket_poll(): ERROR!" messages during normal o...https://projects.osmocom.org/issues/44642020-03-20T21:11:03Zlaforge
<p>When using osmo-bts-trx and establishing voice calls, I get lots of those osmo_rtp_socket_poll() ERROR messages when a TCH/F is established but voice is not yet conncted (i.e. while dialing, until the call is fully established):</p>
<pre>
NOTICE <0000> rsl.c:813 (bts=0,trx=0,ts=1,pchan=TCH/F) (ss=0) TCH_F Tx CHAN ACT ACK
INFO <000e> rsl.c:2122 (bts=0,trx=0,ts=1,ss=0) IPAC set RTP socket parameters: 1
INFO <0015> trau/osmo_ortp.c:0 RtpSession bound to [127.0.0.1] ports [16396] [16397]
INFO <0015> trau/osmo_ortp.c:449 osmo_rtp_socket_connect() refused to set remote 127.0.0.1:0
INFO <0015> trau/osmo_ortp.c:0 RtpSession [0x5607c73cc9d0] sending to rtp 192.168.103.248:4116 rtcp 192.168.103.248:4117
INFO <0015> trau/osmo_ortp.c:0 First estimation
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(0): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(160): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(320): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(480): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(640): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(800): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(960): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(1120): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(1280): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(1440): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(1600): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(1760): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(1920): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(2080): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(2240): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(2400): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(2560): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(2720): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(2880): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(3040): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(3200): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(3360): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(3520): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(3680): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(3840): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4000): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4160): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4320): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4480): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4640): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4800): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(4960): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(5120): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(5280): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(5440): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(5600): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(5760): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(5920): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(6080): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(6240): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(6400): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(6560): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(6720): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(6880): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(7040): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(7200): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(7360): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(7520): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(7680): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(7840): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(8000): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(8160): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(8320): ERROR!
INFO <0015> trau/osmo_ortp.c:206 osmo_rtp_socket_poll(8480): ERROR!
</pre>
<p>Looking at the code, this is actually not an error as such (it's also LOGL_INFO). It merely tells us that we tried to poll for an incoming RTP packet, and there was none received since our last call.</p>
<p>We should probably either remove it completely, or turn it to 'DEBUG' and remove the 'ERROR' from the messate. Or we simply replace it with a counter?</p> SIMtrace 2 - Bug #4430 (New): firmware can get in endless out-of-memory loop on OUT EP floodhttps://projects.osmocom.org/issues/44302020-03-01T15:06:25Zlaforge
<p>When flooding the OUT EP with too many messages, the firmware can get into an OOM situation from which it doesn't recover anymore. All it will do is print the below messages:</p>
<pre>
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
</pre>
<p>I'm currently reproducing this with a test case that sends 1000 bogus OUT EP transfers to the device.</p> libosmocore - Bug #4149 (New): osmo_fsm allows event names to have spaces in themhttps://projects.osmocom.org/issues/41492019-08-13T10:58:36Zlaforge
<p>See <a class="external" href="https://gerrit.osmocom.org/#/c/libosmocore/+/15154/">https://gerrit.osmocom.org/#/c/libosmocore/+/15154/</a></p>
<p>event names, like state names, should be one word <strong>only</strong>.</p> OsmoBTS - Bug #3568 (Stalled): CBCH on SDCCH/8 not working for osmo-bts-sysmohttps://projects.osmocom.org/issues/35682018-09-18T20:54:03Zlaforge
<p>During manual testing I observed that while sms arrived on my test phone when using CBCH on SDCCH/4, they were not arriving when using CBCH on SDCCH/8.</p>
<p>SI4 CBCH location was updated properly, so that was not the cause...</p> SIMtrace 2 - Bug #3379 (Stalled): documentation on how to use SIMtrace2https://projects.osmocom.org/issues/33792018-07-04T16:10:36Zlaforge
<p>the wiki in the SIMtrace2 redmine project currently only documents flashing, but there should of course be good information on how to use the host tools in order to run the complete system.</p> libosmocore - Bug #1762 (New): Review LAPD code for race conditions regarding state, particularly...https://projects.osmocom.org/issues/17622016-07-03T20:20:39Zlaforge
<p>See <a class="issue tracker-1 status-5 priority-2 priority-default closed" title="Bug: LAPD: segfault in T200 call-back (Closed)" href="https://projects.osmocom.org/issues/1760">#1760</a> and <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: LAPD: segfault when bootstrapping Nokia InSite (Resolved)" href="https://projects.osmocom.org/issues/1761">#1761</a>, there are quite some problems that apparently need a more thorough review and/or testing.</p>
<p>Maybe implementing (part of?) the Q.921bis LAPD conformance tests might be an option to catch all of those kind of bugs?</p>
<p>See <a class="external" href="https://www.itu.int/rec/T-REC-Q.921bis-199303-I/en">https://www.itu.int/rec/T-REC-Q.921bis-199303-I/en</a></p> SIMtrace 2 - Bug #1705 (Stalled): re-integrate tracing + card reader modes into SIMtrace2 firmwar...https://projects.osmocom.org/issues/17052016-05-09T19:46:30Zlaforge
<p>the current laforge/cardemu branch breaks sim card tracing + card reader modes. Re-integrate and test those to have one firmware image working in all modes</p>