O2 Micro OZ776 support for openct

I recently got a dell latitude d830 laptop, which instead of
the spec-less, 
pci smartcard controller from TI that my last machine had,
includes an 
oz776 usb controller. This gave me the opportunity to
implement/test ccid 
character mode support for openct. The patch for this is
attached.

This patch does not address the problem with earlier
versions of this 
device that had broken descriptors. Now that I know about
this problem (I 
don't read opensc-user, so I didn't see the discussion of it
there), I will 
probably work something up in the next few weeks.

T=1 cards that advertise an IFSD of 254 will not work with
this device, due 
to proto-t1.c rejecting 254 byte I-Blocks from
non-block-oriented devices. 
I do not know why t1_xcv behaves this way.

It appears that these devices support a usb-passthrough
mode. At least, the 
first time I inserted a cryptoflex/egate device into the
slot, it appeared 
as a usb device (and I found this: 
<http:/
/www.o2micro.com/news/pr_050822.html>). However, ever
since I 
started using the device with openct, this no longer
happens, even after a 
powercycle. Does anyone know how this is configured?

Lastly, it appears that the usb id was specified incorrectly
in 
etc/Info.plist and etc/openct.conf.

b97/7761 is a usb hub. The actual smartcard devices are
b97/7762 (according 
to  ccid/readers/Oz776S.txt from pcsc) and b97/7772 (my new
machine)

_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

On 20/06/07, Chaskiel M Grundman <cg2vandrew.cmu.edu> wrote:
> I recently got a dell latitude d830 laptop, which
instead of the spec-less,
> pci smartcard controller from TI that my last machine
had, includes an
> oz776 usb controller. This gave me the opportunity to
implement/test ccid
> character mode support for openct. The patch for this
is attached.
>
> This patch does not address the problem with earlier
versions of this
> device that had broken descriptors. Now that I know
about this problem (I
> don't read opensc-user, so I didn't see the discussion
of it there), I will
> probably work something up in the next few weeks.
>
> T=1 cards that advertise an IFSD of 254 will not work
with this device, due
> to proto-t1.c rejecting 254 byte I-Blocks from
non-block-oriented devices.
> I do not know why t1_xcv behaves this way.

Have you tried my CCID driver [1] with such a card?
I made many small changes in the T=1 layer I reused from
OpenCT.

Bye

[1] http://pc
sclite.alioth.debian.org/ccid.html

-- 
  Dr. Ludovic Rousseau
_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

thanks, fixed the info and openct.conf and applied your
patch.

Regards, Andreas

_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel

> Have you tried my CCID driver [1] with such a card?

not in a character mode reader (it turns out that the
"new" o2micro 
devices still have the descriptor bug and are not usable
with ccid for 
pcsc. I do not know why it worked in openct).

your copy of openct's proto-t1.c does not have the bogus
looking code:

         if (t1->block_oriented) {
         ....
         } 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)
{
                         ct_error("receive buffer too
small");
                         return -1;
                 }


ccid's t1_xcv does not bound block[2] at all.

_______________________________________________
opensc-devel mailing list
opensc-devellists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc
-devel