SIM card related Projects » osmo-ccid-firmware

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

Untested patch in https://gerrit.osmocom.org/c/osmo-ccid-firmware/+/19460, will test it after dinner.

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

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.