Bug #5286
closedThe reader sometimes uses a wrong bSeq number in the response
100%
Description
I notice that the reader may answer to a command with an invalid bSeq number, i.e. not the bSeq number used in the command sent to the reader.
For example I have the sequence (complete log attached):
00000033 [139745030735808] -> 000002 65 00 00 00 00 02 0C 00 00 00 00000024 [139745030735808] <- 000002 81 00 00 00 00 02 16 01 00 00 00000011 [139745030735808] -> 000002 65 00 00 00 00 02 0D 00 00 00 00000019 [139745030735808] <- 000002 81 00 00 00 00 02 0C 01 00 00 00000019 [139745030735808] <- 000002 81 00 00 00 00 02 0D 01 00 00 00000009 [139745030735808] -> 000002 65 00 00 00 00 02 0E 00 00 00 00000013 [139745030735808] <- 000002 81 00 00 00 00 02 0E 01 00 00 00000018 [139744979597056] -> 000002 65 00 00 00 00 02 0F 00 00 00 00000022 [139744979597056] <- 000002 81 00 00 00 00 02 0F 01 00 00
First CCID frame: "65 00 00 00 00 02 0C 00 00 00"
The driver sends a 0x65 (PC_to_RDR_GetSlotStatus) command to slot 2 with bSeq = 0x0C
The reader then answers with "81 00 00 00 00 02 16 01 00 00"
Here the bSeq value is 0x16 which is invalid and should be 0x0C as in the driver command.
The driver then sends "65 00 00 00 00 02 0D 00 00 00"
uses bSeq = 0x0D and the reader respond with 2 CCID frames
81 00 00 00 00 02 0C 01 00 00
81 00 00 00 00 02 0D 01 00 00
The first frame uses the bSeq for the initial command.
The second frame uses the correct bSeq number.
The CCID specification in 3.1.3 Bulk-in, Bulk-out pipes write:
To maintain track of all the commands, the Host sets a unique command identifier bSeq
for each command sent to the CCID. To mark command completion the CCID sends the
response with the same bSeq number. The driver will not send a new command to a slot
until the ending response to the last command to that slot is received. If it is determined
that the current command has erred or timed out, the response can be
abandoned/aborted by issuing the class specific abandon/abort command to the control
endpoint.
It is not clear is the bSeq should be unique for the reader or for each slot.
For example I don't know if the reader should support two commands with the same bSeq value but for 2 different slots.
It looks like the sysmoOCTSIM firmware can handle the same bSeq on different slots. So that is nice.
I attach 2 log files:- log_CCID.txt contains only the CCID frame
- log.txt contains the complete pcscd logs
You can search for the message "Duplicate frame detected" in the log.txt file.
It looks like the problem occurs only for the first CCID answer from a slot.
It does not always occurs.
My CCID driver has code to handle frame duplication and the problem occurs only during slot initialization so the problem was not noticed until now.
Files