I am unfortunately encountering frequent usb errors with the itsec-p and
5/2048. ifd_usb_control is failing with EOVERFLOW, which apparently
means that a usb condition known as 'babble' has been detected. I don't
really know what this means or if it's the fault of openct, linux, or
the hardware
I've identified the source of these problems. when the 0xc2/0x02 request
(READ) is sent to the device, the 'reader' device sends back a usb packet
containing all the data it has read from the card since the last read. if
ifd_usb_control was not given a sufficiently large buffer, the EOVERFLOW
error would occur. There are 2 things that trigger this condition:
for T=0, after the TPDU header (5 bytes) has been sent, t0_xcv tries to
read the procedure byte with a single byte read. if the command failed (or
was case 1), then it is likely that the card has produced more than one
byte of data (SW bytes, with or without a procedure byte). The fix for
this (which I have implemented) is to make eutron_recv maintain a buffer,
and always do large reads.
for T=1, things _should_ just work, since the default IFSC/IFSD is 32
bytes, and t1_xcv always asks for 37 bytes (off by one due to an alleged
problem in some version of linux). This is why the ITSEC-I just works. The
ITSEC-P, on the other hand, does not seem to strictly obey T=1. It sends
larger I-Blocks without negotiating them first. The fix for this may be to
unset the IFD_PROTOCOL_BLOCK_ORIENTED parameter in the t1 protocol
since the device does not do framing. This has the added bonus of allowing
eutron_recv to be simplified. I have not figured this all out yet.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
