Bug #4805
closed
The reader is mute after a T=1 data block
Added by rousseau over 3 years ago.
Updated over 3 years ago.
Description
I use the sysmoOCTSIM. The reader declares in dwProtocols the support of T=0 only.
But I am a bad guy and I try with a T=1 card :-)
I get:
> 000000 62 00 00 00 00 00 2E 01 00 00
< 000000 80 14 00 00 00 00 2E 00 00 00 3B FA 94 00 00 81 31 20 43 80 65 A2 01 01 01 3D 72 D6 43 21
No problem with PC_to_RDR_IccPowerOn
> 000000 61 07 00 00 00 00 2F 01 00 00 94 10 00 43 00 20 00
< 000000 82 05 00 00 00 00 2F 40 07 00 00 00 00 00
As expected the PC_to_RDR_SetParameters reports an error on bye 7: bProtocolNum
But then if I send a T=1 block using PC_to_RDR_XfrBlock to the reader I get:
sending: 00 C1 01 00 C0
-> 000000 6F 05 00 00 00 00 30 00 00 00 00 C1 01 00 C0
ccid_usb.c:897:ReadUSB() read failed (1/11): -7 LIBUSB_ERROR_TIMEOUT
The reader does not respond. Not even an error code.
After that any command sent to the reader fails with a USB timeout.
The only way I found to get the reader to work again is to remove the power cable and plug it in again. A On/Off button or a reset button on the reader would help here.
- Assignee set to Hoernchen
thanks for playing with the OCTSIM and reporting your findings here!
I think there may be two problems here:
a) the reader should not get in a weird/locked-up state even after receiving unexpected commands
b) why does the hardware watchdog not reset the device
Assigning to Hoernchen for investigation.
- Priority changed from Normal to Low
laforge wrote:
b) why does the hardware watchdog not reset the device
What is the watchdog timer value?
Maybe I have not waited long enough.
I don't know if the reader is blocked. But unpluging and pluging the USB cable does not make the reader available again.
I think the reader re-enumerates on the USB bus because I was able to see it again. But the CCID command PC_to_RDR_GetSlotStatus (first command the driver sends to check the reader is working) failed with a USB timeout.
Sometime I also got an answer "Slot busy" to PC_to_RDR_GetSlotStatus:
00000037 [139738186602432] -> 000000 65 00 00 00 00 00 00 00 00 00
00000417 [139738186602432] <- 000000 81 00 00 00 00 00 00 40 E0 00
00000027 [139738186602432] commands.c:1250:CmdGetSlotStatus Slot busy
00000013 [139738186602432] -> 000000 65 00 00 00 00 00 01 00 00 00
00000389 [139738186602432] <- 000000 81 00 00 00 00 00 01 40 E0 00
00000028 [139738186602432] commands.c:1250:CmdGetSlotStatus Slot busy
00000013 [139738186602432] -> 000000 65 00 00 00 00 00 02 00 00 00
00000286 [139738186602432] <- 000000 81 00 00 00 00 00 02 40 E0 00
00000013 [139738186602432] commands.c:1250:CmdGetSlotStatus Slot busy
Hope that helps.
There is currently no hardware watchdog since the timers deal with any weird states, and so far it was mostly designed to work with remsim, not with software that deliberately tries to cause major protocol violations by using (currently) completely unsupported protocols like T1.
On Wed, Oct 14, 2020 at 04:46:30PM +0000, Hoernchen [REDMINE] wrote:
There is currently no hardware watchdog since the timers deal with any weird states,
This should be adressed then. I'll create a separate ticket. Any device should always
have a hardware watchdog, IMHO.
and so far it was mostly designed to work with remsim, not with software that deliberately tries to cause major protocol violations by using (currently) completely unsupported protocols like T1.
Well, we have a bit of that in our TTCN3 test suite for CCID. And of course, we always
aim for robust implementations...
rousseau wrote:
I don't know if the reader is blocked. But unpluging and pluging the USB cable does not make the reader available again.
I was able to block the reader again (using a different use case. new bug report in progress).
If I restart pcscd I get the "Slot busy" status as above.
But if I unplug/replug the USB cable the reader is available again.
I don't think that 672a96044c89243f37e73209b2e4edd72e7c9498 fixed the problem.
But the patch in ef393c31e887f548db132b121aefb21649f2d743 made PC_to_RDR_SetParameters to fail for T=1 so the driver does not go further and does not try to communicate.
If the driver ignores the failure of PC_to_RDR_SetParameters the driver continues and I have:
00000002 [139776204199680] commands.c:2285:SetParameters() length: 7 bytes
00000006 [139776204199680] -> 000002 61 07 00 00 00 00 2A 01 00 00 94 10 00 43 00 20 00
00000304 [139776204199680] <- 000002 82 05 00 00 00 00 2A 40 00 00 00 00 00 00
00000004 [139776204199680] commands.c:2311:SetParameters Command not supported or not allowed
00000002 [139776204199680] ifdhandler.c:1106:IFDHSetProtocolParameters() IFSC (TA3) present: 32
00000002 [139776204199680] ifdhandler.c:1114:IFDHSetProtocolParameters() Negotiate IFSD at 0
00000009 [139776204199680] sending: 00 C1 01 00 C0
00000004 [139776204199680] -> 000002 6F 05 00 00 00 00 2B 00 00 00 00 C1 01 00 C0
03019807 [139776204199680] ccid_usb.c:899:ReadUSB() read failed (1/10): -7 LIBUSB_ERROR_TIMEOUT
00000023 [139776204199680] openct/proto-t1.c:777:t1_negotiate_ifsd() fatal: transmit/receive failed
I still have a timeout for the "APDU" 00 C1 01 00 C0. This is not a real APDU since it is a T=1 block.
You can note that in the problematic command we have:
- wLevelParameter = 0 since it is a TPDU level
- dwLength = 5 and that is the message length
So all the conditions tested in 672a96044c89243f37e73209b2e4edd72e7c9498 are correct and the execution of the firmware continues.
The modification of PC_to_RDR_SetParameters for T=1 is enough for me.
You can close this bug.
- Status changed from New to Resolved
- % Done changed from 0 to 100
Also available in: Atom
PDF
