Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092024-03-20T14:24:47ZOpen Source Mobile Communications
Redmine Cellular Network Infrastructure - Bug #6411 (Stalled): ttcn3: execute testsuites with a more real...https://osmocom.org/issues/64112024-03-20T14:24:47Zfixeria
<p>This idea by <a class="user active" href="https://osmocom.org/users/7">laforge</a> originates from <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: default TCP user timeout is way too low (Resolved)" href="https://osmocom.org/issues/6375">#6375</a>: we should try running at least some of our BTS / BSC tests over an Abis link with simulated latency and non-zero packet loss. I did some experiments using tc-netem, running the whole ttcn3-bts-test with a simulated delay: <a class="issue tracker-1 status-3 priority-3 priority-high3 closed" title="Bug: default TCP user timeout is way too low (Resolved)" href="https://osmocom.org/issues/6375#note-14">#6375#note-14</a>. Let's continue discussing this here.</p> OsmoUPF - Feature #6394 (Stalled): Basic URR (Usage Reporting Rule) support for tunnel mappinghttps://osmocom.org/issues/63942024-03-08T13:33:39Zlaforge
<p>Implement basic support for URR (Usage Reporting Rule).</p>
The goal here is to
<ul>
<li>count the number of packets and bytes within each TEID (ul/dl separately)</li>
<li>periodically report those counters via PFCP to the control plane</li>
<li>report the final counters when the tunnel is closed</li>
</ul>
<p><a class="user active" href="https://osmocom.org/users/30187">pespin</a> had implemented something like this for open5gs-upf in<br /><pre>commit fb8ebcdbeae0648e30d04fd016a956642131dddd
Author: Pau Espin Pedrol <pespin@sysmocom.de>
Date: Fri Apr 8 16:10:42 2022 +0200
[UPF] Add initial support for URR Usage Report (#1476)
</pre><br />and following commits.</p>
<p>Now sadly, open5gs-upf is more like a lab-grade upf and nothing that scales at all, and we hence have users of osmo-upf that use it for its fast kernel path.</p>
<p>The primary goal for this feature is the <em>tunnel mapping</em> case in a osmo-hnbgw co-located osmo-upf. The packet and byte counters hence will have to be added to the nftables rules.</p> Cellular Network Infrastructure - Bug #6352 (Stalled): ttcn3-bts-test[-latest] is broken since Fe...https://osmocom.org/issues/63522024-02-05T09:25:36Zfixeria
<p>ttcn3-bts-test[-latest] is failing for a few days already:</p>
<p><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/</a><br /><a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test-latest/1953/</a></p>
<p>The console log (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/console</a>) tells us about problems with the virtphy:</p>
<pre>
+ docker kill jenkins-ttcn3-bts-test-2293-virtphy
Error response from daemon: Cannot kill container: jenkins-ttcn3-bts-test-2293-virtphy: No such container: jenkins-ttcn3-bts-test-2293-virtphy
</pre>
<p>Here is the related logging (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/bts/osmo-bts.log</a>):</p>
<pre>
0: starting: osmo-bts-virtual -c /data/osmo-bts.gen.cfg
((*))
|
/ \ OsmoBTS
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853485 DLGLOBAL NOTICE Unimplemented bts_model_phy_instance_set_defaults (main.c:156)
20240201061853486 DLGLOBAL NOTICE Setting up GSMTAP Um forwarding '(null)->'172.18.29.10:4729' (main.c:363)
20240201061853486 DLCTRL NOTICE CTRL at 0.0.0.0 4238 (control_if.c:1014)
20240201061853487 DL1C NOTICE Unimplemented bts_model_ctrl_cmds_install (bts_model.c:222)
20240201061853487 DLGLOBAL NOTICE Available via telnet 0.0.0.0 4241 (telnet_interface.c:88)
20240201061853487 DPCU INFO Started listening on PCU socket (PCU IF v12): /data/unix/pcu_sock (pcu_sock.c:1237)
20240201061853487 DOSMUX INFO Osmux socket listening on 172.18.29.20:1984 (osmux.c:352)
20240201061853487 DABIS NOTICE A-bis connection establishment to BSC (127.0.0.11) in progress... (abis.c:161)
20240201061853487 DLINP NOTICE enabling ipaccess BTS mode, OML connecting to 127.0.0.11:3002 (ipaccess.c:1098)
20240201061853487 DL1C INFO phy0: PHY link state change shutdown -> connecting (phy_link.c:58)
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
20240201061853487 DL1C INFO phy0: PHY link state change connecting -> shutdown (phy_link.c:58)
unable to open PHY link(s)
0: stopped pid 8 with status 2
</pre>
<p>The virtphy container (<a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/2293/artifact/logs/virtphy/virtphy.log</a>) fails to start:</p>
<pre>
Thu Feb 1 06:18:53 2024 DVIRPHY virtphy.c:248 Virtual physical layer starting up...
Failed to join to mcast goup: No such device
Unable to create VirtualUm multicast socket: No such device
Segmentation fault (core dumped)
</pre> 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> OsmoMGW - Feature #6136 (Stalled): libosmo-mgcp-client should ignore unknown codecs in SDPhttps://osmocom.org/issues/61362023-08-08T16:46:58Zneelsnhofmeyr@sysmocom.de
<p>When mgcp_client receives an MGCP response that has an unknown codec in the SDP part, it aborts with an error.<br />Instead, it should simply ignore entries that are unknown, and carry on with other, known, codecs.<br />An error should occur only when none of the SDP codec entries is valid.</p> OsmoHLR - Feature #6135 (Stalled): Implement routing of SMS-over-GSUP messages between connected ...https://osmocom.org/issues/61352023-08-07T09:14:59Zfalconia
<p>As of <a class="issue tracker-2 status-3 priority-2 priority-default closed" title="Feature: Possibility to route SMS messages over GSUP (Resolved)" href="https://osmocom.org/issues/3587">#3587</a>, OsmoMSC can suppress its built-in SMSC and instead pass SMS-PP to and from external SMSCs via MAP-mimicking GSUP, following classic GSM architecture. However, current OsmoHLR is unable to route these SMS-over-GSUP messages: if I implement my own GSUP-speaking SMSC and connect it to OsmoHLR, the latter won't know how to forward MO-forwardSM.req from OsmoMSC to the SMSC based on the SC-address in SM-RP-DA, or how to forward MT-forwardSM.req in the opposite direction based on the IMSI.</p>
<p>Themyscira Wireless is currently in need of a custom SMSC, I am starting to implement one, and I am looking to do it in the most GSM-architecture-classic manner. The mechanism of SMS-over-GSUP looks like the right way to do what I seek, or at least from OsmoMSC side the protocol does exactly what it should, pass SM-RP to an external SMSC with minimal transformation. My SMSC would connect to OsmoHLR via GSUP much like EUSEs do for USSD - copy the same model, so far so good. But the routing piece in OsmoHLR is missing.</p>
<p>I propose the following design:</p>
<ul>
<li>Similarly to how EUSEs connect with IPA names of the form EUSE-foobar, require SMSCs to connect with IPA names of the form SMSC-12345, where 12345 is the SC-address of this SMSC, i.e., the number to be programmed as the Service-Centre-Address in the EF_SMSP record on SIM cards.</li>
</ul>
<ul>
<li>When MO-forwardSM.req comes from MSC/VLR, route it based on SM-RP-DA: require the address type to be SMSC, and look for a connected GSUP peer with name SMSC-12345 or whatever digit string is in the SC address field coming from the MS.</li>
</ul>
<ul>
<li>To route MO-forwardSM.{resp,err} correctly, the SMSC will be responsible for setting destination_name in the response to a copy of source_name from the request, ideally using osmo_gsup_req_respond().</li>
</ul>
<ul>
<li>When MT-forwardSM.req comes from an SMSC, route it to the serving VLR based on the IMSI just like MT USSD coming from an EUSE.</li>
</ul>
<ul>
<li>For MT-forwardSM.{resp,err} routing, OsmoMSC will need to be patched to fill response destination_name with a copy of request source_name, which it currently fails to do.</li>
</ul>
<p>The only part for which I don't have any solution currently is READY-FOR-SM.req: it's a request coming from MSC/VLR, but there is no SMSC address to route to. In the official architecture the HLR is expected to keep a list of SMSC that attempted and failed MT SMS delivery, and notify all of them upon a single "ready" notification from MSC/VLR - but implementing all that complexity would be a bit too much for me at the present moment. I am thinking of having OsmoHLR simply reply with "success" to READY-FOR-SM.req as a FIXME placeholder in the initial implementation, just so that the MS gets an RP-ACK rather than RP-ERROR (the MS did nothing wrong!), and leave it as a problem to be solved later.</p>
<p>Any better ideas?</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> 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> Core testing infrastructure - Feature #5760 (Stalled): Develop TTCN-3 test suite for MMEhttps://osmocom.org/issues/57602022-11-09T21:46:56Zlaforge
<p>Implement functional test suites in the TTCN-3 domain specific language for the MME, and create jenkins/docker/... integration for executing it nightly against open5gs mme.</p> OsmoSGSN - Feature #5759 (Stalled): Support for Mobility between SGSN (2G/3G) and S-GW (4G)https://osmocom.org/issues/57592022-11-09T21:45:34Zlaforge
<p>Develop the interface for mobility between 2G/3G and 4G on the S-GW/SGSN level, allowing subscribers to switch seamlessly between 2G/3G and 4G coverage areas with minimal interruption.</p> pySim - Bug #5714 (Stalled): update_record_decoded does not use real record length when writing E...https://osmocom.org/issues/57142022-10-16T08:44:29ZCHV
<p>I'm using old regular cards for testing.</p>
<p>Class EF_MSISDN, method _encode_record_hex always assumes a rec_len of 15 which results in misaligned/invalid data if the real record length is different.<br />The encoded msisdn must always use the <ins>last 14 bytes</ins> in the record. This can only be achieved when the real record length is used.</p>
<p>Example:<br /><pre>
select MF/ADF.USIM/EF.MSISDN
update_record_decoded 1 {"msisdn":"+491234567890"}
read_record_decoded 1
read_record 1
</pre></p>
<p>This may also concern updating EF.ADN records.</p> OsmoPCU - Bug #5696 (Stalled): RLC/MAC: poll timeout when assigning a multi-slot DL TBFhttps://osmocom.org/issues/56962022-10-05T07:58:36Zfixeria
<p>One of my phones, Sony Ericsson K800i, fails to complete <code>PDP Context Activation</code> procedure. Thanks to TEMS, I found out that the phone never receives <code>Activate PDP Context Accept</code> message. Further analysis revealed that <code>Activate PDP Context Request</code> message from the phone triggers allocation of a multi-slot Downlink TBF, which includes TS6 and TS7. For some reason, <strong>the phone ACKnowledges allocation of Downlink TBF on TS7 instead of TS6</strong>, what confuses osmo-pcu and causes retransmissions of the <code>PACKET_DOWNLINK_ASSIGNMENT</code> message.</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> OCTOI - Osmocom Community TDM over IP - Bug #5693 (Stalled): no progress tones in yatehttps://osmocom.org/issues/56932022-09-30T13:04:16Zlaforge
<p>We've never had call progress tones from yate in our network and had ignored that until now.</p>
This is the case in
<ul>
<li>any outbound call setup from a phone, where there are no dial tones, alerting tones, etc.</li>
<li>calls routed to tone/*</li>
</ul>
<p>The respective ToneSource() class instances are created and provide the respective quantity of samples. It works for SIP, but not for ISDN.</p>
<p>I think it's related to the Q.931 signaling side. It states:</p>
<blockquote>
<p><strong>5.4 In-band tones and announcements</strong></p>
<p>When in-band tones/announcements not associated with a call state change are to be provided by the network before reaching the Active state, a PROGRESS message is returned simultaneously with the application of the in-band tone/announcement. The PROGRESS message contains the progress indicator No. 8, in-band information or appropriate pattern is now available.</p>
<p>When tones/announcements have to be provided together with a call state change, then the appropriate message [e.g. for ALERTING, DISCONNECT, etc., (see clause 3)] with progress indicator No. 8, in-band information or appropriate pattern is now available, is sent simultaneously with the application of the in-band tone/announcement.</p>
</blockquote> 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> Core testing infrastructure - Bug #5665 (Stalled): ERROR: files left in build directory after dis...https://osmocom.org/issues/56652022-08-28T09:21:41Zfixeria
<p>Since recently we're observing sporadic master-* job failures on Jenkins. There is always a coredump file, which makes 'distcleancheck' target fail:</p>
<pre>
ERROR: files left in build directory after distclean:
./tests/core
make[1]: Leaving directory '/build/libosmocore-1.7.0.26-862dd/_build/sub'
make[1]: *** [Makefile:1010: distcleancheck] Error 1
make: *** [Makefile:941: distcheck] Error 1
</pre>
<p>This is not specific to libosmocore, I saw master-osmo-{bsc,msc} failing with the same verdict too.</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 #5568 (Stalled): SMPP socket doesn't use TCP_NODELAYhttps://osmocom.org/issues/55682022-05-17T18:33:30Zlaforge
<p>The SMPP socket uses sockets directly (without relying on libosmo-netif/stream) and fails to setsockopt(TCP_NODELAY). This is not critical (SMS is sloooow), but it does add unintended latency to all SMPP messages sent.</p>
<p>The quick fix is to add the setsockopt for every socket we accept(). The clean-up would be to use libosmo-netif/stream...</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> OsmocomBB - Feature #5502 (Stalled): MS-side LLC implementationhttps://osmocom.org/issues/55022022-03-29T12:35:40Zlaforge
<p>The LLC + SNDCP protocols are rather symmetrical, so the existing code from the network side (in <a class="wiki-page" href="https://osmocom.org/projects/osmosgsn/wiki">osmo-sgsn</a> should be possible to generalize rather easily</p> OsmocomBB - Feature #5501 (Stalled): MS-side GPRS Mobility Management (GMM) + Session Management ...https://osmocom.org/issues/55012022-03-29T12:32:56Zlaforge
<p>In order to support GPRS from the MS side, we will need a GMM + SM implementation on the mobile side.</p>
<p>The network side is already implemented as part of <a class="wiki-page" href="https://osmocom.org/projects/osmosgsn/wiki">osmo-sgsn</a></p> OCTOI - Osmocom Community TDM over IP - Feature #5434 (Stalled): more statistics / countershttps://osmocom.org/issues/54342022-01-30T11:09:45Zlaforge
<p>For some more long-term testing or later operation, we need good statistics, such as</p>
<ul>
<li>re-ordered or missing IP packets</li>
<li>Rx/Tx byte/packet count</li>
<li>RTT</li>
<li>frame underflows in IP -> E1 direction</li>
</ul>
<p>Those stats could be interrogated via VTY, but ideally also exposed via our libosmocore statsd exporter.</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> OsmoBSC - Bug #5308 (Stalled): confusion around mgw e1 line vs trunk dichtomyhttps://osmocom.org/issues/53082021-11-14T14:48:15Zlaforge
<p>there seems to be some lack of logical clarity how the MGCP endpoint names are constructed for use with E1.</p>
<ul>
<li>osmo-mgw uses the trunk number to construct the "e1-N" part in "ds/e1-0/s-1/su16-0"
<ul>
<li>any e1_input line_nr can be mapped to any trunk_nr in the config</li>
</ul>
</li>
<li>osmo-bsc unconditionally uses the e1_input line_nr to construct the "e1-N" part in "ds/e1-0/s-1/su16-0"</li>
</ul>
This means that the entire setup will only work, if osmo-mgw is confiugred to use the same trunk_nr as e1_input line_nr, which
<ol>
<li>is weird, as why would you make something configurable if it only works in one way, and</li>
<li>is not mentioned or documented anywhere in either the osmo-mgw or osmo-bsc documentation, and also not really visible from the example configs, AFAICT</li>
</ol>
<p>So I think we have two ways forward:</p>
<ol>
<li>make osmo-mgw always use the e1 line_nr for constructing the enpdoint names</li>
<li>allow osmo-bsc to configure the mgw-side trunk number [for each timeslot?]</li>
</ol>