OpenCT API question

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

OpenCT API question

Laurent Pinchart
Hi everybody,

I got a question about the purpose of the set_protocol function.

From what I understand, its purpose is to set the smart card communication
protocol, which is negociated between the card and the reader at reset time
(PPS exchange). However, it seems there is no restriction about when that
function can be called, and the pertosmart driver even performs a card reset
in set_protocol, which (obviously) resets the card and invalidates the ATR.
That's quite a side effect in my opinion...

OpenCT only calls set_protocol before resetting the card, but exports the
function (ct_card_set_protocol) to the client, making it possible to select a
different protocol after reset.

It's not clear to me if the original purpose to set_protocol was to select the
protocol before reset only, or at runtime as well, which doesn't make much
sense to me.

Maybe the design decision was made when the only supported readers didn't
perform a PPS exchange automatically after reset, but required a manual
operation to select the protocol ? But in that case, why export set_protocol
to the client, as it is called by ifd_card_request anyway ? How should
readers which require the protocol to be selected before reset be handled ?

Comments are welcome.

Laurent Pinchart
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Priit Randla


    Hello,  

Laurent Pinchart wrote:

>Hi everybody,
>
>I got a question about the purpose of the set_protocol function.
>
>From what I understand, its purpose is to set the smart card communication
>protocol, which is negociated between the card and the reader at reset time
>(PPS exchange). However, it seems there is no restriction about when that
>function can be called, and the pertosmart driver even performs a card reset
>in set_protocol, which (obviously) resets the card and invalidates the ATR.
>That's quite a side effect in my opinion...
>  
>
    If I recall correctly, it was me who added this function to openct.
    The reason I did it was to make it possible for clients using openct
through
    pcsc-lite layer(openct as pcsc-lite 'driver') to use
   something like:
   rv = SCardConnect(hContext, &mszReaders,
                SCARD_SHARE_SHARED,  SCARD_PROTOCOL_T1,
                &hCard, &dwPref);
    ... when the default protocol after reset is T=0.

  It just didn't work otherwise.
  Look at src/pcsc.c :
IFDHSetProtocolParameters(DWORD Lun, DWORD Protocol,
  UCHAR Flags, UCHAR PTS1, UCHAR PTS2, UCHAR PTS3)

>OpenCT only calls set_protocol before resetting the card, but exports the
>function (ct_card_set_protocol) to the client, making it possible to select a
>different protocol after reset.
>  
>
    Yes, this should be adressed somehow. According to 'Smart card handbook'
  it's only permitted to do PPS once right after reset.

>
>Comments are welcome.
>
>Laurent Pinchart
>  
>

Priit


_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Andreas Jellinghaus-2
In reply to this post by Laurent Pinchart
I'm no expert on this topic (all my usb crypto tokens talk
T=1 to me and I wouldn't even know how to try T=0).

but as far as I know you need to first reset the card
and then you can (optionaly) change the protocol.

if the protocol change does yet another reset: well,
not needed but doesn't hurt either, so if that is easier: ok.

change protocoll can't happen once you start sending APDUs.
but code wise what happens in undefined. Do we need code to
prevent mis-use? I think we don't, better invest time in good
documentation and examples.

btw: I'm not sure of this - does the card after protocol
selection send a new atr? can that one be a different atr?

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Laurent Pinchart
Hi Andreas,

> I'm no expert on this topic (all my usb crypto tokens talk
> T=1 to me and I wouldn't even know how to try T=0).

I'm no expert either. The Belgian eID card talks T=0, and I wouldn't even know
how to try T=1 ;-)

> but as far as I know you need to first reset the card
> and then you can (optionaly) change the protocol.

I don't know about synchronous devices (I2C and the like), but for
asynchronous devices, what happens according to the ISO-7816 standard is
this. Upon cold or warm reset, the card transmits the ATR and enters either
specific mode or negociable mode. In specific mode, the card basically says
"ok, I selected a protocol, now use it". In negociable mode, a PPS exchange
(I'm not sure what PPS stands for) is performed to negociate a protocol
between the reader and the card. Upon successfull negociation, the card
enters specific mode using the selected protocol.

Now, I can imagine three classes of readers. The first class is for dumb
readers, and expects the host to perform the PPS exchange manually. As far as
I know, there's no support for such readers in OpenCT, at least not in a
generic way (such a reader could be supported by coding PPS exchange manually
in the driver). The second class is for smarter readers which can do PPS
exchange, but need to be instructed to do so. For those readers, the expected
sequence of operation is

Host         Reader       Card
   --Reset-->     --Reset-->
   <--ATR--       <--ATR--
   --Do PPS-->    --PPS-->
                  <--PPS--
                  --PPS-->
   <--PPS Done--  <--PPS--

The third class is for the readers which will perform the PPS exchange
automatically. Those readers (the ACR30U is one of them) need to be told
which protocol to select *before* sending the reset command.

Now, let's have a look at what currently happens in OpenCT. Class one is not
supported at the moment, class two needs a set_protocol after reset and class
three needs a set_protocol before reset. When the card is reset, the driver
has the opportunity to select a protocol. If it does, fine, OpenCT will leave
it as-is. If it doesn't, OpenCT will try to select a protocol automatically.
It will decode the ATR and choose the default protocol, calling set_protocol
if the driver has such a function.

How should this all be handled by OpenCT ? There are two solutions. The first
one is to call set_protocol before reset, to select the prefered protocol.
The following reset will then try to select that protocol. The second one is
to call allow set_protocol calls at any time, in which case set_protocol will
perform a reset and try to select the protocol. Does anyone know what
assumptions are being made by code that uses OpenCT ? I'm personally in favor
of the first solution, as it is cleaner and easier to implement. We could
even get rid of set_protocol completely on the driver side for asynchronous
cards, by passing a protocol parameter to card_reset and card_request.

I'd like to have the driver writer's opinion here.

> if the protocol change does yet another reset: well,
> not needed but doesn't hurt either, so if that is easier: ok.

It's actually more complicated. The driver needs to remember which protocol
was selected when doing a reset to select that protocol again, and to perform
a reset and invalidate data that it doesn't own when doing a set_protocol.

> change protocoll can't happen once you start sending APDUs.
> but code wise what happens in undefined. Do we need code to
> prevent mis-use? I think we don't, better invest time in good
> documentation and examples.

I agree with you, if the API documentation clearly states how set_protocol can
and must not be used, I'm fine with it.

> btw: I'm not sure of this - does the card after protocol
> selection send a new atr? can that one be a different atr?

The card doesn't send a new ATR when selecting a protocol. It sends the ATR
and then performs the PPS exchange. Selecting another protocol requires a
card reset, and thus results in the card sending an ATR. Have a look at
ISO-7816-3 (you can find draft documents at http://www.sc17.com/).

Regards,

Laurent Pinchart

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Laurent Pinchart
Hi everybody,

after further investigation, I found out that some drivers actually perform
PTS exchange (btw, does someone know if the protocol selection process is
called PTS or PPS ? ISO-7816-3 draft 2004-10-1 talks about PPS, while OpenCT
uses PTS). The cardman driver builds the PTS packet itself, and the ccid
driver calls ifd_build_pts.

If I'm not mistaken, only the Kaan driver supports synchronous cards, all the
others only support asynchroboys cards. Some of the drivers set the protocol
before doing a card reset (ACR30U), others do it after reset (host-controlled
or manually triggered reader-controlled PTS exchange).

It seems to me that we should get rid of set_protocol in ifd_driver_ops
completely, and add a protocol parameter to card_reset and card_request. That
way, the driver can set the protocol before or right after reset, as needed
by the reader. Calling set_protocol after the protocol has been selected,
which currently results in broken behaviour for most drivers, will not be
possible anymore. The user will have to reset the card explicitely. The
possible side effects of set_protocol will thus disappear, everybody is happy
and the world is a better place to live in (well, I wish :-)).

For synchronous cards, the protocol is passed to sync_read and sync_write
anyway, so no problem there.

Comments anyone ?

Laurent Pinchart
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Michael Haardt-3
In reply to this post by Laurent Pinchart
> It seems to me that we should get rid of set_protocol in ifd_driver_ops
> completely, and add a protocol parameter to card_reset and card_request.

If there is a value for using the default protocol, that sounds like a
very good idea to me.

Michael
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Priit Randla
In reply to this post by Laurent Pinchart
Laurent Pinchart wrote:

    Hi,

>Hi everybody,
>
>....
>It seems to me that we should get rid of set_protocol in ifd_driver_ops
>completely, and add a protocol parameter to card_reset and card_request
>
Well, that would break both PC/SC and CTAPI, which do have
SetProtocolParameters and
CTBCS_INS_SET_INTERFACE_PARAM to modify interface settings between SC
and reader.

>. That
>way, the driver can set the protocol before or right after reset, as needed
>by the reader. Calling set_protocol after the protocol has been selected,
>which currently results in broken behaviour for most drivers, will not be
>possible anymore. The user will have to reset the card explicitely. The
>possible side effects of set_protocol will thus disappear, everybody is happy
>and the world is a better place to live in (well, I wish :-)).
>  
>
    You wish. For pc/sc and ctapi users God himself has granted the
right to modify interface parameters. ;p
Maybe we should replace set_protocol with do_pts (or do_pps) (Protocol
Type Selection or Protocol Parameter Selection).
Or make set_protocol call do_pts or something. Or maybe we(somebody else
;-))  just have to implement sc state machine with
possible transitions between negotiable mode and specific mode? Then
set_protocol could just check if the card is in negotiable mode
before proceeding.


>Comments anyone ?
>
    Didn't you see my last e-mail to the list?

>Laurent Pinchart
>_______________________________________________
>  
>
Priit,
gone through driver writing already.

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Laurent Pinchart
> >It seems to me that we should get rid of set_protocol in ifd_driver_ops
> >completely, and add a protocol parameter to card_reset and card_request
>
> Well, that would break both PC/SC and CTAPI, which do have
> SetProtocolParameters and
> CTBCS_INS_SET_INTERFACE_PARAM to modify interface settings between SC
> and reader.

PC/SC defines both a client API and an IFD driver API. The driver API has
seperate reset/set protocol functions (IFDHPowerICC and
IFDHSetProtocolParameters), but the client API only defines a single function
(SCardConnect). I expect the PC/SC implementation to call IFDHPowerICC and
IFDHSetProtocolParameters in that order during SCardConnect. This means that
readers which need to know what protocols to negociate *before* reset can't
be supported properly without a hack in the PC/SC IFD driver.

That's where our problem come from. ISO-7816 defines a way to select the
protocol type and parameters. The standard states that reset is followed by
PTS. The people who designed CT-API and PC/SC needed an API to talk to the
drivers. For protocol type selection, they just copied ISO-7816.
Unfortunately, the ISO standard defines the reader/ICC interface protocol,
and the PC/SC guys never thought it might not be appropriate for the
host/reader interface.

I expect the first readers to have been quite dumb and to basically act as an
electrical interface to the ICC contacts only. For those, the PC/SC model fit
quite nicely. Now, a few years later, we have more clever readers which can
perform PTS exchange automatically. If most of those need to be instructed to
start the PTS exchange after reset (for them, PC/SC still works), the
engineers who designed the ACR30U thought they would be even more clever, and
created a reader that performs the PTS exchange after reset without even
being told. Thus, to select the protocol type, the reader has to be told
_before_reset_ what protocol is desired. And *kaboom*, the PC/SC model
crashed. The order of the operations is reversed.

On the left side, PC/SC. Reset followed by SetProtocolParameters. On the right
side, the reader. SetProtocol followed by reset. In the middle, the various
layers of OpenCT. Clearly one of them has to reverse the operations. The
options are:

- Reverse them in the driver. The driver, when selecting a protocol, stores
the desired protocol internally and resets the card (-> possible side
effects), and when resetting the card, tells the reader to use the stored
protocol beforehand.

- Reverse them in the PC/SC layer. set_protocol and reset_card on the driver
side are made one, IFDHSetProtocolParameters stores the desired protocol
internally and resets the card (-> possible side effects), and IFDHPowerICC
uses the stored value to select the protocol.

I'm in favour of the second solution (you probably already know that :-)), as
it gives OpenCT a clean and side effects free API, and uses hacks in the
PC/SC emulation layer. As we have to choose between hacks in the drivers or
the PC/SC emulation layer, I'd rather see the main project (OpenCT and its
native API) clean and hack-free.

We could even keep the client API unchanged, with set_protocol storing the
parameters and reset doing the job, and make life easier for driver writers.
The client API would then be documented properly to point out that
set_parameter only stores the protocol and must be called before reset.

Please also note that OpenCT doesn't currently provide a way to implement
IFDHSetProtocolParameters completely, as PTS1, PTS2 and PTS3 are ignored.

> >. That
> >way, the driver can set the protocol before or right after reset, as
> > needed by the reader. Calling set_protocol after the protocol has been
> > selected, which currently results in broken behaviour for most drivers,
> > will not be possible anymore. The user will have to reset the card
> > explicitely. The possible side effects of set_protocol will thus
> > disappear, everybody is happy and the world is a better place to live in
> > (well, I wish :-)).
>
>     You wish. For pc/sc and ctapi users God himself has granted the
> right to modify interface parameters. ;p

And God was wrong to think that host/reader == reader/ICC :-)

> Maybe we should replace set_protocol with do_pts (or do_pps) (Protocol
> Type Selection or Protocol Parameter Selection).

Some drivers need to perform PTS, others don't. It's the driver responsability
to perform the operations it needs. The rest of OpenCT shouldn't have to care
if protocol selection must be done before reset, after reset or not at all.

Now, if there's too much opposition, I'll just drop it, but the ACR30U will
then not fit the OpenCT model, as it does not fit the PC/SC model. You might
think that making such a fuss for a single driver is a waste of time, but
there might be other similar readers in the future.

Laurent Pinchart
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Andreas Jellinghaus-2
In reply to this post by Laurent Pinchart
On Thursday 08 September 2005 14:49, Laurent Pinchart wrote:
> It seems to me that we should get rid of set_protocol in ifd_driver_ops
> completely, and add a protocol parameter to card_reset and card_request.

fine with me.

> and the world is a better place to live in (well, I wish :-)).

always a good goal :)

Andreas
p.s. but not for openct 0.6.6. will release it this weekend unless anyone
finds a big bug in the releases/openct-0.6.6 branch.
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Andreas Jellinghaus-2
In reply to this post by Laurent Pinchart
On Thursday 08 September 2005 20:03, Laurent Pinchart wrote:
> - Reverse them in the PC/SC layer. set_protocol and reset_card on the driver
> side are made one, IFDHSetProtocolParameters stores the desired protocol
> internally and resets the card (-> possible side effects), and IFDHPowerICC
> uses the stored value to select the protocol.

so pcsc interface will cause two resets instead of one?
except for a delay there should be no side effect, right?
can anyone thinkf of a card or reader that would have problems
with such an implementation?

> it gives OpenCT a clean and side effects free API, and uses hacks in the
> PC/SC emulation layer. As we have to choose between hacks in the drivers or
> the PC/SC emulation layer, I'd rather see the main project (OpenCT and its
> native API) clean and hack-free.

me too.

but I haven't received priits second mail so far,
neet to get and read that one too.

Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Andreas Jellinghaus-2
In reply to this post by Priit Randla
Hi Priit,

what do you think of the merging of those two functions?

sure, for ct-api and ifdhandler that would cause two resets
to the card, as those get a reset function call first and a
setprotocol function call after that.

that is a low complexity approach and that doesn't sound
like a big issue to me. or do you think that will cause problems?

Regards, Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Michael Haardt-3
In reply to this post by Laurent Pinchart
> sure, for ct-api and ifdhandler that would cause two resets
> to the card, as those get a reset function call first and a
> setprotocol function call after that.

It would cause two resets, if the reader does PPS on its own and you
want to chose a different protocol after PPS.  In case it delays PPS
until the next command, it wouldn't.  It's a driver/terminal issue,
not an API issue.

The B1 documentation says, that PPS is delayed until the first command,
and CT-API and B1 are very close.  CT-API over OpenCT over a B1 terminal
is an incomplete hack, but suffices for my needs.  If you would like to
use it 100%, I guess you have to go with a vendor library.  The freedom
taken in CT-API and CT-BCS implementations makes that pretty unlikely,
though.

Personally, I did not manage to get protocol selection working with my
B1 so far, because I suspect there is a bug in how the Kaan/B1 driver
interprets the reset response.  I wrote about that on the list a few
times, but never with any response.

All in all, I don't mind two resets.  Most people never change the
protocol anyway, but are heppy with getting T=1 by default.  By making
the preferred type a reset parameter, everything should get easier indeed.
We just need a parameter value that does not enforce a specific protocol.

Michael
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Priit Randla
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus wrote:

>Hi Priit,
>  
>
    Hello,

>what do you think of the merging of those two functions?
>
>sure, for ct-api and ifdhandler that would cause two resets
>to the card, as those get a reset function call first and a
>setprotocol function call after that.
>
>that is a low complexity approach and that doesn't sound
>like a big issue to me. or do you think that will cause problems?
>  
>
    Frankly, I don't know. Maybe we'll just try it?
If you don't mind I'll do a prototype patch on weekend.
Values for new parameter - unspecified', T=0, T=1, (more?);  default
goes 'Unspecified'. Agreed?

Or maybe there are other volunteers ;-)?

Priit
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Priit Randla
Priit Randla wrote:

> Andreas Jellinghaus wrote:
>
>> Hi Priit,
>>  
>>
>    Hello,
>
>> what do you think of the merging of those two functions?
>>
>> sure, for ct-api and ifdhandler that would cause two resets
>> to the card, as those get a reset function call first and a
>> setprotocol function call after that.
>>
>> that is a low complexity approach and that doesn't sound
>> like a big issue to me. or do you think that will cause problems?
>>  
>>
>    Frankly, I don't know. Maybe we'll just try it?
> If you don't mind I'll do a prototype patch on weekend.
> Values for new parameter - unspecified', T=0, T=1, (more?);  default
> goes 'Unspecified'. Agreed?

    Well, here it comes. Not very extensively tested but still I tested
it with 'normal openct usage' and
with 'pcsc-over-openct-setting-non-default-protocol' too. It even seemed
to work.
To make openct compilable(?) and testable, I had to modify all driver
files to get the interface consistent.
Before we can make various set_protocol functions in drivers static and
remove the function(s) from public API,
driver authors have make use of the new parameter 'unsigned int
protocol' in ...card_reset and ...card_request.
I had to make protocol parameter unsigned, as ct_tlv_get_int is meant to
be used with unsigned int only.

Andreas, btw, ct_tlv_get_int returns only 0 or 1, yet in process.c it's
return value is tested against <0.

Priit


diff -ur openct-0.6.6/src/ct/client.c openct-new/src/ct/client.c
--- openct-0.6.6/src/ct/client.c 2005-05-29 20:59:00.000000000 +0300
+++ openct-new/src/ct/client.c 2005-09-11 23:02:34.186054000 +0300
@@ -161,14 +161,14 @@
 /*
  * Reset the card - this is the same as "request icc" without parameters
  */
-int ct_card_reset(ct_handle * h, unsigned int slot, void *atr, size_t atr_len)
+int ct_card_reset(ct_handle * h, unsigned int slot, void *atr, size_t atr_len, unsigned int protocol)
 {
- return ct_card_request(h, slot, 0, NULL, atr, atr_len);
+ return ct_card_request(h, slot, 0, NULL, atr, atr_len, protocol);
 }
 
 int ct_card_request(ct_handle * h, unsigned int slot,
     unsigned int timeout, const char *message,
-    void *atr, size_t atr_len)
+    void *atr, size_t atr_len, unsigned int protocol)
 {
  ct_tlv_parser_t tlv;
  unsigned char buffer[256];
@@ -181,6 +181,7 @@
  ct_buf_putc(&args, CT_CMD_RESET);
  ct_buf_putc(&args, slot);
 
+ ct_args_int(&args, CT_TAG_PROTOCOL, protocol);
  /* Add arguments if given */
  if (timeout)
  ct_args_int(&args, CT_TAG_TIMEOUT, timeout);
diff -ur openct-0.6.6/src/ctapi/ctapi.c openct-new/src/ctapi/ctapi.c
--- openct-0.6.6/src/ctapi/ctapi.c 2005-06-12 12:35:15.000000000 +0300
+++ openct-new/src/ctapi/ctapi.c 2005-09-11 23:45:01.601788000 +0300
@@ -203,7 +203,7 @@
  case CTBCS_UNIT_INTERFACE1:
  case CTBCS_UNIT_INTERFACE2:
  rc = ct_card_reset(ct->h, p1 - CTBCS_UNIT_INTERFACE1,
-   atr, sizeof(atr));
+   atr, sizeof(atr), IFD_PROTOCOL_DEFAULT);
  break;
 
  case CTBCS_UNIT_CT:
@@ -301,6 +301,8 @@
 {
  unsigned char proto = 0xff;
  unsigned int slot;
+ unsigned int atrlen = 0;
+        unsigned char atr[64];
 
  if ((p1 == 0x00) || (p1 > 2))
  return ctapi_error(rbuf, CTBCS_SW_BAD_PARAMS);
@@ -354,10 +356,10 @@
  }
  if (proto == 0xff)
  return ctapi_error(rbuf, CTBCS_SW_BAD_PARAMS);
- if (!ct_card_set_protocol(ct->h, slot, proto))
- return ctapi_error(rbuf, CTBCS_SW_SUCCESS);
- else
+ if (ct_card_reset(ct->h, slot, atr, sizeof(atr), proto) < 0)
  return ctapi_error(rbuf, CTBCS_SW_NOT_EXECUTABLE);
+ else
+ return ctapi_error(rbuf, CTBCS_SW_SUCCESS);
       bad_length:
  return ctapi_error(rbuf, CTBCS_SW_BAD_LENGTH);
 }
diff -ur openct-0.6.6/src/ifd/ifd-acr30u.c openct-new/src/ifd/ifd-acr30u.c
--- openct-0.6.6/src/ifd/ifd-acr30u.c 2005-09-05 10:16:20.000000000 +0300
+++ openct-new/src/ifd/ifd-acr30u.c 2005-09-11 22:27:03.252005000 +0300
@@ -395,7 +395,7 @@
  * Reset
  */
 static int
-acr_card_reset(ifd_reader_t *reader, int slot, void *atr, size_t size)
+acr_card_reset(ifd_reader_t *reader, int slot, void *atr, size_t size, unsigned int protocol)
 {
  unsigned char buffer[IFD_MAX_ATR_LEN];
  unsigned char cmd[2];
diff -ur openct-0.6.6/src/ifd/ifd-cardman.c openct-new/src/ifd/ifd-cardman.c
--- openct-0.6.6/src/ifd/ifd-cardman.c 2005-05-29 20:58:58.000000000 +0300
+++ openct-new/src/ifd/ifd-cardman.c 2005-09-11 22:27:16.936924000 +0300
@@ -127,7 +127,7 @@
  * Reset
  */
 static int cm_card_reset(ifd_reader_t * reader, int slot, void *atr,
- size_t size)
+ size_t size, unsigned int protocol)
 {
  ifd_device_t *dev = reader->device;
  unsigned char buffer[IFD_MAX_ATR_LEN];
diff -ur openct-0.6.6/src/ifd/ifd-ccid.c openct-new/src/ifd/ifd-ccid.c
--- openct-0.6.6/src/ifd/ifd-ccid.c 2005-09-04 14:37:18.000000000 +0300
+++ openct-new/src/ifd/ifd-ccid.c 2005-09-11 22:27:46.671404000 +0300
@@ -788,7 +788,7 @@
  * Reset
  */
 static int
-ccid_card_reset(ifd_reader_t *reader, int slot, void *atr, size_t size)
+ccid_card_reset(ifd_reader_t *reader, int slot, void *atr, size_t size, unsigned int protocol)
 {
      ccid_status_t *st=(ccid_status_t *)reader->driver_data;
      unsigned char buffer[IFD_MAX_ATR_LEN];
diff -ur openct-0.6.6/src/ifd/ifd-cm4000.c openct-new/src/ifd/ifd-cm4000.c
--- openct-0.6.6/src/ifd/ifd-cm4000.c 2005-09-05 10:16:40.000000000 +0300
+++ openct-new/src/ifd/ifd-cm4000.c 2005-09-11 22:27:58.226647000 +0300
@@ -89,7 +89,7 @@
  * Reset
  */
 static int cm_card_reset(ifd_reader_t * reader, int slot, void *atr,
- size_t size)
+ size_t size, unsigned int protocol)
 {
  ifd_device_t *dev = reader->device;
  struct atreq cmatr;
diff -ur openct-0.6.6/src/ifd/ifd-egate.c openct-new/src/ifd/ifd-egate.c
--- openct-0.6.6/src/ifd/ifd-egate.c 2005-05-29 20:58:59.000000000 +0300
+++ openct-new/src/ifd/ifd-egate.c 2005-09-11 22:28:10.631762000 +0300
@@ -86,7 +86,7 @@
 }
 
 static int eg_card_reset(ifd_reader_t * reader, int slot, void *atr,
- size_t size)
+ size_t size, unsigned int protocol)
 {
  ifd_device_t *dev = reader->device;
  unsigned char buffer[EGATE_ATR_MAXSIZE];
diff -ur openct-0.6.6/src/ifd/ifd-etoken64.c openct-new/src/ifd/ifd-etoken64.c
--- openct-0.6.6/src/ifd/ifd-etoken64.c 2005-07-20 11:27:47.000000000 +0300
+++ openct-new/src/ifd/ifd-etoken64.c 2005-09-11 22:28:24.952585000 +0300
@@ -61,7 +61,7 @@
  * We should do something to make it come back with all state zapped
  */
 static int et64_card_reset(ifd_reader_t * reader, int slot, void *atr,
- size_t size)
+ size_t size, unsigned int protocol)
 {
  ifd_device_t *dev = reader->device;
  unsigned char buffer[256];
diff -ur openct-0.6.6/src/ifd/ifd-etoken.c openct-new/src/ifd/ifd-etoken.c
--- openct-0.6.6/src/ifd/ifd-etoken.c 2005-06-12 12:35:17.000000000 +0300
+++ openct-new/src/ifd/ifd-etoken.c 2005-09-11 22:28:33.092347000 +0300
@@ -83,7 +83,7 @@
  * We should do something to make it come back with all state zapped
  */
 static int et_card_reset(ifd_reader_t * reader, int slot, void *atr,
- size_t size)
+ size_t size, unsigned int protocol)
 {
  ifd_device_t *dev = reader->device;
  unsigned char buffer[256];
diff -ur openct-0.6.6/src/ifd/ifd-eutron.c openct-new/src/ifd/ifd-eutron.c
--- openct-0.6.6/src/ifd/ifd-eutron.c 2005-06-12 12:35:17.000000000 +0300
+++ openct-new/src/ifd/ifd-eutron.c 2005-09-11 22:28:53.076309000 +0300
@@ -59,7 +59,7 @@
  * We should do something to make it come back with all state zapped
  */
 static int eutron_card_reset(ifd_reader_t * reader, int slot, void *atr,
-     size_t size)
+     size_t size, unsigned int protocol)
 {
  ifd_device_t *dev = reader->device;
  unsigned char buffer[IFD_MAX_ATR_LEN + 100];
diff -ur openct-0.6.6/src/ifd/ifd-gempc.c openct-new/src/ifd/ifd-gempc.c
--- openct-0.6.6/src/ifd/ifd-gempc.c 2005-06-12 12:35:17.000000000 +0300
+++ openct-new/src/ifd/ifd-gempc.c 2005-09-11 22:29:06.304298000 +0300
@@ -201,7 +201,7 @@
  * Reset the card and get the ATR
  */
 static int gpc_card_reset(ifd_reader_t * reader, int slot, void *atr,
-  size_t size)
+  size_t size, unsigned int protocol)
 {
  static unsigned char reset_auto_pps[] = { 0x12, 0x23 };
  static unsigned char reset_no_pps[] = { 0x12, 0x13 };
diff -ur openct-0.6.6/src/ifd/ifd-ikey2k.c openct-new/src/ifd/ifd-ikey2k.c
--- openct-0.6.6/src/ifd/ifd-ikey2k.c 2005-06-12 12:35:17.000000000 +0300
+++ openct-new/src/ifd/ifd-ikey2k.c 2005-09-11 22:29:20.789096000 +0300
@@ -58,7 +58,7 @@
  * We should do something to make it come back with all state zapped
  */
 static int ikey2k_card_reset(ifd_reader_t * reader, int slot, void *atr,
-     size_t size)
+     size_t size, unsigned int protocol)
 {
  ifd_device_t *dev = reader->device;
  unsigned char buffer[256];
diff -ur openct-0.6.6/src/ifd/ifd-ikey3k.c openct-new/src/ifd/ifd-ikey3k.c
--- openct-0.6.6/src/ifd/ifd-ikey3k.c 2005-06-12 12:35:17.000000000 +0300
+++ openct-new/src/ifd/ifd-ikey3k.c 2005-09-11 22:29:30.874563000 +0300
@@ -58,7 +58,7 @@
  * We should do something to make it come back with all state zapped
  */
 static int ikey3k_card_reset(ifd_reader_t * reader, int slot, void *atr,
-     size_t size)
+     size_t size, unsigned int protocol)
 {
  ifd_device_t *dev = reader->device;
  unsigned char buffer[256];
diff -ur openct-0.6.6/src/ifd/ifd-kaan.c openct-new/src/ifd/ifd-kaan.c
--- openct-0.6.6/src/ifd/ifd-kaan.c 2005-05-29 20:58:58.000000000 +0300
+++ openct-new/src/ifd/ifd-kaan.c 2005-09-11 22:30:16.516624000 +0300
@@ -438,7 +438,7 @@
  * Reset card and get ATR
  */
 static int kaan_card_reset(ifd_reader_t * reader, int nslot, void *result,
-   size_t size)
+   size_t size, unsigned int protocol)
 {
  unsigned char cmd[5] = { 0x20, 0x10, 0x00, 0x01, 0x00 };
 
@@ -452,7 +452,7 @@
  * Request ICC
  */
 static int kaan_card_request(ifd_reader_t * reader, int slot, time_t timeout,
-     const char *message, void *atr, size_t atr_len)
+     const char *message, void *atr, size_t atr_len, unsigned int protocol)
 {
  ct_buf_t buf;
  unsigned char buffer[256] = { 0x20, 0x17, 0x00, 0x01, 0x00 };
diff -ur openct-0.6.6/src/ifd/ifd-pertosmart1030.c openct-new/src/ifd/ifd-pertosmart1030.c
--- openct-0.6.6/src/ifd/ifd-pertosmart1030.c 2005-09-05 01:44:32.000000000 +0300
+++ openct-new/src/ifd/ifd-pertosmart1030.c 2005-09-11 22:31:22.936527000 +0300
@@ -1199,7 +1199,7 @@
 
 
 static int
-ps_card_reset(ifd_reader_t *reader, int slot, void *atr, size_t size)
+ps_card_reset(ifd_reader_t *reader, int slot, void *atr, size_t size, unsigned int protocol)
 {
   ifd_device_t *     dev;
   ps_device_data_t * device_data;
diff -ur openct-0.6.6/src/ifd/ifd-smartboard.c openct-new/src/ifd/ifd-smartboard.c
--- openct-0.6.6/src/ifd/ifd-smartboard.c 2005-05-29 20:58:58.000000000 +0300
+++ openct-new/src/ifd/ifd-smartboard.c 2005-09-11 22:31:38.629141000 +0300
@@ -194,7 +194,7 @@
  * Reset card and get ATR
  */
 static int smartboard_card_reset(ifd_reader_t * reader, int slot, void *result,
- size_t size)
+ size_t size, unsigned int protocol)
 {
  unsigned char code;
  int rc;
diff -ur openct-0.6.6/src/ifd/ifd-towitoko.c openct-new/src/ifd/ifd-towitoko.c
--- openct-0.6.6/src/ifd/ifd-towitoko.c 2005-06-12 12:35:17.000000000 +0300
+++ openct-new/src/ifd/ifd-towitoko.c 2005-09-11 22:32:01.960594000 +0300
@@ -169,7 +169,7 @@
  * Reset the card and get the ATR
  */
 static int twt_card_reset(ifd_reader_t * reader, int slot, void *atr,
-  size_t size)
+  size_t size, unsigned int protocol)
 {
  static unsigned char reset1[] = { 0x80, 0x6F, 0x00, 0x05, 0x76 };
  static unsigned char reset2[] = { 0xA0, 0x6F, 0x00, 0x05, 0x74 };
diff -ur openct-0.6.6/src/ifd/process.c openct-new/src/ifd/process.c
--- openct-0.6.6/src/ifd/process.c 2005-05-29 20:58:58.000000000 +0300
+++ openct-new/src/ifd/process.c 2005-09-11 22:45:15.702927000 +0300
@@ -270,17 +270,21 @@
  char msgbuf[128];
  const char *message = NULL;
  unsigned int timeout = 0;
+ unsigned int protocol;
  int rc;
 
  if (unit > reader->nslots)
  return IFD_ERROR_INVALID_SLOT;
 
+ if (ct_tlv_get_int(args, CT_TAG_PROTOCOL, &protocol) < 0)
+ return IFD_ERROR_MISSING_ARG;
+
  /* See if we have timeout and/or message parameters */
  ct_tlv_get_int(args, CT_TAG_TIMEOUT, &timeout);
  if (ct_tlv_get_string(args, CT_TAG_MESSAGE, msgbuf, sizeof(msgbuf)) > 0)
  message = msgbuf;
 
- rc = ifd_card_request(reader, unit, timeout, message, atr, sizeof(atr));
+ rc = ifd_card_request(reader, unit, timeout, message, atr, sizeof(atr), protocol);
  if (rc < 0)
  return rc;
 
diff -ur openct-0.6.6/src/ifd/reader.c openct-new/src/ifd/reader.c
--- openct-0.6.6/src/ifd/reader.c 2005-07-20 11:27:46.000000000 +0300
+++ openct-new/src/ifd/reader.c 2005-09-11 23:08:16.763974000 +0300
@@ -192,16 +192,16 @@
  * Reset card and obtain ATR
  */
 int ifd_card_reset(ifd_reader_t * reader, unsigned int idx, void *atr,
-   size_t size)
+   size_t size, unsigned int protocol)
 {
- return ifd_card_request(reader, idx, 0, NULL, atr, size);
+ return ifd_card_request(reader, idx, 0, NULL, atr, size, protocol);
 }
 
 /*
  * Request ICC
  */
 int ifd_card_request(ifd_reader_t * reader, unsigned int idx, time_t timeout,
-     const char *message, void *atr, size_t size)
+     const char *message, void *atr, size_t size, unsigned int protocol)
 {
  const ifd_driver_t *drv = reader->driver;
  ifd_device_t *dev = reader->device;
@@ -259,7 +259,7 @@
  if (drv->ops->card_request && (timeout || message)) {
  n = drv->ops->card_request(reader, idx,
    timeout, message, slot->atr,
-   sizeof(slot->atr));
+   sizeof(slot->atr), protocol);
  if (n <= 0)
  return n;
  count = n;
@@ -267,7 +267,7 @@
     if (dev->type != IFD_DEVICE_TYPE_SERIAL
  || !drv->ops->change_parity) {
  n = drv->ops->card_reset(reader, idx,
- slot->atr, sizeof(slot->atr));
+ slot->atr, sizeof(slot->atr), protocol);
  if (n <= 0)
  return n;
  count = n;
@@ -278,7 +278,7 @@
 
  /* Reset the card */
  n = drv->ops->card_reset(reader, idx,
- slot->atr, sizeof(slot->atr));
+ slot->atr, sizeof(slot->atr), protocol);
 
  /* If there was no ATR, try again with odd parity */
  if (n == IFD_ERROR_NO_ATR) {
@@ -286,7 +286,7 @@
  if (drv->ops->change_parity(reader, parity) < 0)
  return -1;
  n = drv->ops->card_reset(reader, idx,
- slot->atr, sizeof(slot->atr));
+ slot->atr, sizeof(slot->atr), protocol);
  }
 
  /* Bail out in case of general error */
diff -ur openct-0.6.6/src/include/openct/driver.h openct-new/src/include/openct/driver.h
--- openct-0.6.6/src/include/openct/driver.h 2005-08-29 00:10:23.000000000 +0300
+++ openct-new/src/include/openct/driver.h 2005-09-11 23:11:23.334611000 +0300
@@ -151,7 +151,8 @@
  * Called by: ifd_card_request.
  * @return Error code <0 if failure, length of the ATR if success.
  */
- int (*card_reset)(ifd_reader_t *reader, int slot, void *atr, size_t atr_len);
+ int (*card_reset)(ifd_reader_t *reader, int slot, void *atr, size_t atr_len,
+ unsigned int protocol);
  /**
  * Prompts the insertion of a smart card in the reader and performs a card reset.
  *
@@ -168,7 +169,7 @@
  */
  int (*card_request)(ifd_reader_t *reader, int slot,
  time_t timeout, const char *message,
- void *atr, size_t atr_len);
+ void *atr, size_t atr_len, unsigned int protocol);
  /**
  * Eject the smart card.
  *
diff -ur openct-0.6.6/src/include/openct/ifd.h openct-new/src/include/openct/ifd.h
--- openct-0.6.6/src/include/openct/ifd.h 2005-03-22 10:02:31.000000000 +0200
+++ openct-new/src/include/openct/ifd.h 2005-09-11 23:05:22.392482000 +0300
@@ -19,9 +19,9 @@
 typedef union ifd_device_params ifd_device_params_t;
 
 enum {
- IFD_PROTOCOL_DEFAULT = -1,
  IFD_PROTOCOL_T0 = 0,
  IFD_PROTOCOL_T1,
+ IFD_PROTOCOL_DEFAULT = 15,
  IFD_PROTOCOL_2WIRE = 16,
  IFD_PROTOCOL_3WIRE,
  IFD_PROTOCOL_I2C_SHORT,
@@ -135,13 +135,15 @@
 extern int ifd_card_reset(ifd_reader_t *reader,
  unsigned int slot,
  void *atr_buf,
- size_t atr_len);
+ size_t atr_len,
+ unsigned int protocol);
 extern int ifd_card_request(ifd_reader_t *reader,
  unsigned int slot,
  time_t timeout,
  const char *message,
  void *atr_buf,
- size_t atr_len);
+ size_t atr_len,
+ unsigned int protocol);
 extern int ifd_card_eject(ifd_reader_t *reader,
  unsigned int slot,
  time_t timeout,
diff -ur openct-0.6.6/src/include/openct/openct.h openct-new/src/include/openct/openct.h
--- openct-0.6.6/src/include/openct/openct.h 2005-03-22 10:02:31.000000000 +0200
+++ openct-new/src/include/openct/openct.h 2005-09-11 22:38:46.509094000 +0300
@@ -66,10 +66,10 @@
 extern int ct_card_set_protocol(ct_handle *h, unsigned int slot,
  unsigned int protocol);
 extern int ct_card_reset(ct_handle *h, unsigned int slot,
- void *atr, size_t atr_len);
+ void *atr, size_t atr_len, unsigned int protocol);
 extern int ct_card_request(ct_handle *h, unsigned int slot,
  unsigned int timeout, const char *message,
- void *atr, size_t atr_len);
+ void *atr, size_t atr_len, unsigned int protocol);
 extern int ct_card_lock(ct_handle *h, unsigned int slot,
  int type, ct_lock_handle *);
 extern int ct_card_unlock(ct_handle *h, unsigned int slot,
diff -ur openct-0.6.6/src/tools/openct-tool.c openct-new/src/tools/openct-tool.c
--- openct-0.6.6/src/tools/openct-tool.c 2005-09-04 14:37:16.000000000 +0300
+++ openct-new/src/tools/openct-tool.c 2005-09-11 23:15:23.812053000 +0300
@@ -18,6 +18,7 @@
 #include <openct/openct.h>
 #include <openct/logging.h>
 #include <openct/error.h>
+#include <openct/ifd.h>
 
 static void usage(int exval);
 static void version(void);
@@ -225,10 +226,10 @@
        (status & IFD_CARD_STATUS_CHANGED) ? ", status changed" : "");
 
  if (status & IFD_CARD_PRESENT) {
- n = ct_card_reset(h, opt_slot, atr, atr_len);
+ n = ct_card_reset(h, opt_slot, atr, atr_len, IFD_PROTOCOL_DEFAULT);
  } else {
  n = ct_card_request(h, opt_slot, 5, "Please insert card",
-    atr, atr_len);
+    atr, atr_len, IFD_PROTOCOL_DEFAULT);
  }
 
  if (n < 0) {

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Andreas Jellinghaus-2
Hi Priit,

thanks for the patch. but I wonder: what is the semantic
we want to implement? Is that parameter a preference
or a requirement? Do we want to pass a single value
or have flags that can be or'ed to allow several
protocols?

sorry, I didn't follow the discussion close enough.

laurent, how do those smart readers work? do you set
a preference? or do you need to set exactly the
protocol you want to have?

for etoken, ikey2000 and  ikey3000 I only have T=1.
should the driver fail if asked for anything else?
or ignore and use T=1 / return that information?

sorry, also I have not much clue how pcsc handles
all this.

> Andreas, btw, ct_tlv_get_int returns only 0 or 1, yet in process.c it's
> return value is tested against <0.

good catch. most likely never saw that code before :(
will fix it.

Andreas
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Michael Haardt-3
On Mon, Sep 12, 2005 at 12:12:01AM +0200, Andreas Jellinghaus wrote:
> thanks for the patch. but I wonder: what is the semantic
> we want to implement? Is that parameter a preference
> or a requirement? Do we want to pass a single value
> or have flags that can be or'ed to allow several
> protocols?
>
> sorry, I didn't follow the discussion close enough.

I didn't try the patch so far, but the discussion agreed on a new
parameter to enforce one specific protocol.  There should be a value
that uses the default protocol, which would have been used before.
Looking at the patch, it appears to do that.

> for etoken, ikey2000 and  ikey3000 I only have T=1.
> should the driver fail if asked for anything else?
> or ignore and use T=1 / return that information?

It should fail.  I vote for using a different get() function to
return the currently used protocol.  I am not sure if all readers
can return it at all.

Michael
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Priit Randla
In reply to this post by Andreas Jellinghaus-2
Andreas Jellinghaus wrote:

>Hi Priit,
>
>thanks for the patch. but I wonder: what is the semantic
>we want to implement? Is that parameter a preference
>or a requirement? Do we want to pass a single value
>or have flags that can be or'ed to allow several
>protocols?
>  
>
    Currently it's meant normally used as IFD_PROTOCOL_DEFAULT, which
should let the card (or reader driver) decide, which protocol to use.
Any other value means
the client application requires specific protocol for some reason. Of
course, as IFD_PROTOCOL_DEFAULT is
defined as being 15, it can be read as being IFD_PROTOCOL_T0 |
IFD_PROTOCOL_T1 | IFD_PROTOCOL_T10 | IFD_PROTOCOL_WHATEVER
for asynchronous cards ;-).

>sorry, I didn't follow the discussion close enough.
>
>laurent, how do those smart readers work? do you set
>a preference? or do you need to set exactly the
>protocol you want to have?
>
>for etoken, ikey2000 and  ikey3000 I only have T=1.
>should the driver fail if asked for anything else?
>or ignore and use T=1 / return that information?
>  
>
    It should fail.

>sorry, also I have not much clue how pcsc handles
>all this.
>  
>
   In PC/SC (lite) currently protocol selection is usually made using
   SCardConnect(hContext, reader, sharing, SCARD_PROTOCOL_T0 |
SCARD_PROTOCOL_T1, &hCard, &dwActiveProtocol);
     PS/SC-lite prefers T=1, if that doesn't work, T=0 is tried.

Priit
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Laurent Pinchart
In reply to this post by Andreas Jellinghaus-2
> thanks for the patch. but I wonder: what is the semantic
> we want to implement? Is that parameter a preference
> or a requirement? Do we want to pass a single value
> or have flags that can be or'ed to allow several
> protocols?

I think we should make it a preference, with a way to check which protocol was
selected.

> laurent, how do those smart readers work? do you set
> a preference? or do you need to set exactly the
> protocol you want to have?

The ACR30U asks for a preferred protocol, and tries to negociate it with the
ICC. If it fails, another protocol is selected, and you can query the reader
to find which one.

> for etoken, ikey2000 and  ikey3000 I only have T=1.
> should the driver fail if asked for anything else?
> or ignore and use T=1 / return that information?

> sorry, also I have not much clue how pcsc handles
> all this.

Not sure about PC/SC on Windows, but Muscle tries to negociate the requested
protocol, and falls back to the default protocol if negociation fails. If the
requested protocol is not supported by the ICC, an error code is returned to
the user. The preferred protocols parameter is a bit mask.

Should we try to handle all this in the general case where 15 protocols can be
supported (T=0 to T=14), or should we just care about T=0 and T=1 ? In the
later case, only 3 values are needed (T=0, T=1, any/default) and we won't
need a bitmask.

In any case, the selected protocol should be returned to the user. For
synchronous cards, no protocol is currently selected at reset time. The
protocol parameter is instead passer to the sync_read and sync_write
functions. Does anyone know what the rationale behind that is ?

BTW, this might be a dumb question, but what's the difference between T=0 and
T=1 from the user point of view ? Isn't OpenCT supposed to handle T=0 and T=1
so that the user only transmits APDUs without caring which protocol is used ?
Why would the user want to use T=0 or T=1 explicitely ?

Laurent Pinchart
_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: OpenCT API question

Priit Randla
Laurent Pinchart wrote:

>>thanks for the patch. but I wonder: what is the semantic
>>we want to implement? Is that parameter a preference
>>or a requirement? Do we want to pass a single value
>>or have flags that can be or'ed to allow several
>>protocols?
>>    
>>
>
>I think we should make it a preference, with a way to check which protocol was
>selected.
>
>  
>
>>laurent, how do those smart readers work? do you set
>>a preference? or do you need to set exactly the
>>protocol you want to have?
>>    
>>
>
>The ACR30U asks for a preferred protocol, and tries to negociate it with the
>ICC. If it fails, another protocol is selected, and you can query the reader
>to find which one.
>  
>

>Should we try to handle all this in the general case where 15 protocols can be
>supported (T=0 to T=14), or should we just care about T=0 and T=1 ? In the
>later case, only 3 values are needed (T=0, T=1, any/default) and we won't
>need a bitmask.
>  
>
I'd vote for bitmask IFD_PROTOCOL_DEFAULT = IFD_PROTOCOL_T0 |
IFD_PROTOCOL_T1 | ...

>In any case, the selected protocol should be returned to the user.
>
 So, yet another parameter to ct_card_reset? &protocol_selected?

>BTW, this might be a dumb question, but what's the difference between T=0 and
>T=1 from the user point of view ? Isn't OpenCT supposed to handle T=0 and T=1
>so that the user only transmits APDUs without caring which protocol is used ?
>Why would the user want to use T=0 or T=1 explicitely ?
>  
>
 Well, I'm dumber. Basically, I know that protocol handling is supposed
to be transparent to client applications.
After all 'Smart Card Handbook' says this ;-).
But also I know, that using PC/SC one always has to add Le byte to the
commands which provoke the card
to answer with some data. Those commands the cards tend to answer with
0x61xx using T=0 need the Le byte
appended to thenm for sending within T=1 frame. I really don't know if
it should be driver's responsibility to do that or not.
Is there somebody who really works within sc industry to clarify the
situation?

Priit

_______________________________________________
opensc-devel mailing list
[hidden email]
http://www.opensc.org/cgi-bin/mailman/listinfo/opensc-devel