Open Source Mobile Communications: Issueshttps://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092023-12-06T14:31:01ZOpen Source Mobile Communications
Redmine 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> OCTOI - Osmocom Community TDM over IP - Feature #6246 (New): co-locate cisco 2811 for FrameRelay...https://projects.osmocom.org/issues/62462023-11-06T13:48:35Zlaforge
<p>let's put a Cisco 2811 into the co-location, ideally with support for both X.25 as well as FrameRelay.</p>
<p>The idea would be to use it as basis for interop testing any Linux/FOSS work on X.25/framerelay routing/switching that would happen on the OCTOI hub.</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> Retrocomputing - Feature #5947 (New): Assemble PC104-SVGAhttps://projects.osmocom.org/issues/59472023-03-15T09:29:21Zlaforge
<p><a class="external" href="https://github.com/monotech/PC104-SVGA">https://github.com/monotech/PC104-SVGA</a></p> Retrocomputing - Feature #5940 (New): Assemble LPT_Capturehttps://projects.osmocom.org/issues/59402023-03-06T16:42:08Zlaforge
<p><a class="external" href="https://github.com/bkw777/LPT_Capture">https://github.com/bkw777/LPT_Capture</a></p> Retrocomputing - Bug #5939 (In Progress): Assemble GraphicGremlin / isavideohttps://projects.osmocom.org/issues/59392023-03-06T16:39:24Zlaforge
<p><a class="external" href="https://github.com/schlae/graphics-gremlin">https://github.com/schlae/graphics-gremlin</a></p> Retrocomputing - Feature #5938 (In Progress): assemble "fake parallel printer"https://projects.osmocom.org/issues/59382023-03-06T16:33:11Zlaforge
<p>This will be useful for generating digital captures of e.g. the traces generated by <a class="wiki-page" href="https://projects.osmocom.org/projects/retronetworking/wiki/Wandel_Goltermann_DTX-1">Wandel_Goltermann_DTX-1</a>.</p>
<p><a class="external" href="https://github.com/tomverbeure/fake_parallel_printer">https://github.com/tomverbeure/fake_parallel_printer</a></p> Retrocomputing - Feature #5936 (New): Assemble netpi-idehttps://projects.osmocom.org/issues/59362023-03-02T19:20:56Zlaforge
<p><a class="external" href="https://www.retrotronics.org/home-page/netpi-ide/">https://www.retrotronics.org/home-page/netpi-ide/</a></p>
<p><a class="external" href="https://www.retrotronics.org/svn/jride/trunk/">https://www.retrotronics.org/svn/jride/trunk/</a></p> Retrocomputing - Feature #5934 (In Progress): Assemble Pico-GUShttps://projects.osmocom.org/issues/59342023-03-02T18:50:05Zlaforge
<p><a class="external" href="https://github.com/polpo/picogus">https://github.com/polpo/picogus</a></p> Retrocomputing - Feature #5933 (In Progress): Assemble XT-CF-Lite v4.1https://projects.osmocom.org/issues/59332023-03-02T18:15:17Zlaforge
<p><a class="external" href="http://www.malinov.com/Home/sergeys-projects/xt-cf-lite">http://www.malinov.com/Home/sergeys-projects/xt-cf-lite</a></p> Retrocomputing - Feature #5932 (New): assemble ISA-USBhttps://projects.osmocom.org/issues/59322023-03-02T17:28:00Zlaforge
<p><a class="external" href="https://www.lo-tech.co.uk/wiki/Lo-tech_ISA_USB_Adapter">https://www.lo-tech.co.uk/wiki/Lo-tech_ISA_USB_Adapter</a></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> OsmoHLR - Feature #5865 (New): Automate selection of LU Reject Causehttps://projects.osmocom.org/issues/58652023-01-20T13:59:07Zkeith
<p>There is some suggestion in <a class="external" href="https://gerrit.osmocom.org/c/osmo-hlr/+/16808">https://gerrit.osmocom.org/c/osmo-hlr/+/16808</a> that osmo-hlr could use some criteria to decide what cause/reason to send to the GSUP client when rejecting a Location/Routing Update</p>
<p>Possibly, sending "IMSI Unknown in HLR" is wrong when the SIM is foreign to our network.</p>
<p>We could have a regex config option to let osmo-hlr know what is "our" SIM or not. Or maybe a GSUP client like osmo-msc can comunicate MNC-MCC info from the MSC network config over GSUP? I'm not familiar with GSUP.</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> 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> OCTOI - Osmocom Community TDM over IP - Feature #5437 (New): brainstorm about making protocol eve...https://projects.osmocom.org/issues/54372022-01-30T13:40:54Zlaforge
<p>Right now in the PoC protocol of <code>laforge/e1oip</code> we still send something in the order of 8000/(32..40) = 200 .. 250 UDP packets per second even if there are no active timeslots at all.</p>
This really only serves the following purpose:
<ul>
<li>theoretical ability for a receiver without GPS-DO (client) to re-construct timing based on the averaged recorvered packet timing</li>
<li>ability of receiver to quickly detect lost frames (network problems or the like)</li>
<li>keep-alive of any NAT mapping/bindings</li>
</ul>
<p>But at least in the current icE1usb hardware with GPS-DO, timing recovery is not really needed. And whether or not it is required to detect outages as fast as 50ms after they happen is somewhat disputable.</p>
<p>So why not introduce a mode in which we suppress idle packet transmission even further? For example, if we went down into a "1 PPS" mode during periods of quiescence, we would drastically reduce the network load / bandwith use, while still providing the peer to determine the alive-status of the network connection. Basically something like DTX (discontinuous transmission) in GSM, where transmissions are reduced to the SACCH only, if no [voice] activity is detected.</p>
<p>Any kind of alarms (TS0 processing) could of course trigger instantaneous transmission of packets.</p>
<p>Am I missing something here?</p> OCTOI - Osmocom Community TDM over IP - Feature #5436 (New): BRI variant of OCTOI protocolhttps://projects.osmocom.org/issues/54362022-01-30T13:33:09Zlaforge
<p>right now the protocol is rather E1-centric, or at least assuming that timeslots always have the same bitrate.</p>
For BRI we have
<ul>
<li>2x64k B-channels (exposed to the user)</li>
<li>1x16k D-channel (exposed to the user)</li>
<li>additional management channels (not exposed to the user, normally handled in the NT)</li>
</ul>
<p>We need to find a way to express BRI in our protocol.</p>
<p>Misc note: DAHDI exposes the 2xB+1xD as three channels. Not sure if the D-channel runs at a non-8kHz rate, or if it simply only uses 2 bits of every byte?</p>
<p>The header/packet protocol overhead of course becomes even higher (proportionally) compared to PRI.</p> OCTOI - Osmocom Community TDM over IP - Feature #5429 (New): authentication in TDMoIP protocolhttps://projects.osmocom.org/issues/54292022-01-30T10:42:43Zlaforge
<p>We need at least some minimalistic form of authentication to identify users/peers. Authentication must be challenge-response based, so that related credentials are never transmitted over the network.</p>
<p>Authentication should also be mutual. However, without integrity protection or encryption, this will of course not prevent against any type of MITM.</p> SIMtrace 2 - Feature #5422 (In Progress): "cardem" continuous testing setuphttps://projects.osmocom.org/issues/54222022-01-27T12:22:10Zlaforge
<p>We shuold create a test setup where we can continously test the <code>cardem</code> firmware for the various targets, such as at least simtrace2 and qmod.</p>
<p>The idea would be to use the TTCN3 test ports for SIMTRACE USB protocol on the one hand side and CCID USB protocol on the other hand side.</p>
<p>Tests should ideally not just test interop with one specific CCID reader model but with a larger number of different readers to cover reader-specific issues (I'm seeing different issues with different readers in manual testing).</p>
<p>The tests can then be executed with the latest cardem firmware of the day, on different IUT hardware (simtrace2, qmod) against different readers.</p>
For QMOD testing we would have to either
<ul>
<li>insert a modem with CCID capability (they do exist)</li>
<li>use a custom PCB adapter or some solder wire to hook up the SIM traces of the mCPIE sockets with some external reader</li>
</ul>
<p>But let's focus on simtrace2 for the initial setup, and then expand from there.</p> OsmoCBC - Feature #4944 (New): 3G SABP support in OsmoCBChttps://projects.osmocom.org/issues/49442021-01-13T09:09:23Zlaforge
<p>Currently, OsmoCBC only supports 2G/GSM using the CBSP protocol.</p>
<p>This ticket is about supporting 3G/UMTS support via the SABP protocol towards the RNC/HNB-GW</p> osmo-clock-conv - Feature #4809 (New): alignment of DC barrel with face platehttps://projects.osmocom.org/issues/48092020-10-15T21:54:33Zlaforge
<p>this way we could have a circular drill hole in the face plate, rather than the rectangular cut-out.</p> libosmocore - Feature #4727 (Feedback): Add more distro/platform/archs to jenkins CIhttps://projects.osmocom.org/issues/47272020-08-25T14:18:29Zpespin
<p>Currently we rely on OBS to run unit test software on several architectures/distributions/versions. However, OBS hosts lack some features which means we need to disable them when we run there (such as socket_sctp_test), and hence only get tested mostly only in x86_64 on one debian version.</p>
<p>That means we don't test such features in ARM, or in Ubuntu or CentOS, or debian unstable.</p> OsmoBSC - Feature #4650 (New): Add BIG FAT error message in case OM2000 BTS fail to start uphttps://projects.osmocom.org/issues/46502020-07-04T19:30:38Zlaforge
<p>I was using the internal XO of a Digium DAHDI E1 card while tryign to bring up my RBS2308, and failed for multiple days to do so.</p>
Intrestingly, the TF ca nbe fully broguht up (enabled / operational), but the failure shows in a very weird way:
<ul>
<li>The TX ENABLE RESULT shows <em>MO State: DISABLED</em> and points to the <em>Attribute Idnetifier: ARFCN TX</em></li>
</ul>
<p>This is completely misleading, as the ARFCN number is fully acceptable - it's just that the TRX refuses to come up while timing is not precise.</p>
<p>The only other thing that shows up in a trace is a <em>TF Fault Report</em> with <em>External Condition Map Class 1: 0300</em>.</p>
<p>We should print very descriptive error messags on either of those two events to make sure other people realize that all they have is a bad E1 clock.</p>
<p>(the way how I fixed it is to use a SIU slaved to GPS 1PPS which feeds the clock into one of the 4ports of a Digium Quad-E1, which then uses that port as clock source)</p> OsmoBSC - Bug #4614 (Stalled): "bogus channel load sample" when using BS-11, Nokia or Ericsson BTShttps://projects.osmocom.org/issues/46142020-06-15T13:47:09Zlaforge
<pre>
Mon Jun 15 15:36:12 2020 DRLL chan_alloc.c:208 (bts=0) bogus channel load sample (used=0 / total=0)
Mon Jun 15 15:36:13 2020 DRLL chan_alloc.c:208 (bts=0) bogus channel load sample (used=0 / total=0)
</pre>
<p>Also, interestingly:<br /><pre>
OsmoBSC> show trx
TRX 0 of BTS 0 is on ARFCN 121
Description: (null)
RF Nominal Power: 24 dBm, reduced by 0 dB, resulting BS power: 24 dBm
NM State: Oper 'NULL', Admin 'Unlocked', Avail 'Power off'
RSL State: connected
Baseband Transceiver NM State: Oper 'NULL', Admin 'unknown 0x0', Avail 'Power off'
E1 Signalling Link:
E1 Line 2, Type dahdi: Timeslot 1, Mode RSL
E1 TEI 1, SAPI 0
</pre></p>
<p>I think the problem is that the Siemens BS-11 MO structure is quite unlike what TS 12.21 describes, so the baseband transceiver object is simply never initialized.</p>
<p>The " OC=<abbr title="a5">SIEMENSHW</abbr> INST=(03,00,00)" might be can idea?</p> libosmo-sccp + libosmo-sigtran - Feature #4608 (New): "action" commands to interactively shutdown...https://projects.osmocom.org/issues/46082020-06-10T13:12:24Zlaforge
<p>would be great to do that, especially for testing/debugging.</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> osmo-remsim - Feature #4249 (New): ability to explicitly provision an "empty SIM card slot" to a ...https://projects.osmocom.org/issues/42492019-11-07T14:21:12ZlaforgeOsmoBSC - Feature #1946 (New): Add checks to the BSC VTY to prevent configurations known to not workhttps://projects.osmocom.org/issues/19462017-02-08T23:41:53Zneelsnhofmeyr@sysmocom.de
<p>e.g. running TCH/F_TCH/H_PDCH timeslots on a nanobts doesn't work,<br />similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR),<br />and so on.</p> osmo-qcdiag - Feature #1908 (New): add VTY interface to osmo-qcdiaghttps://projects.osmocom.org/issues/19082017-01-11T12:24:21Zlaforge
The VTY interface should
<ul>
<li>allow enabling/disabling of LOG, MSG, EVENT codes</li>
<li>allow inquiry for supported LOG / MSG / EVENTs in the target</li>
<li>allow inquiry about version information of target</li>
<li>allow configuration of GSMTAP destination IP/port</li>
<li>allow configuration of GSMTAP format, like
<ul>
<li>raw DIAG forwarding like implemented now</li>
<li>GSMTAP forwarding of radio/OTA messages only</li>
<li>combined mode where radio/OTA messages are forwarded as DIAG, but MSG (text messages) are sent as GSMTAP LOG</li>
</ul></li>
</ul> SIMtrace 2 - Feature #1463 (New): Add VCC current sensing circuit for SPA & DPA attackshttps://projects.osmocom.org/issues/14632016-02-19T22:48:42Z
<p>It would be pretty good to be able to sense current going to the SIM.</p>
<p>The simple idea is to measure current like this :</p>
<pre>
A B
o o
| |
pwr >----/\/\/\----> to SIM
|
=
|
#
</pre>
<ul>
<li>Ideally use a '4 wire' resistor to make sure you have precision measurement.</li>
<li>Choose value appropriately depending on a typical smart card power consumption.</li>
</ul>
<p>Now, I would include added circuitery to make measurements easier.<br />Because in the simple form there are a couple of issue:</p>
<p>First the signal is gonna be pretty small.<br />Second is that to measure the current across the resistor you can't just put the gnd of your probe on A and the tip on B. That's because the GND of the scope is connected to earth of the mains supply, which in turn is connected to the GND on the PC and so the GND of the simtrace ...</p>
<p>You can either:<br /> - Use two scope probe and use A - B function but this has often less functions that a single probe channel. Also if you only have a 2 channel scope you can't monitor anything else (like the clk line or something).<br /> - Simply probe one point: But then you have the supply noise added to your measurement noise and you don't have absolute values.<br /> - Use a differential probe: Great option ... if you have a couple more k$ to buy one.</p>
<p>So ... all of these suck.</p>
<p>We could have an difference amplifier onboard, however, finding one with multi-MHz bandwidth isn't trivial and they all need dual power rails.</p>
<p>(sorry for the rambling, I'm thinking while writing the ticket ...)</p>
<p>Note that since this feature in its more advanced form may involve expensive / complex components and only be used by very few people. so it could be mounted as a simple 0R with other pad left to be mounted manually by the interested parties.</p>