Marcin Cieslak wrote:
> Andrey Jivsov wrote:
>> 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.
>
> Yes. I wonder what I/O error means in libusb terms.
>
>> 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.
>
> The problem is that FreeBSD kernel does everything that libusb provides
> (and even more) for you. I don't need to worry about almost anything,
> just write the code writing and reading from pipes.
>
> This is a kernel module source which successfully initializes (and does
> nothing more):
>
> http://akson.sgh.waw.pl/~saper/FreeBSD/smartcard/ucyberjack.c
Hi Marcin, we seem to be using the same commands:
you:
error = ucyberjack_command(sc, NAD_PC_TO_RDR, CMD_IFS_REQ);
...
error = ucyberjack_command(sc, NAD_PC_TO_RDR, CMD_SYNC_REQ);
...
err = ucyberjack_status(sc, &status);
I:
if( ifd_device_send( dev, (unsigned char*)"\x00\x04\x00"
"\xe2\xc1\x00\x23", 7 ) != 7 ||
ifd_device_send( dev, (unsigned char*)"\x00\x04\x00"
"\xe2\xc0\x00\x22", 7 ) != 7 )
...
if( (ret=ifd_device_recv( dev, read_buffer, 64, 8000 )) < 7 ) {
>
> I don't have to use timeouts or sleeps to have this working. It is
> actually a very clean code with no quirks. I will try to have a look at
> SVN in a while as well.
You use the same timeout as I do: 8 sec. You don't have a sleep().
Perhaps you can simply remove it?
The issue is that openct ifd driver implementation need to fit into
openct framework. The driver doesn't make the USB calls directly.
Instead, it initializes USB function calls through ifd_device_open and
ifd_device_set_parameters calls. This allows better portability. I also
think that having user-level module is a great advantage v.s. a kernel
module.
>
> I have one questions related to cyberjack implementation:
>
> Do we need to rollout another t=1 implementation to deal with cyberjack?
> couldn't something existing like proto-t1.c be easily attached?
While implementing the cyberJack reader driver I noticed that the
initialization command sequence and subsequent data transfer commands
must happen over the same session of T=1 protocol. This means that the
sequence number bit at the position T1_I_SEQ_SHIFT of protocol control
byte (PCB) must be preserved among initialization, ATR, and data
transfer exchanges. Unfortunately, the generic T=1 protocol object in
proto-t1.c is initialized after the card is initialized and there is no
way to set its state to the intermediate state, so that the transition
from T=1 state I keep in the driver to the object proto-t1.c will be
possible. Perhaps there is a simpler way to trick the code in proto-t1.c
to start using given bit in t1->ns -- I just could not figure this out.
>
> How does cyberjack implement other protocols? Or should I just use T=1
> to send reader-specific commands? How do I switch to, say, T=0?
>
I think you have no option but to sent reader-specific command through
T=1. Furthermore, I only implemented the T=1 support to talk to the
card; I am not sure if T=0 is available for communication with a card.
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
