Open Source Mobile Communications: Issueshttps://osmocom.org/https://osmocom.org/favicon.ico?16647414092022-02-21T19:07:57ZOpen Source Mobile Communications
Redmine SIMtrace 2 - Bug #5464 (In Progress): cardem firmware unable to attach to cardhttps://osmocom.org/issues/54642022-02-21T19:07:57Zk_o_
<p>I'm using a Nexus 5 phone. I have a permanent problem that the remote SIM cannot be attached. I always see several RESETs after the phone is restarted. The trace firmware together with the command line works. The adapter cable is in a prepared SIM tray and works. What could be the issue?</p>
<pre>
simtrace2-cardem-pcsc --usb-vendor 1d50 --usb-product 60e3 --usb-path 2-1.4 --usb-config 1 -n 2
simtrace2-cardem-pcsc - Using PC/SC reader as SIM
(C) 2010-2020, Harald Welte <laforge@gnumonks.org>
(C) 2018, sysmocom -s.f.m.c. GmbH, Author: Kevin Redon <kredon@sysmocom.de>
<0002> simtrace2_api.c:267 [0] <= osmo_st2_cardem_request_config(features=00000001)
<0002> simtrace2_api.c:168 [0] <= osmo_st2_cardem_request_card_insert(inserted=1)
<0002> simtrace2_api.c:317 [0] <= _modem_sim_select(remote_sim=1)
<0002> simtrace2_api.c:250 [0] <= osmo_st2_cardem_request_set_atr(3b 9f 96 80 1f c7 80 31 e0 73 f6 21 13 67 56 03 27 00 89 01 02 28 )
<0002> simtrace2_api.c:284 [0] <= _modem_reset(asserted=2, pulse_ms=300)
Entering main loop
-> 01 08 00 00 00 00 0d 00 01 00 00 00 00
SIMtrace IRQ 01 04 00 00 00 00 15 00 00 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x0, fi=1, di=1, wi=10 wtime=9600 ()
SIMtrace IRQ 01 04 00 00 00 00 15 00 10 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x10, fi=1, di=1, wi=10 wtime=9600 (RESET )
SIMtrace IRQ 01 04 00 00 00 00 15 00 00 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x0, fi=1, di=1, wi=10 wtime=9600 ()
SIMtrace IRQ 01 04 00 00 00 00 15 00 10 00 00 00 00 00 01 01 0a 80 25 00 00
SIMtrace IRQ STATUS: flags=0x10, fi=1, di=1, wi=10 wtime=9600 (RESET )
</pre> SIMtrace 2 - Bug #5423 (New): "trace" firmware continuous test setuphttps://osmocom.org/issues/54232022-01-27T12:24:54Zlaforge
<p>Similar to <code>cardem</code> in <a class="issue tracker-2 status-2 priority-2 priority-default" title="Feature: "cardem" continuous testing setup (In Progress)" href="https://osmocom.org/issues/5422">#5422</a>, we should also create a continuous test setup for passing SIM protocol tracing. The IUT is the simtrace2 firmware.</p>
<p>We can use diffeent modems / CCID readers accessing a SIM card via a SIMtrace2 device while tracing the communication.</p> SIMtrace 2 - Feature #5422 (In Progress): "cardem" continuous testing setuphttps://osmocom.org/issues/54222022-01-27T12:22:10Zlaforge
<p>We shuold create a test setup where we can continously test the <code>cardem</code> firmware for the various targets, such as at least simtrace2 and qmod.</p>
<p>The idea would be to use the TTCN3 test ports for SIMTRACE USB protocol on the one hand side and CCID USB protocol on the other hand side.</p>
<p>Tests should ideally not just test interop with one specific CCID reader model but with a larger number of different readers to cover reader-specific issues (I'm seeing different issues with different readers in manual testing).</p>
<p>The tests can then be executed with the latest cardem firmware of the day, on different IUT hardware (simtrace2, qmod) against different readers.</p>
For QMOD testing we would have to either
<ul>
<li>insert a modem with CCID capability (they do exist)</li>
<li>use a custom PCB adapter or some solder wire to hook up the SIM traces of the mCPIE sockets with some external reader</li>
</ul>
<p>But let's focus on simtrace2 for the initial setup, and then expand from there.</p> 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> SIMtrace 2 - Bug #5415 (New): cardem: watchdog triggers firmware resethttps://osmocom.org/issues/54152022-01-24T15:18:49Zlynxis
<p>While testing the cardem firmware on a owhw board with a script, the watchdog resets the board from time to time (2-4 times while doing 50 test runs).<br />When the watchdog triggers, the userspace application also exits because the USB transfer errors with a stall (bulk transfer).</p>
<p>bootloader version: 87f8de15 (based on ea9a91f5c)<br />app: 87f8de15 (based on ea9a91f5c)<br />I've pushed this version to lynxis/wip.</p>
<p>The test look like this pseudo c code<br /><pre>
for(i=0; i<50; i++) {
reset_modem();
for (j=0; j<5; j++) {
if (get_imsi() == 0)
break;
}
}
</pre></p> SIMtrace 2 - Bug #4430 (New): firmware can get in endless out-of-memory loop on OUT EP floodhttps://osmocom.org/issues/44302020-03-01T15:06:25Zlaforge
<p>When flooding the OUT EP with too many messages, the firmware can get into an OOM situation from which it doesn't recover anymore. All it will do is print the below messages:</p>
<pre>
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
-E- _talloc_zero() out of memory!
</pre>
<p>I'm currently reproducing this with a test case that sends 1000 bogus OUT EP transfers to the device.</p> UmTRX - Feature #3747 (New): LMS6002D RX Gain Controlhttps://osmocom.org/issues/37472019-01-08T02:53:19Zjahredibanez
<p>Hi, with OSMO Rx-Gain Setting for UmTRX</p>
<p>osmotrx rx-gain <0-50><br />Set the receiver gain (configured in the hardware) in dB</p>
<p>LMS6002D Transceiver has gain blocks for RXLNA, RXVGA1, RXLPF, and RXVGA2.</p>
<p>which block does this setting change? and how does it change these values?</p> SIMtrace 2 - Feature #3711 (New): Add screw holes for permanent installationshttps://osmocom.org/issues/37112018-11-27T02:04:29Zgnutoo
<p>The remote SIM functionality enables to use SIMtrace 2 to do things like functional testing of smartphones, for instance to do regression testing or to fix bugs on the free software code that talks to its modem.</p>
<p>In such permanent installation setup, it would be better to be able to permanently screw it (through standoffs, screws, and bolts).</p>
<p>As for keeping the smartphone in place, it's probably trivial to do that with a smartphone case.</p> 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> Z-Netz - Feature #2814 (New): Create + Document classic CrossPoint setup on DOS (dosemu)https://osmocom.org/issues/28142018-01-01T13:41:48ZlaforgeZ-Netz - Feature #2813 (New): Create + Document OpenXP setup on Linuxhttps://osmocom.org/issues/28132018-01-01T13:41:26ZlaforgeZ-Netz - Bug #2809 (New): Build ZConnect <-> UseNet gatewayhttps://osmocom.org/issues/28092018-01-01T13:09:32Zlaforge
<p>possibly looking at <a class="external" href="https://www.daneben.de/odoconnect.html">https://www.daneben.de/odoconnect.html</a> as a tool</p> Z-Netz - Bug #2808 (New): Create + Document VM/emulation setup for running ZERBERUShttps://osmocom.org/issues/28082018-01-01T13:09:06ZlaforgeZ-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> UUCP and UseNet - Feature #2806 (New): Create Dockerfile and/or ansible playbook for UseNet nodehttps://osmocom.org/issues/28062018-01-01T13:04:27Zlaforge
<p>Should be possible using stock debian packages for taylor UUCP, inn2, exim, ...</p> SIMtrace 2 - Feature #1912 (Stalled): do proper re-layout of the boardhttps://osmocom.org/issues/19122017-01-12T12:55:08Zlaforge
<p>SIMtrace v1 PCB layout has been serving us well, but is far from ideal in terms of RF return paths and signal integrity.</p>
<p>Let's revisit that when doing a v2 of the hardware</p> SIMtrace 2 - Feature #1911 (New): check if we can have an enclosed version of simtrace v2https://osmocom.org/issues/19112017-01-12T12:52:40Zlaforge
<p>It would be nice to have an enclosed device rather than a bare PCB. Let's review that option for v2 hardware.</p> UmTRX - Feature #1515 (New): Heat dissipation and mounting issuehttps://osmocom.org/issues/15152016-02-19T22:52:49Z
<p>Heat dissipation and mounting issue.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1516 (New): There are no port to control external equipment like PAhttps://osmocom.org/issues/15162016-02-19T22:52:49Z
<p>There is no port to control external equipment such as a PA.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1517 (New): U_FL (UMC) connectors are not reliable after few connectionshttps://osmocom.org/issues/15172016-02-19T22:52:49Z
<p>U_FL (UMC) connectors are not reliable after few connections.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1518 (New): Upper limit of the clock is too lowhttps://osmocom.org/issues/15182016-02-19T22:52:49Z
<p>Upper limit of the clock is too low.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1510 (New): Complete UHD integrationhttps://osmocom.org/issues/15102016-02-19T22:52:48Z
<p>Complete UHD integration.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1508 (New): Implement UmSEL diversity switch controlhttps://osmocom.org/issues/15082016-02-19T22:52:48Z
<p>Implement <a class="wiki-page new" href="https://osmocom.org/projects/umtrx/wiki/UmSEL">UmSEL</a> diversity switch control.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1507 (New): Implement UmSEL tuner controlhttps://osmocom.org/issues/15072016-02-19T22:52:48Z
<p>Implement <a class="wiki-page new" href="https://osmocom.org/projects/umtrx/wiki/UmSEL">UmSEL</a> tuner control.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1506 (New): Move to the latest stable UHDhttps://osmocom.org/issues/15062016-02-19T22:52:48Z
<p>Move to the latest stable UHD.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Bug #1505 (New): OHM4 footprint incorrecthttps://osmocom.org/issues/15052016-02-19T22:52:48Z
<p>OHM4 footprint incorrect.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1511 (New): Solve Tx and Rx I/Q imbalance for wideband signalshttps://osmocom.org/issues/15112016-02-19T22:52:48Z
<p>Solve Tx and Rx I/Q imbalance for wideband signals.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1509 (New): Store calibration values in EEPROMhttps://osmocom.org/issues/15092016-02-19T22:52:48Z
<p>Store calibration values in EEPROM.</p>
<p>[Migrated from old Google Code tracker]</p> UmTRX - Feature #1504 (New): LMS6002 phase error increases when Rx is enabled and varies with tem...https://osmocom.org/issues/15042016-02-19T22:52:47Z
<p>LMS6002 phase error increases when Rx is enabled and varies with temperature.</p>
<p>[Migrated from old Google Code tracker]</p> SIMtrace 2 - Feature #1463 (New): Add VCC current sensing circuit for SPA & DPA attackshttps://osmocom.org/issues/14632016-02-19T22:48:42Z
<p>It would be pretty good to be able to sense current going to the SIM.</p>
<p>The simple idea is to measure current like this :</p>
<pre>
A B
o o
| |
pwr >----/\/\/\----> to SIM
|
=
|
#
</pre>
<ul>
<li>Ideally use a '4 wire' resistor to make sure you have precision measurement.</li>
<li>Choose value appropriately depending on a typical smart card power consumption.</li>
</ul>
<p>Now, I would include added circuitery to make measurements easier.<br />Because in the simple form there are a couple of issue:</p>
<p>First the signal is gonna be pretty small.<br />Second is that to measure the current across the resistor you can't just put the gnd of your probe on A and the tip on B. That's because the GND of the scope is connected to earth of the mains supply, which in turn is connected to the GND on the PC and so the GND of the simtrace ...</p>
<p>You can either:<br /> - Use two scope probe and use A - B function but this has often less functions that a single probe channel. Also if you only have a 2 channel scope you can't monitor anything else (like the clk line or something).<br /> - Simply probe one point: But then you have the supply noise added to your measurement noise and you don't have absolute values.<br /> - Use a differential probe: Great option ... if you have a couple more k$ to buy one.</p>
<p>So ... all of these suck.</p>
<p>We could have an difference amplifier onboard, however, finding one with multi-MHz bandwidth isn't trivial and they all need dual power rails.</p>
<p>(sorry for the rambling, I'm thinking while writing the ticket ...)</p>
<p>Note that since this feature in its more advanced form may involve expensive / complex components and only be used by very few people. so it could be mounted as a simple 0R with other pad left to be mounted manually by the interested parties.</p>