[opensc-devel] ccid_set_protocol, FLAG_AUTO_ATRPARSE (dwFeatures 0x2) handling

2009-11-13 Thread Andrey Jivsov
While trying to fix Broadcom Corp CCID build-in reader (USB ID 
0A5C:5801) found Dell Latitude E6400 and others, I discovered that the 
device's advertised
second bit (0x2) of the dwFeatures flags of USB CCID descriptor causes 
problems for the openct ifd-ccid.c reader driver. The driver cannot 
power up a card.

The bit 0x2 is described in CCID USB document as * 0002h Automatic 
parameter configuration based on ATR data.

If I ignore that bit the ifd-ccid.c powers up the card. If I don't, the 
card doesn't power up.

The first difference between two cases is the set parameters command:

Fails with 0xFB:
  Req : 61 07 00 00 00 00 04 01 00 00 00 00 00 00 00 00 00
  Repl: 82 07 00 00 00 00 04 40 fb 00 00 00 00 00 00 00 00

Succeeds:
  Req : 61 07 00 00 00 00 04 01 00 00 96 10 00 45 00 fe 00
  Repl: 82 07 00 00 00 00 04 00 ff 00 96 10 00 45 00 fe 00

As you can see, the second request, which succeeds, is filled with 
parameters parsed from ATR, while the corresponding parameters are 
zeroes in the first request.

Also see http://www.natisbad.org/E4300/index.html .

I wonder what is the correct interpretation of the 0x02 bit of 
dwFeatures ? Thank you.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


[opensc-devel] A bug in ifd_atr_parse for ATRs with absent TD1...TD4

2009-11-02 Thread Andrey Jivsov
Here is an example ATR for the new RSA SecurID 800:

   3b 0f 80 22 15 e1 5a 00 20 00 29 21 02 31 20 02 00

T0 = 0x0f, meaning that there are 15 historical bytes and zero TDX bytes.

However, the check in ifd_atr_parse does the following:

   if (len = 2 + (atr[1]  0x0f))
   return IFD_ERROR_INVALID_ATR;

I think it should allow len == 2 + (atr[1]  0x0f) and be changed to
 
   if (len  2 + (atr[1]  0x0f))
return IFD_ERROR_INVALID_ATR;

http://www.opensc-project.org/openct/browser/trunk/src/ifd/atr.c#L26

Thank you.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


[opensc-devel] Fix for O2 Micro CCID SC Reader

2009-01-29 Thread Andrey Jivsov
I am attaching the tested patch to the file ifd-ccid.c to add support 
for the reader. The reader's USB IDs that I tested with are 0b97:7762 
and 0b97:7772. Without this patch the ifd-ccid.c code will not work with 
these readers.


The patch is based on the work done in the pcsc-lite project. The patch 
is made against openct-0.6.15-svn-r1127. I didn't make corresponding 
updates to text configuration files.


Thank you.
--- openct-0.6.15-svn-r1127/src/ifd/ifd-ccid.c  2009-01-29 13:03:01.0 
-0800
+++ openct-with-fix/src/ifd/ifd-ccid.c  2009-01-29 13:05:00.0 -0800
@@ -583,22 +583,50 @@
bEndpointAddress;
}
}
if (ok == 7)
break;
intf = NULL;
}
if (!intf)
continue;
if (!intf-extralen) {
-   intf = NULL;
-   continue;
+   int i;
+   /* Buggy O2 Micro CCID SC Reader has zero extra 
len at interface level but not endpoint descriptor.
+* Patch the interface level field and proceed.
+* ProdID 7762 reader is in Dell Latitude D620 
and 7772 is in D630.
+*/
+   if( de.idVendor == 0x0b97  (de.idProduct == 
0x7762 || de.idProduct == 0x7772) )  {
+   ct_error(ccid: extra len is zero, 
patching O2 Micro support);
+   for (i=0; iintf-bNumEndpoints; i++)  {
+   /* find the extra[] array */
+   if( intf-endpoint[i].extralen 
== 54 )  {
+   /* get the extra[] from 
the endpoint */
+   intf-extralen = 54;
+   /* avoid double free on 
close, allocate here */
+   intf-extra = 
malloc(54);
+   if( intf-extra )  {
+   memcpy( 
intf-extra, intf-endpoint[i].extra, 54 );
+   break;
+   }
+   else  {
+   intf = NULL;
+   continue;
+   }
+   }
+   }
+   }
+   else  {
+   intf = NULL;
+   ct_error(ccid: extra len is zero, 
continuing);
+   continue;
+   }
}
 
r = intf-extralen;
_class = intf-extra;
i = 0;
p = _class + i;
/* 0x21 == USB_TYPE_CLASS | 0x1 */
/* accept descriptor type 0xFF if force_parse != 0 */
while (i  r  p[0]  2 
   (p[1] != 0x21 
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] New cyberJack driver contribution: PINPAD, no dependency on kernel module.

2008-01-16 Thread Andrey Jivsov


Marcin Cieslak wrote:
 Ludovic Rousseau wrote:
 On Dec 7, 2007 2:12 AM, Andrey Jivsov [EMAIL PROTECTED] wrote:
 one year ago I mentioned that I would like to contribute the cyberJack
 PINPAD reader driver for OpenCT. I apologize for the delay. Finally, it
 is available.

 I am attaching the patch against SVN rev 1007 (Dec 6 2007).
 Patch commited in revision 1008.
 Please test it.
 
 I have applied this patch to 0.16.4 on my FreeBSD 7.0 (amd64) and I got
 this:
 
 
 # ifdhandler -F -d -r0 cyberjack usb /dev/ugen1
 Debug: ifd_open: trying to open [EMAIL PROTECTED]:/dev/ugen1
 Debug: cyberjack_open: device=usb:/dev/ugen1
 Debug: ifd_sysdep_usb_control: BSD: ifd_sysdep_usb_control(0x6)
 Debug: ifd_sysdep_usb_control: BSD: CTRL bmRequestType 0x80 bRequest 0x6
 wValue 0x100 wIndex 0x0 wLength 0x12
 Debug: ifd_sysdep_usb_control: BSD: CTRL SEND data  00 04 d1 00 08 00 00
 00 a2 79 40 00 00 00 00 00 b8 93
 Debug: ifd_sysdep_usb_control: BSD: CTRL RECV data  12 01 00 01 00 00 00
 10 4b 0c 00 01 00 01 02 03 00 01
 Debug: ifd_usb_control: usb req type=x80 req=x06 val=x0100 ind=x len=18
 Debug: ifd_usb_control: recv  12 01 00 01 00 00 00 10 4b 0c 00 01 00 01
 02 03 00 01
 Error: detected e-com/pp at usb:/dev/ugen1, max packet 16
 Debug: cyberjack_open: trying to claim interface 0 on device, config 1
 Debug: usb_set_params: called. config x01 ifc x00 eps x02/x82
 Debug: ifd_sysdep_usb_claim_interface: interface=0 (not yet implemented)
 Debug: cyberjack_open: successfully claimed interface
 Debug: cyberjack_open: cyberjack: returning device 0x800d18080
 Debug: cyberjack_activate: called (dev = 0xd18080).
 Debug: usb_send: usb send to=x02
 Debug: usb_send: send  00 04 00 e2 c1 00 23
 Debug: ifd_sysdep_usb_bulk: endpoint=2 direction=0
 Debug: ifd_sysdep_usb_bulk: wrote buffer[7]= 00 04 00 e2 c1 00 23
 Debug: usb_send: usb send to=x02
 Debug: usb_send: send  00 04 00 e2 c0 00 22
 Debug: ifd_sysdep_usb_bulk: endpoint=2 direction=0
 Debug: ifd_sysdep_usb_bulk: wrote buffer[7]= 00 04 00 e2 c0 00 22
 Debug: ifd_sysdep_usb_bulk: endpoint=2 direction=1
 Error: usb_bulk read failed: Input/output error
 Error: cyberjack: failed to activate 2
 Error: cyberjack: failed to activate 2: no cookie
 Error: Failed to activate reader; err=-1

Marcin, thank you for reporting this.

Looks like cyberjack_activate() fails on the first cyberjack_recv_t1.

I would try to increase/decrease the value in ifd_msleep( 100 ) before 
cyberjack_recv_t1 to see if this makes the difference. I will try to 
reproduce it this week.

 
 I started my own attempt to write my own, kernel FreeBSD driver.
 My driver has no problems with sending initialization sequences
 attempted above.

If you look at the source code of ifd/ifd-cyberjack.c, you are long way 
along the path to make it work, once you are done with initialization. 
Why not enhance the version in SVN, which already works, with more 
reliable initialization sequence that you developed? Thank you.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


[opensc-devel] New cyberJack driver contribution: PINPAD, no dependency on kernel module.

2007-12-06 Thread Andrey Jivsov

Hello,

one year ago I mentioned that I would like to contribute the cyberJack 
PINPAD reader driver for OpenCT. I apologize for the delay. Finally, it 
is available.


I am attaching the patch against SVN rev 1007 (Dec 6 2007).

I tested that I can send commands to the card through 
ifd_card_command(). I also tested PINPAD authentication through 
ifd_card_perform_verify(). I ran my tests on RedHat Fedora Core 7 and 8.


The advantage of my implementation is that the code is completely 
contained in the attached file and only depends on OpenCT framework. In 
particular, it doesn't depend on kernel module or additional libraries.


I hope it will get integrated into the set of included drivers.


Some of my tests follow:

# /sbin/rmmod cyberjack; ./src/ifd/ifdhandler -d -d -d -d -d -d -F 
cyberjack usb /dev/bus/usb/004/005


# openct-tool list
  0 cyberjack reader

# openct-tool atr
Detected cyberjack reader
Card present, status changed
ATR: 3b b7 94 00 81 31 fe 65 53 50 4b 32 33 90 00 d1 90 01


Thank you.
Index: src/ifd/init.c
===
--- src/ifd/init.c	(revision 1007)
+++ src/ifd/init.c	(working copy)
@@ -41,6 +41,8 @@
 	ifd_starkey_register();
 	ifd_towitoko_register();
 	/* ifd_wbeiuu_register();	driver not working yet */
+	ifd_cyberjack_register();	
+
 	/* ccid last */
 	ifd_ccid_register();
 
Index: src/ifd/ifd-cyberjack.c
===
--- src/ifd/ifd-cyberjack.c	(revision 0)
+++ src/ifd/ifd-cyberjack.c	(revision 0)
@@ -0,0 +1,858 @@
+/*
+	Cyberjack reader. 
+	
+	Tested with USBID 0c4b:0100. These are red readers: one with LCD, 
+	another one without. 
+	
+	Supports PIN-pad authentication. 
+
+	One advantage of this implementaiton is that everything needed to support 
+	cyberjack is in this single file, as it is done for other OpenCT reader
+	drivers.
+
+	This code doesn't unload cyberjack kernel module, with which it will
+	conflict. To do this call rmmod cyberjack after the device is plugged in, 
+	or better add blacklist cyberjack to modprobe.conf.
+	
+	TODO: cleanup improvised T=1 communication with the reader.
+
+	Written by Andrey Jivsov in 2006. [EMAIL PROTECTED] or [EMAIL PROTECTED]
+
+	$Id: $
+*/
+
+#include internal.h
+#include usb-descriptors.h
+#include stdlib.h
+#include string.h
+#include stdarg.h
+#include unistd.h
+#include stdio.h
+#include ctbcs.h
+
+static const unsigned T1_I_SEQ_SHIFT=6;
+static const unsigned T1_R_SEQ_SHIFT=4;
+static const unsigned DATA_NAD = (04/*card*/) | 2/*host*/;
+
+/* Pseudo-slot referencing the reader. The reader exposes only 
+ * one slot corresponding to the card and is at index 0. 
+ */
+static const int cyberjack_reader_slot = (OPENCT_MAX_SLOTS-1);
+static const int cyberjack_card_slot = 0;
+
+struct cyberjack_t1_state {
+	unsigned ns;
+	ifd_device_t * dev;
+	ifd_protocol_t *proto;
+	int verify_initiated;
+	int verify_timeout;		// in seconds
+};
+
+#if !defined(ifd_msleep)  !defined(BG_MODULE)
+#define ifd_msleep(x) usleep(x * 1000)
+#endif
+
+#if 1
+#define cyberjack_ct_error(max_len, fmt, args... ) \
+	ct_error( fmt, ##args );
+#else
+/* define your own here for testing */
+#define cyberjack_ct_error(max_len, fmt, args...) \
+	ct_error( max_len, fmt, ##args );
+#endif
+
+#if 1
+#define cyberjack_ifd_debug( level, max_len, args... )  \
+	ifd_debug( level, ##args )
+#else
+/* define your own here for testing */
+#define cyberjack_ifd_debug( level, max_len, args... )  \
+	ifd_debug( level, max_len, ##args )
+#endif
+
+static unsigned int get_checksum( void *p, int len )  {
+	int i;
+	unsigned char *pp = p;
+	unsigned ret=0;
+	for( i=0; ilen; i++ )
+		ret ^= pp[i];
+	return ret;
+}
+
+inline static unsigned get_nad_mirrow( unsigned nad )  {
+	return (((nad0xf)4) | (nad4));
+}
+
+static int cyberjack_init_proto( ifd_reader_t *reader, struct cyberjack_t1_state *state )  {
+	ifd_protocol_t *p;	
+	if( state-proto==NULL )  {
+		p = ifd_protocol_new(IFD_PROTOCOL_T1, reader, DATA_NAD);
+		if (p == NULL)  {
+			cyberjack_ct_error( 40, cyberjack: internal error: cannot allocate protocol object );
+			return -1;
+		}
+		state-proto = p;
+	}
+	else  {
+		cyberjack_ct_error( 40, cyberjack: internal error: protocol already initialized );
+		return -1;
+	}
+	return 0;
+}
+
+static void cyberjack_free_proto( struct cyberjack_t1_state *state )  {
+	if( state-proto )
+		ifd_protocol_free( state-proto );
+}
+
+/*
+ * Initialize the device
+ */
+static int cyberjack_open(ifd_reader_t * reader, const char *device_name)
+{
+ifd_device_t *dev;
+struct ifd_usb_device_descriptor de;
+	ifd_device_params_t params;
+	const int device_name_len = strlen(device_name);
+	int ret;
+
+	(void)device_name_len;
+
+	cyberjack_ifd_debug(1, 40+device_name_len, device=%s, device_name);
+	 
+	reader-name = cyberjack

Re: [opensc-devel] Resetting USB device in OpenCT

2006-11-10 Thread Andrey Jivsov

Andreas Jellinghaus wrote:

Andrey Jivsov wrote:
I was thinking to implement the cyberJack PIN pad reader support. 


that is a good idea! if I can be of any help please let me know.
I thought about it myself, but never found time for that (and most
likely neither will anytime soon, so please go ahead!).


Hello Andreas and everyone who responded. Sorry for slow reply. I wanted 
to try a few things first before replying to ensure that my answer is 
precise.


I will write up a question today about integration of PIN-pad 
authentication. It's unclear to me how this should work in openct framework.




Unfortunately, I ran into a problem when I must reset the reader with 
usb_reset(device_handle). However, I don't see ifd_device_ops.reset 
implemented. Is there a way to cleanly invoke the USB device reset 
functionality?


I attached the patch that I think is needed. It would be nice to 
integrate it into the tree.


Hi Andrey,

thanks for the patch, commited. I hope it doesn't cause side effects.
the proble with usb reset is that the device will get a new device
number on the usb bus, and thus the old openct ifdhandler will need
to die and exit, and udev will spawn a new one for the new device.

so usb reset is like unplugging and plugging in again. except for the
absolute worst case scenario it should never be necessary to do that.


Thank you for adding the patch. Turns out, on Linux RedHat FC5 with 
2.6.18 kernel at least, this is not the case. The device will retain its 
address. I assume there is a logic in the kernel to try to reuse the 
device address, since the kernel knows that the current device is being 
reset.


However, I now realize that usb_reset may not be so clean on other 
systems and perhaps is not guaranteed to behave exactly as I described 
in mentioned kernel under race conditions.


Still, I tried multiple times and confirm that resetting the device is 
necessary to make cyberJack power-up the card.





Andreas


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


Re: [opensc-devel] Resetting USB device in OpenCT

2006-11-10 Thread Andrey Jivsov

Martin Preuss wrote:

Hi,

On Friday 03 November 2006 00:40, Andrey Jivsov wrote:
[...]

I was thinking to implement the cyberJack PIN pad reader support.

[...]

Just curious: Are you implementing support for both types of Cyberjack devices 
(0x100 and 0x300, even though they look identical they are very different 
internally)?



Regards
Martin



Only tried with 0c4b:0100.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


Re: [opensc-devel] Resetting USB device in OpenCT

2006-11-10 Thread Andrey Jivsov

Martin Preuss wrote:

Hi,

On Friday 03 November 2006 00:40, Andrey Jivsov wrote:
[...]

I was thinking to implement the cyberJack PIN pad reader support.
Unfortunately, I ran into a problem when I must reset the reader with
usb_reset(device_handle). However, I don't see ifd_device_ops.reset

[...]

What problem did you run into? I'm just asking because I recently took over 
maintenance of the CTAPI driver for Linux provided by the manufacturer and 
might be of assistence.



regards
Martin



I was testing without cyberjack kernel module. The reset was necessary 
to initialize the reader.  The reader would not send even a single byte 
to the host without this USB reset.

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


[opensc-devel] T1 protocol implementation for 256 byte response

2006-09-26 Thread Andrey Jivsov
I tried new ifd-eutron.c with 2048 bit key decryption and ran into an 
issue in t1-proto.c.


Please take a look at the following patch. It restores regression 
introduced by new Eutron driver for decryption with 2048 bit key. 
Without this change the code bellow fails with receive buffer too 
small. This is because Eutron driver now sets T1 protocol.


It seems to me that values 0-254 are valid inclusively for T1 
information field. The constant T1_BUFFER_SIZE defined in this file 
agrees with this change.


Am I correct in the following change? Thank you.

[EMAIL PROTECTED] openct-cvs]$ diff -up -U 10 src/ifd/proto-t1.c 
src/ifd/proto-t1.c-fixed

--- src/ifd/proto-t1.c  2006-09-26 20:12:32.0 -0700
+++ src/ifd/proto-t1.c-fixed2006-09-26 20:12:24.0 -0700
@@ -555,21 +555,21 @@ int t1_xcv(t1_state_t * t1, unsigned cha
m = block[2] + 3 + t1-rc_bytes;
if (m  n)
n = m;
}
} else {
/* Get the header */
if (ifd_recv_response(prot, block, 3, timeout)  0)
return -1;

n = block[2] + t1-rc_bytes;
-   if (n + 3  rmax || block[2] = 254) {
+   if (n + 3  rmax || block[2]  254) {
ct_error(receive buffer too small);
return -1;
}

/* Now get the rest */
if (ifd_recv_response(prot, block + 3, n, t1-timeout)  0)
return -1;

n += 3;
}
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


[opensc-devel] ifd_time_elapsed magic

2006-04-11 Thread Andrey Jivsov

I am looking at

long ifd_time_elapsed( struct ifd_time *then )
{
struct timeval now, delta, then_tv;

then_tv.tv_sec = then-p1;
then_tv.tv_usec = then-p2;

gettimeofday(now, NULL);
timersub(now, then_tv, delta);
return delta.tv_sec * 1000 + (delta.tv_usec % 1000);
}

what does last line do? tv_sec is in seconds and tv_usec is in 
microseconds. The sum adds milliseconds from tv_sec and lowest 1000 
microseconds. Should it be


return delta.tv_sec * 1000 + (delta.tv_usec / 1000);

instead? Thanks!
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


Re: [opensc-devel] ifd_time_elapsed magic (corrected)

2006-04-11 Thread Andrey Jivsov

[corrected to the actual source from CVS]

I am looking at

long ifd_time_elapsed(struct timeval *then)
{
struct timeval now, delta;

gettimeofday(now, NULL);
timersub(now, then, delta);
return delta.tv_sec * 1000 + (delta.tv_usec % 1000);
}

what does last line do? tv_sec is in seconds and tv_usec is in 
microseconds. The sum adds milliseconds from tv_sec and lowest 1000 
microseconds. Should it be


return delta.tv_sec * 1000 + (delta.tv_usec / 1000);

instead? Thanks!
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel


[opensc-devel] Gem e-Seal with CCID driver (USB ID 08e6:3438)

2006-03-31 Thread Andrey Jivsov

When I try to select a root file on this card by sending SELECT 3f00
file, the first response to the APDU returns SW 67 00  'Wrong length'.

Is it a specific problem to the card or to the ccid driver? I don't have
access to other CCID readers at the moment, but the same APDU works with
etoken and ikey3k.

Thank you.

-

ifdhandler ccid my USB device
returns (slightly edited):

Reader drivers:
ccid, towitoko, smartboard, pertosmart1030, b1, kaan, ikey3k,
ikey2k, gempc, eutron, etoken64, etoken, egate, cm4000,
cardman, acr30u
Protocols:
T=0, T=1, GBP, transparent, I2C short, I2C long, 2Wire,
3Wire, Eurochip Countercard
Debug: ifd_open: trying to open ccid@/proc/bus/usb/002/003
Debug: ifd_usb_control: usb req type=x80 req=x06 val=x0100 ind=x len=18
Debug: ifd_usb_control: recv 12 01 10 01 00 00 00 08 e6 08 38 34 00 01 
01 02 00 01

Debug: ifd_usb_control: usb req type=x80 req=x06 val=x0201 ind=x len=8
Debug: ifd_usb_control: recv 09 02 5d 00 01 01 00 80
Debug: ifd_usb_control: usb req type=x80 req=x06 val=x0201 ind=x len=93
Debug: ifd_usb_control: recv 09 02 5d 00 01 01 00 80 32 09 04 00 00 03 
0b 00 00 00 36 21 00 01 00 07 03 00 00 00 a0 0f 00 00 a0 0f 00 00 00 00 
2a 00 00 16 40 05 00 00 fe 00 00 00 00 00 00 00 00 00 00 00 30 02 01 00 
0f 01 00 00 00 00 00 00 00 01 07 05 02 02 40 00 00 07 05 82 02 40 00 00 
07 05 81 03 08 00 18

Debug: skipped 1 class/vendor specific interface descriptors
Debug: ccid_open_usb: reader type is 1.
Debug: usb_set_params: called. config x ifc x00 eps x02/x82
Debug: ifd_usb_begin_capture: usb capture type=1 ep=x81 maxpacket=8
Debug: usb_submit_urb: submit urb 0x8067768
Debug: ifd_usb_capture: called, timeout=100 ms.
Debug: ifd_usb_capture: usb capture: Command timed out
Debug: ccid_command: sending:65 00 00 00 00 00 00 00 00 00
Debug: usb_send: usb send to=x02
Debug: usb_send: send 65 00 00 00 00 00 00 00 00 00
Debug: usb_recv: usb recv from=x82
Debug: usb_recv: recv 81 00 00 00 00 00 00 00 00 00
Debug: ccid_command: received:81 00 00 00 00 00 00 00 00 00
Debug: ccid_card_status: probed result: 3
Debug: ccid_card_reset: called. powering on with manual voltage selection
Debug: ccid_card_reset: Trying voltage parameter 1
Debug: ccid_command: sending:62 00 00 00 00 00 01 01 00 00
Debug: usb_send: usb send to=x02
Debug: usb_send: send 62 00 00 00 00 00 01 01 00 00
Debug: usb_recv: usb recv from=x82
Debug: usb_recv: recv 80 11 00 00 00 00 01 00 00 00 3b 6d 00 00 80 31 80 
 65 b0 83 01 02 90 83 00 90 00

Debug: ccid_command: received:80 11 00 00 00 00 01 00 00 00 3b 6d 00 00
80 31 80 65 b0 83 01 02 90 83 00 90 00
Debug: ifd_protocol_select: atr=3b 6d 00 00 80 31 80 65 b0 83 01 02 90 
83 00 90 00

Debug: ifd_protocol_select: default T=0, supported protocols=0x1
Debug: ccid_set_protocol: called for proto {T0=1,T1=0}
Debug: ifd_atr_parse: atr=3b 6d 00 00 80 31 80 65 b0 83 01 02 90 83 00 90 00
Debug: ifd_atr_parse: supported protocols=0x1, default protocol=0
Debug: ccid_command: sending:61 05 00 00 00 00 02 00 00 00 11 00 00 0a 00
Debug: usb_send: usb send to=x02
Debug: usb_send: send 61 05 00 00 00 00 02 00 00 00 11 00 00 0a 00
Debug: usb_recv: usb recv from=x82
Debug: usb_recv: recv 82 05 00 00 00 00 02 00 00 00 11 00 00 0a 00
Debug: ccid_command: received:82 05 00 00 00 00 02 00 00 00 11 00 00 0a 00
card_reset returned 17, ATR 3b:6d:00:...
Debug: ifd_protocol_transceive: cmd: SELECT (00 a4 00 0c 02 3f 00)
Debug: ccid_transparent: called.
Debug: ccid_command: sending:6f 07 00 00 00 00 03 00 00 00 00 a4 00 0c 
02 3f 00

Debug: usb_send: usb send to=x02
Debug: usb_send: send 6f 07 00 00 00 00 03 00 00 00 00 a4 00 0c 02 3f 00
Debug: usb_recv: usb recv from=x82
Debug: usb_recv: recv 80 02 00 00 00 00 03 00 00 00 67 00
Debug: ccid_command: received:80 02 00 00 00 00 03 00 00 00 67 00
Debug: ifd_protocol_transceive: resp: SW 'Wrong length' (67 00)
ifd_card_command returned 2


From /proc/bus/usb/devices:

T:  Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=08e6 ProdID=3438 Rev= 1.00
S:  Manufacturer=Gemplus
S:  Product=USB SmartCard Reader
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=0b(scard) Sub=00 Prot=00 Driver=(none)
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=24ms

uname: Linux tcm 2.6.15.6-mh2 #3 Thu Mar 16 20:57:21 PST 2006 i686 i686 
i386 GNU/Linux

(2.6.15.6 kernel with bluez patches).


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel