Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092023-12-23T15:12:32ZOpen Source Mobile Communications
Redmine pySim - Bug #6317 (Stalled): data driven tests for TLV decodershttps://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> Core testing infrastructure - Feature #6023 (Stalled): test rack/lab power management software wi...https://osmocom.org/issues/60232023-05-04T06:38:46Zlaforge
<a name="Problem-Statement"></a>
<h2 >Problem Statement<a href="#Problem-Statement" class="wiki-anchor">¶</a></h2>
<p>In our test/lab setups, we do have a number of systems that run 24/7 but which are really used only very few hours per day. This has become very visible after we started (a few months ago) to deploy tasmota/influxdb/grafana for plotting many different power rails.</p>
<p>Direct on/off switching from within a given test job only works if that test job is the only user of the given resource (such as e.g. a BTS in osmo-gsm-tester).</p>
<p>For jenkins builders, OBS workers and similar machines, there could be any number of concurrent users. So there's no single job that can power on the resourec before using it, and power it off after it terminates.</p>
<p>What we need is a system that maintains a usage count, similar to how we do usage/reference counting in data structures in software development.</p>
<p>I've started to prototype a modular python daemon which offers a REST API over which users can obtain <em>usage tokens</em> for named resources. The daemon then keeps track of the current use count and switches resources on/off as needed.</p>
<p>Jenkins jobs would then (e.g. in a pipeline) first obtain a usage token (which would implicitly power up the resource if it is not aleady powwered), and release the usage token after they're gone. This way we can power up build machines only when needed, saving significant electrical power, reducing noise and minimizing heat dissipation.</p>
<a name="Architecture-Class-model"></a>
<h2 >Architecture / Class model<a href="#Architecture-Class-model" class="wiki-anchor">¶</a></h2>
<a name="Resource"></a>
<h3 >Resource<a href="#Resource" class="wiki-anchor">¶</a></h3>
<p>A <em>Resource</em> is typically some kind of physical equipment (server, build host, network equipment, ...) which one or multiple users may be using concurrently.</p>
<p>The Resource has a state, such as</p>
<table>
<tr>
<th>State</th>
<th>Description</th>
</tr>
<tr>
<td>off</td>
<td>Powered down</td>
</tr>
<tr>
<td>powered</td>
<td>Powered up, but not reachable yet</td>
</tr>
<tr>
<td>available</td>
<td>Powered up and reachable (typically via network)</td>
</tr>
</table>
<p>A Resource refers to a <em>Switcher</em> and an <em>AvailabilityChecker</em></p>
<p>A Resource keeps a list of <em>UsageToken</em>; one for each concurrent user.</p>
<a name="Switcher"></a>
<h3 >Switcher<a href="#Switcher" class="wiki-anchor">¶</a></h3>
A <em>Switcher</em> is something that can switch power. Possible implementations include
<ul>
<li>sispm compatible USB-switchable power sockets</li>
<li>Intellinet rackmount PDUs with IP/HTTP interface</li>
<li>Tasmota switchable power sockets</li>
<li>ethernet wake-on-lan (on) + ssh-based shutdown (off)</li>
</ul>
A <em>Switcher</em> implementation (inheriting from the abstract Switcher base class) provides methods for
<ul>
<li>changing the power state (on/off)</li>
<li>determining the current actual power state (if supported by hardware). This is important to get the state right at start-up time.</li>
</ul>
<a name="SwitcherGroup"></a>
<h3 >SwitcherGroup<a href="#SwitcherGroup" class="wiki-anchor">¶</a></h3>
<p>A <em>SwitcherGroup</em> is a logical group of multiple <em>Switcher</em>, for example the set of four switchable sispm sockets in one power strip, or the set of 8 switchable power ports in an Intellinet PDU.</p>
<a name="AvailabilityChecker"></a>
<h3 >AvailabilityChecker<a href="#AvailabilityChecker" class="wiki-anchor">¶</a></h3>
<p>An <em>AvailabilityChecker</em> is something that can check the logical availability of a (powered-up) resource. One common example for an IP-attached resources is an ICMP echo request/response based check.</p>
<a name="UsageToken"></a>
<h3 >UsageToken<a href="#UsageToken" class="wiki-anchor">¶</a></h3>
<p>An <em>UsageToken</em> for a <em>Resource</em> must be obtained by any user intending to use the Resource. The UsageToken has a validity time (in seconds), after which it automatically expires.</p>
<p>Release of the UsageToken can hence be either explicit (via REST API after the user is done) or implicit (timeout of the validity period).</p> libosmo-abis - Bug #5896 (Feedback): libosmo-abis built withtout --enable-e1d in deb and rpm pack...https://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> SDR (Software Defined Radio) - Feature #5892 (Stalled): design/build ext clock input board for Pl...https://osmocom.org/issues/58922023-02-06T10:04:22Zlaforge
<p>We have a number of plutosdr devices at sysmocom, unfortunately all of them still RevB which unlike current RevD has no external clock input. Most of our use cases require a proper reference clock input, so I thought it might be a good idea to build a small board which contains the LTC6957HMS-3#PBF based input circuitry that was added in RevD. This circuit ensures that any square or sine clock can be used, at proper 50 Ohm impedance, over a wide range of levels.</p>
<p>The ext in / ext out ports should be SMA connectors, so that the resulting PCB can be panel-mounted by bulkhead-mounting those two SMA connectors to a face plate of whatever enclosure we're putting the plutosdr into.</p>
<p>The interconnect between the clock board and plutosdr can be made via u.fl as shown in <a class="external" href="https://coherent-receiver.com/wp-content/uploads/2018/01/umc-pluto-site.jpg">https://coherent-receiver.com/wp-content/uploads/2018/01/umc-pluto-site.jpg</a></p>
<p><a class="external" href="https://wiki.analog.com/university/tools/pluto/hacking/hardware">https://wiki.analog.com/university/tools/pluto/hacking/hardware</a></p> SIMtrace 2 - Feature #5826 (Stalled): SAM4S4BA support in firmwarehttps://osmocom.org/issues/58262022-12-13T16:27:45Zlaforge
<p>This ticket is about supporting the SAM4S4BA from our firmware, in addition to the SAM3S4BA, SAM3S8BA and SAM4SD8BA we've been using so far for simtrace2 devices.</p>
<p>This is a spin-off of <a class="issue tracker-2 status-2 priority-1 priority-lowest parent" title="Feature: Hardware / Circuit board update for SAM3S based SIMtrace2 with 1.8V/5V support (In Progress)" href="https://osmocom.org/issues/1706">#1706</a></p> osmo-e1d - Bug #5824 (Feedback): Line dead message in the log after starthttps://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://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> libosmo-abis - Feature #5691 (Stalled): Expose DAHDI statistics to prometheushttps://osmocom.org/issues/56912022-09-27T15:32:46Zlaforge
<p>The DAHDI_SPANSTAT ioctl can be used to obtain a number of statistics for a given span (E1/T1 line).</p>
<p>It would be a good idea to implement some library code which would start a timer to periodically poll the DAHDI_SPANSTAT on each of the relevant spans. This could be used by osmo-bsc, osmo-gbproxy or even a stand-alone application to pull all those counters into osmocom rate_ctr infrastructure.</p>
<p>That in turn would allow the counters to be exported alongside all our other counters/stats via the statsd exporter.</p> pySim - Bug #5630 (Stalled): pySim-trace doesn't support decoding classic SIM cards (TS 11.11 / T...https://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> SIMtrace 2 - Bug #5578 (Stalled): osmo-remsim-client-st2 hangs after usb-reset without power loss...https://osmocom.org/issues/55782022-06-15T21:50:45Zroh
<p>in case of a osmo-remsim-client-st2 session which gets restarted after being stopped by a usb-disconnect<br /> (terminates with "DST2 FATAL user_simtrace2.c:221 USB IN transfer failed, status=1" as expected)</p>
<p>osmo-remsim-client-st2 gets stuck and then terminates after some time:</p>
<pre>
root@raspberrypi:~# /usr/bin/osmo-remsim-client-st2 -i 10.15.1.135 -V 1d50 -P 4004 -C 1 -I 0 -H 1-1.3.1 -c 1 -n 0
DRSPRO INFO ../rspro_client_fsm.c:307 RSPRO_CLIENT(server){REESTABLISH}: Creating TCP connection to server at 10.15.1.135:9998
DLINP NOTICE simtrace2_api.c:267 [0] <= osmo_st2_cardem_request_config(features=00000001)
DLINP NOTICE input/ipa.c:128 10.15.1.135:9998 connection done
DRSPRO NOTICE ../rspro_client_fsm.c:125 RSPRO_CLIENT(server){REESTABLISH}: RSPRO link to 10.15.1.135:9998 UP
DRSPRO INFO ../rspro_client_fsm.c:307 RSPRO_CLIENT(bankd){REESTABLISH}: Creating TCP connection to server at 10.15.1.135:9999
DLINP NOTICE input/ipa.c:128 10.15.1.135:9999 connection done
DRSPRO NOTICE ../rspro_client_fsm.c:125 RSPRO_CLIENT(bankd){REESTABLISH}: RSPRO link to 10.15.1.135:9999 UP
DLINP NOTICE simtrace2_api.c:168 [0] <= osmo_st2_cardem_request_card_insert(inserted=1)
DLINP NOTICE simtrace2_api.c:317 [0] <= _modem_sim_select(remote_sim=1)
DLINP NOTICE simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 00 )
DLINP NOTICE simtrace2_api.c:285 [0] <= _modem_reset(asserted=2, pulse_ms=300)
DLINP NOTICE simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 9f 96 80 1f 87 80 31 e0 73 fe 21 1b 67 4a 4c 75 30 34 05 4b a9 )
DST2 INFO user_simtrace2.c:65 SIMtrace => PTS req: ff 10 96 79 00 00
...
<modem starts, usb enumeration of serials/wwlan>
...
USB OUT transfer failed, status=2
</pre>
<p>later restarts remain the same in behaviour but a bit different in output:</p>
<pre>
root@raspberrypi:~# /usr/bin/osmo-remsim-client-st2 -i 10.15.1.135 -V 1d50 -P 4004 -C 1 -I 0 -H 1-1.3.1 -c 1 -n 0
DRSPRO INFO ../rspro_client_fsm.c:307 RSPRO_CLIENT(server){REESTABLISH}: Creating TCP connection to server at 10.15.1.135:9998
DLINP NOTICE simtrace2_api.c:267 [0] <= osmo_st2_cardem_request_config(features=00000001)
DLINP NOTICE input/ipa.c:128 10.15.1.135:9998 connection done
DRSPRO NOTICE ../rspro_client_fsm.c:125 RSPRO_CLIENT(server){REESTABLISH}: RSPRO link to 10.15.1.135:9998 UP
DRSPRO INFO ../rspro_client_fsm.c:307 RSPRO_CLIENT(bankd){REESTABLISH}: Creating TCP connection to server at 10.15.1.135:9999
DLINP NOTICE input/ipa.c:128 10.15.1.135:9999 connection done
DRSPRO NOTICE ../rspro_client_fsm.c:125 RSPRO_CLIENT(bankd){REESTABLISH}: RSPRO link to 10.15.1.135:9999 UP
DLINP NOTICE simtrace2_api.c:168 [0] <= osmo_st2_cardem_request_card_insert(inserted=1)
DLINP NOTICE simtrace2_api.c:317 [0] <= _modem_sim_select(remote_sim=1)
DLINP NOTICE simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 00 )
DLINP NOTICE simtrace2_api.c:285 [0] <= _modem_reset(asserted=2, pulse_ms=300)
DLINP NOTICE simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 9f 96 80 1f 87 80 31 e0 73 fe 21 1b 67 4a 4c 75 30 34 05 4b a9 )
USB OUT transfer failed, status=2
</pre>
<p>please note that the modem does not seem to reboot on later restarts of osmo-remsim-client-st2, which is odd.</p>
<p>osmo-remsim-client version 1.0.0.18-f5f5<br />qmod firmware 0.8.1.33-9088</p>
<p>osmo-remsim-bankd version 1.0.0.18-f5f5<br />osmo-resmim-server version 1.0.0.18-f5f5</p>
<p>maybe this is a rerun of <a class="issue tracker-1 status-7 priority-1 priority-lowest" title="Bug: osmo-remsim-client-st2 (or firmware?) gets stuck on PTS (Stalled)" href="https://osmocom.org/issues/4409">#4409</a></p>
<p>for this test the server/bankd were on x86_64 and the client was on armv7l (rpi) but i don't think it matters.<br />i have also tried a older qmod firmware (0.7.0.57-f46d) for comparison but i can see no difference in behavior.</p>
<p>please note that i could not reproduce this issue with a modem on st34, only on st12. i suspect it has to do with st12 staying powered all the time and not reset/rebooted on usb-connect properly somehow.</p>
<p>this may as well be a firmware issue on the qmod.</p> OsmoMSC - Bug #5564 (Stalled): blocking database I/O by SMS databasehttps://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://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://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://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://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 #5419 (Stalled): cardem errors with higher baud ratehttps://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://osmocom.org/attachments/download/4852/wireshark.png" alt="" /></p> OCTOI - Osmocom Community TDM over IP - Feature #5417 (Stalled): S/T (S0) ISDN BRI adapter with V...https://osmocom.org/issues/54172022-01-24T19:52:37Zlaforge
<p>So.. As part of the <a class="wiki-page" href="https://osmocom.org/projects/octoi/wiki/Community_TDMSS7_Network">Community_TDMSS7_Network</a>, offering PRI is nice but most people will have BRI equipment (modems, ISDN-TA, small home PBX, ...) that they'd be interested in attaching.</p>
<p>Doing this with COTS ISDN adapters is not an option, as we cannot control their clock to match the master clock of the TDMoIP network.</p>
<p>I've been brainstorming a potential design and validated component availability. Currently I'm thinking of something like this</p>
<ul>
<li>CologneChip XHFC-2SU (2-port S0) controller IC, operated in NT mode
<ul>
<li>available from stock at MOQ-160 from CologneChip</li>
</ul>
</li>
<li>Matching dual magnetics.
<ul>
<li>digikey + mouser have a few pulse parts still in stock (low qty): T5007</li>
<li>Sumida has stopped all production</li>
<li>Talema has 30 weeks lead time</li>
<li>UMEC still has some stock of UT20795-5MTS, I'm putting a 250 unit reel on sysmocom stock right now</li>
</ul>
</li>
<li>clocking
<ul>
<li>10 MHz VCXO (optional external 10 MHz input in case somebody already has GPS-DO around)</li>
<li>some clock divider to bring this down to 8kHz. If we have no other programmable logic or timer/counter blocks that can be used, an ATTiny clocked off 10MHz (no prescaler, counter generating interrupt every 250 cycles, divide-by-5 in software/irq-handler) approach can be used - doen in a lot of DYI 10MHz -> 1PPS designs.</li>
<li>some PWM or DAC to drive the VXCO</li>
</ul></li>
</ul>
<p>The more interesting question is the interface on the "Compute" side.</p>
Possible high-level approaches:
<ol>
<li>USB-attached to some Linux PC
<ul>
<li>more analoguous to icE1usb, but requires an additonal computer</li>
</ul>
</li>
<li>Raspi hat (or beagle or the like)
<ul>
<li>I'm not a big raspi fan, but they are very popular</li>
</ul>
</li>
<li>built-in Ethernet for direct TDMoIP
<ul>
<li>most easy to deploy, would allow people without Linux knowledge to simply plug+play</li>
</ul></li>
</ol>
<p>Right now I'm leaning mostly towards something self-contained with built-in Ethernet.</p>
The major problem right now is availability of uC or FPGA.
<ul>
<li>STM32 are basically vanished off the planet</li>
<li>iCE40 equally not available (yes, <a class="user active" href="https://osmocom.org/users/12">tnt</a> might get 100, but ...)</li>
</ul>
<p>One thought might be to use an SAME5x (sysmocom uses that part in the sysmoOCTSIM and has some stock. It is a bit on the high-end side compared to the requirements).</p> osmo-e1d - Feature #4917 (Stalled): reporting of alarms/errors known to the icE1usbhttps://osmocom.org/issues/49172020-12-18T10:33:35Zlaforge
<p>Now that the device firmware is exposing error situations / counters via a dedicated interrupt endpoint, we should make use of this in osmo-e1d.</p>
<p>See <a class="external" href="https://gerrit.osmocom.org/c/osmo-e1d/+/21782">https://gerrit.osmocom.org/c/osmo-e1d/+/21782</a> and <a class="external" href="https://gerrit.osmocom.org/c/osmo-e1d/+/21783">https://gerrit.osmocom.org/c/osmo-e1d/+/21783</a> for a start.</p>
<p>We should also consider if and how to report such errors to the clients (libosmo-e1d users).</p>
Furthermore, there is also important knowledge to be gained from parsing the TS0, such as
<ul>
<li>does the remote end indicate alarm via A bit</li>
<li>does the remote end report CRC errors via E bits</li>
</ul> osmo-e1d - Bug #4916 (Stalled): USB unplug / replug renders e1d unusablehttps://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://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://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> Core testing infrastructure - Feature #4692 (Stalled): finally implement testing of the actual vo...https://osmocom.org/issues/46922020-08-05T08:27:45Zlaforge
<p>For many years we've set up tons of testing, but it's all on the control plane, and the user plane for PS services. We don't yet have any testing of the acutal voice path, so we wouldn't detect codec problems drop-outs or whatever other voice quality issues in any of our testing.</p> OsmoBSC - Bug #4614 (Stalled): "bogus channel load sample" when using BS-11, Nokia or Ericsson BTShttps://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> OsmoBTS - Bug #3569 (Stalled): Some phones don't receive SMSCBhttps://osmocom.org/issues/35692018-09-19T09:23:20Zlaforge
<p>Reported so far to be affected of this:</p>
<ul>
<li>Samsung Galaxy Note 4</li>
<li>Huawei P10</li>
<li>Samsung Galaxy S9</li>
<li>iPhone 8</li>
<li>Huawei Honor 9</li>
</ul> OsmoBTS - Bug #3568 (Stalled): CBCH on SDCCH/8 not working for osmo-bts-sysmohttps://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> Misc Hardware Projects - Feature #3566 (Stalled): power supply / battery / charge for our GSM-R O...https://osmocom.org/issues/35662018-09-18T13:54:06Zroh
figure out a pinout/spec for these 2 kinds of devices:
<ul>
<li>sagem NNG OPS 940
<ul>
<li>pogopins from device to battery</li>
<li>ericcson style flat connector row on bottom end</li>
<li>3.6V 2.3Ah li-ion battery</li>
</ul></li>
</ul>
<ul>
<li>timba tec pocket pc
<ul>
<li>5V DC 2.4A label</li>
<li>3.7V 4Ah li-ion battery</li>
</ul></li>
</ul> SIMtrace 2 - Bug #3379 (Stalled): documentation on how to use SIMtrace2https://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> OsmoBTS - Bug #2979 (Stalled): osmo-bts-virtual reports bogus measurement valueshttps://osmocom.org/issues/29792018-02-21T23:25:35Zlaforge
<p>Despite the GSMTAP header containing RSSI information, we do not report those measurement values up to L1SAP.</p> OsmoSGSN - Bug #2958 (Stalled): OsmoSGSN doesn't authenticate on second/further ATTACH REQUESThttps://osmocom.org/issues/29582018-02-17T17:29:12Zlaforge
<p>When a new/unknown MS performs an ATTACH REQUEST for the first time, it is authenticated.</p>
<p>However, if that same MS later performs a second ATTACH REQUEST, even with new P-TMSI/TLLI, it is not authenticated and we simply send an ATTACH ACCEPT. This is a security problem, as it means anyone can impersonate other known-existing IMSIs.</p> Z-Netz - Bug #2807 (Stalled): Obtain ZERBERUS software build[s] and manual[s]https://osmocom.org/issues/28072018-01-01T13:08:48Zlaforge
<p>I've sent mail to padeluun + rena about this.</p> Cellular Network Infrastructure - Feature #2604 (Stalled): GSUP-to-DIAMETER converter / IWFhttps://osmocom.org/issues/26042017-10-29T23:01:06Zlaforge
<p>In order to support a single subscriber database for 2G/3G and LTE, operators normally use a single HSS. HSS is the EPC successor of the LTE.</p>
<p>Instead of MAP over SS7, HSS's speak DIAMETER over SCTP or TCP (with optional TLS). The types of procedures / transactions are pretty much the same as before, but the encoding and the protocol changed completely.</p>
<p>There are a couple of (at least minimal) HSS implementations out there, from freeDiameter to nextepc, to name some examples.</p>
<p>If we were to implement a converter between GSUP and DIAMETER, then the OsmoMSC and OsmoSGSN could access an external HSS - and that same HSS could be accessed from nextepc or even openair-cn for LTE access.</p>
<p>3GPP TS 29.305 specifies the MAP-to-DIAMETeR InterWorkingFunction (IWF), which is pretty much the same device, with the exception that we'd use GSUP instead of MAP.</p> SIMtrace 2 - Bug #1705 (Stalled): re-integrate tracing + card reader modes into SIMtrace2 firmwar...https://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>