Bug #4684
closedosmo-ccid-firmware problems with osmo-remsim-bankd
100%
Description
I observed this when using osmo-remsim-bankd + pcsc-lite:
- with a 3rd party reader
- I send
00 a4 00 00 02 3f 00
to the card - I receive
6a 86
from the card (sysmoUSIM-SJS1)
- I send
- with sysmoOCTSIM
- I send
00 a4 00 00 02 3f 00
to the card - I receive
3f 00 6a 86
from the card (sysmoUSIM-SJS1)
- I send
the latter is of course bogus. The card certainly didn't send 3f00 before the status word...
Updated by laforge over 3 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 10
this definitely seems unrelated to osmo-remsim-bankd, as I get the following logs from bankd itself:
[003 CONN_CLIENT_MAPPED_CARD] bankd_main.c:701 tpduModemToCard(00a40000023f00) [003 CONN_CLIENT_MAPPED_CARD] bankd_pcsc.c:221 : OK [003 CONN_CLIENT_MAPPED_CARD] bankd_main.c:727 tpduModemToCard response from card: 3f006a86
So it's clear that at least pcsc-lite already has the extraneous bytes at the start of the response.
Updated by laforge over 3 years ago
this is using build 0.2.19-25d4
of the firmware, which is the last version we have available as a binary download.
Updated by Hoernchen over 3 years ago
So it's receiving the last two bytes that are being sent out, the question is: why, apparently the rx timing is off, and: why only the last 2, not one, not three.
Updated by laforge over 3 years ago
The problem also is visible already on the CCID level.
This is from the CCID_Tests.ttcn test suite (response to 00A40004023F00
):
20:01:20.854851 17 CCID_Tests.ttcn:175 Message enqueued on CCID from CCID(15) @CCID_Types.CCID_PDU : { hdr := { bMessageType := RDR_to_PC_DataBlock (128), dwLength := 4, bSlot := 1, bSeq := 211 }, hdr_in := { bStatus := { bmICCStatus := CCID_ICC_STATUS_PRES_ACT (0), RFU := '0000'B, bmCommandStatus := CCID_CMD_STATUS_OK (0) }, bError := CCID_ERR_CMD_NOT_SUPPORTED (0) }, u := { DataBlock := { bChainParameter := 0, abData := '3F006156'O } } } id 1003
The response should be 6156
without the repetition of the 3F00
in front.
Updated by laforge over 3 years ago
I'm not sure if it
Hoernchen wrote:
So it's receiving the last two bytes that are being sent out, the question is: why, apparently the rx timing is off, and: why only the last 2, not one, not three.
I would think it is an artefact of the way how we store the APDU in msgb or the like: The command part is stored in front of the response part. So I think if the command part was longer (Lc > 2) then we would also have all of those bytes in the response. Will test.
Updated by laforge over 3 years ago
suspicion confirmed: The answer to 00A40004043F003F00
is 3F003F006700
Updated by laforge over 3 years ago
- % Done changed from 10 to 30
Untested patch in https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/19460, will test it after dinner.
Updated by laforge over 3 years ago
- % Done changed from 30 to 80
patch seems to fix the problem. I'm also submitting a patch to update CCID_Tests.ttcn to ensure the length of he response to SELET MF is always two octets long:
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/19465
Updated by laforge over 3 years ago
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
patch merged. Version 0.2.22 and higher include the fix. Automatic build should show up at https://ftp.osmocom.org/binaries/osmo-ccid-firmware/all/ shortly.