Bug #4684
closed
osmo-ccid-firmware problems with osmo-remsim-bankd
Added by laforge almost 4 years ago.
Updated almost 4 years ago.
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)
- 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)
the latter is of course bogus. The card certainly didn't send 3f00 before the status word...
- 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.
this is using build 0.2.19-25d4
of the firmware, which is the last version we have available as a binary download.
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.
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.
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.
suspicion confirmed: The answer to 00A40004043F003F00
is 3F003F006700
- % Done changed from 10 to 30
- % Done changed from 30 to 80
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
Also available in: Atom
PDF