Actions
Bug #5419
opencardem errors with higher baud rate
Start date:
01/25/2022
Due date:
% Done:
60%
Spec Reference:
Description
Setup is as follows:
- sysmoISIM-SJA2 in built-in CCID reader of my Thinkpad x260
- SIMtrace2 with cardem firmware 'master' (0.8.1.7-ea9a) hooked up via FPC to
- CCID reader "Identive CLOUD 2700 F"
simtrace2-cardem-pcsc
to forward request from IdentiveCCID -> SIMtrace -> st2-cardem-pcsc -> builtin-CCID
This works fine with F/D ratio 372, and also works fine in most cases with F/D ratio 16.
However, sometimes with ratio 16, things break down at some point.
log output of cardem firmware¶
-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)two things noticable:
- the 'N' being printed by card_emu as waiting time extension
- the last TPDU header
02 00 a4 00 04
doesn't look like a TPDU header: The 02 seems wrong, the TPDU likely starts with00 a4
.
situation on "Identive CCID reader" side¶
pySim-shell "export" shows:
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'
simtrace2-cardem-pcsc¶
=> 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
it also agrees that this last APDU is somehow wrong and cannot determine the APDU case.
USB communication¶
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.
Files
Actions