Project

General

Profile

Actions

Bug #5286

closed

The reader sometimes uses a wrong bSeq number in the response

Added by rousseau over 2 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
-
Start date:
10/29/2021
Due date:
% Done:

100%

Spec Reference:
CCID v1.1 3.1.3 Bulk-in, Bulk-out pipes

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

log_CCID.txt log_CCID.txt 12.8 KB rousseau, 10/29/2021 09:32 AM
log.txt log.txt 139 KB rousseau, 10/29/2021 09:43 AM
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)