2009/4/28 João Poupino <joao.poup...@data.identity.pt>: > On 25/4/09 10:40, João Poupino wrote: >> >> On 22/4/09 18:15, Martin Paljak wrote: >>> >>> Please provide logs of pcscd and OpenSC. This should not happen. > > > I tried to investigate the problem a little a little further. Here's what > I've found: > > 1. On Ubuntu Linux 8.10, with pcsc-lite 1.5.2 and ccid driver 1.3.10 the > problem persists (previously, I was using MacOS X 10.5.6, with pcsc-lite > 1.4.0 and ccid driver 1.3.10); > > 2. The problem only occurs with some operations. For example, if I run a > simple command like pkcs15-tool -k (read keys), the card never "hangs" > regardless of the number of times I run it. On the other hand, if I try a > pkcs15-tool -D, the first run is ok, on the second time the card just hangs. > > 3. After raising the debug level to 7 in the ccid driver (in Info.plist). I > can see some strange messages coming from the reader on the second try (00 > 82 00 82), the messages keep repeating until I forcibly kill (kill -KILL) > the pcsc-lite daemon. > > For example, on the second run, when the cards hangs: > > winscard_msg_srv.c:317:SHMProcessEventsContext() command TRANSMIT received > by client 7 > winscard.c:1647:SCardTransmit() Send Protocol: T=1 > ifdhandler.c:1165:IFDHTransmitToICC() > usb:0529/0620:libhal:/org/freedesktop/Hal/devices/usb_device_529_620_noserial_if0 > (lun: 0) > commands.c:1931:CmdXfrBlockTPDU_T1() T=1: 5 and 258 bytes > openct/proto-t1.c:570:t1_build() more bit: 0 > sending: 00 00 05 00 CA DF 30 05 25 > -> 000000 6F 09 00 00 00 00 B6 00 00 00 00 00 05 00 CA DF 30 05 25 > <- 000000 80 09 00 00 00 00 B6 00 00 00 00 E1 01 31 D1 00 92 00 92 > received: 00 E1 01 31 D1 > openct/proto-t1.c:413:t1_transceive() wrong response S-BLOCK received > sending: 00 82 00 82 > -> 000000 6F 04 00 00 00 00 B7 00 00 00 00 82 00 82 > <- 000000 80 04 00 00 00 00 B7 00 00 00 00 92 00 92 > received: 00 92 00 92 > openct/proto-t1.c:291:t1_transceive() received: 1, expected: 0, more: 0 > openct/proto-t1.c:296:t1_transceive() Rule 7.2 > sending: 00 82 00 82 > -> 000000 6F 04 00 00 00 00 B8 00 00 00 00 82 00 82 > <- 000000 80 04 00 00 00 00 B8 00 00 00 00 92 00 92 > received: 00 92 00 92 > openct/proto-t1.c:291:t1_transceive() received: 1, expected: 0, more: 0 > openct/proto-t1.c:296:t1_transceive() Rule 7.2 > sending: 00 82 00 82 > -> 000000 6F 04 00 00 00 00 B9 00 00 00 00 82 00 82 > <- 000000 80 04 00 00 00 00 B9 00 00 00 00 92 00 92 > > (The rest of the log continues like this, Ad Eternum).
It looks like your Aladdin token is bogus. It is sending a RDR_to_PC_DataBlock CCID frame: <- 000000 80 09 00 00 00 00 B6 00 00 00 00 E1 01 31 D1 00 92 00 92 containing 9 bytes of data: 00 E1 01 31 D1 00 92 00 92 But the ISO 7816-3 T=1 block inside is just: 00 E1 01 31 D1. The 0x01 is the size of data. The data is 0x31 I have no idea what the "00 92 00 92" extra bytes are used for. And after that T=1 block the token/card and the driver can't synchronise again. Do you also have the problem on Windows with Windows CCID driver? Do you also have the problem using the CCID driver from OpenCT? Bye -- Dr. Ludovic Rousseau _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
