SCARD_E_SHARING_VIOLATION workaround in SCardReconnect() (2475)

[Paul Klissner]

Hi,

During some testing of the Sun version of PCSClite we noticed
some SCARD_E_SHARING_VIOLATION errors in SCardReconnect().

A co-worker pointed out that winscard_clnt.c was patched (2475) in the
open source code to make SCardReconnect() loop (re-try) when
SCARD_E_SHARING_VIOLATION  occurs, thus masking the error.

That looks like a workaround for something.  But does it mask the
error a bit *too* earnestly?

I'm wondering:  Why is there not some sort of re-try maximum
in that loop to keep it from looping infinitely without letting the
application know there's an issue, and why isn't there some sort
of time delay to throttle down the rate to keep it from spinning too  
fast?

Also, I notice there is no such workaround in SCardTransmit().
I assume maybe there's a good reason to handle it differently in
the two API calls, but I just want to find out if it was a conscious
choice to add it to one and not the other, or not.

Thanks,
Paul

_______________________________________________
Muscle mailing list
Muscle@...
http://lists.drizzle.com/mailman/listinfo/muscle

[Ludovic Rousseau]

2009/10/1 Paul Klissner <Paul.Klissner@...>:
> Hi,

Hello Paul,

> During some testing of the Sun version of PCSClite we noticed
> some SCARD_E_SHARING_VIOLATION errors in SCardReconnect().
>
> A co-worker pointed out that winscard_clnt.c was patched (2475) in the
> open source code to make SCardReconnect() loop (re-try) when
> SCARD_E_SHARING_VIOLATION  occurs, thus masking the error.

The idea is not to mask the error but to be Windows compatible (if I
remember correctly)
I made the change in revision 2475 [1] but have not documented _why_
the change. And I don't remember who asked for the change. I will have
to look in my email archives.

> That looks like a workaround for something.  But does it mask the
> error a bit *too* earnestly?
>
> I'm wondering:  Why is there not some sort of re-try maximum
> in that loop to keep it from looping infinitely without letting the
> application know there's an issue, and why isn't there some sort
> of time delay to throttle down the rate to keep it from spinning too fast?
>
> Also, I notice there is no such workaround in SCardTransmit().
> I assume maybe there's a good reason to handle it differently in
> the two API calls, but I just want to find out if it was a conscious
> choice to add it to one and not the other, or not.

If you do not want to wait in SCardReconnect() you can use
SCardDisconnect()/SCardConnect() insted. SCardConnect() will not block
and return SCARD_E_SHARING_VIOLATION immediately.

Do you know the behavior of SCardReconnect() under Windows? That
should be the reference for pcsc-lite.

Bye

[1] http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2007-March/002640.html

--
 Dr. Ludovic Rousseau

_______________________________________________
Muscle mailing list
Muscle@...
http://lists.drizzle.com/mailman/listinfo/muscle

[s.ferey]

Ludovic Rousseau a écrit :

> 2009/10/1 Paul Klissner <Paul.Klissner@...>:
>> Hi,
>
> Hello Paul,
>
>> During some testing of the Sun version of PCSClite we noticed
>> some SCARD_E_SHARING_VIOLATION errors in SCardReconnect().
>>
>> A co-worker pointed out that winscard_clnt.c was patched (2475) in the
>> open source code to make SCardReconnect() loop (re-try) when
>> SCARD_E_SHARING_VIOLATION  occurs, thus masking the error.
>
> The idea is not to mask the error but to be Windows compatible (if I
> remember correctly)
> I made the change in revision 2475 [1] but have not documented _why_
> the change. And I don't remember who asked for the change. I will have
> to look in my email archives.

AFAI understand it, this is NOT a Windows specific behavior.
SCard[Re]Connect can return SCARD_E_SHARING_VIOLATION if an exclusive
connection is alive or if excl. conn. is requested while another conn.
exist. this is not OS dependant.

a loop/retry strategy is IMHO not the good answer since the low level
method has not idea of the existing conn., OOH the calling appl. may
choose to deal with shared conn. if exclusive one can't be obtained.

>> That looks like a workaround for something.  But does it mask the
>> error a bit *too* earnestly?
>>
>> I'm wondering:  Why is there not some sort of re-try maximum
>> in that loop to keep it from looping infinitely without letting the
>> application know there's an issue, and why isn't there some sort
>> of time delay to throttle down the rate to keep it from spinning too fast?
>>
>> Also, I notice there is no such workaround in SCardTransmit().
>> I assume maybe there's a good reason to handle it differently in
>> the two API calls, but I just want to find out if it was a conscious
>> choice to add it to one and not the other, or not.
>
> If you do not want to wait in SCardReconnect() you can use
> SCardDisconnect()/SCardConnect() insted. SCardConnect() will not block
> and return SCARD_E_SHARING_VIOLATION immediately.
>
> Do you know the behavior of SCardReconnect() under Windows? That
> should be the reference for pcsc-lite.

Do you mean we're missing an important Windows specific detail?
Thanks to summarize it, these exchanges will be more efficient :)

Sylvain.


_______________________________________________
Muscle mailing list
Muscle@...
http://lists.drizzle.com/mailman/listinfo/muscle

[Ludovic Rousseau]

2009/10/1 s.ferey <s.ferey@...>:

> Ludovic Rousseau a écrit :
>>
>> 2009/10/1 Paul Klissner <Paul.Klissner@...>:
>>>
>>> Hi,
>>
>> Hello Paul,
>>
>>> During some testing of the Sun version of PCSClite we noticed
>>> some SCARD_E_SHARING_VIOLATION errors in SCardReconnect().
>>>
>>> A co-worker pointed out that winscard_clnt.c was patched (2475) in the
>>> open source code to make SCardReconnect() loop (re-try) when
>>> SCARD_E_SHARING_VIOLATION  occurs, thus masking the error.
>>
>> The idea is not to mask the error but to be Windows compatible (if I
>> remember correctly)
>> I made the change in revision 2475 [1] but have not documented _why_
>> the change. And I don't remember who asked for the change. I will have
>> to look in my email archives.
>
> AFAI understand it, this is NOT a Windows specific behavior.
> SCard[Re]Connect can return SCARD_E_SHARING_VIOLATION if an exclusive
> connection is alive or if excl. conn. is requested while another conn.
> exist. this is not OS dependant.
>
> a loop/retry strategy is IMHO not the good answer since the low level method
> has not idea of the existing conn., OOH the calling appl. may choose to deal
> with shared conn. if exclusive one can't be obtained.

That makes sense. I will revert the patch soon, unless someone objects.

I searched my mail archives and could not find any reference to this 2475 patch.

>>> That looks like a workaround for something.  But does it mask the
>>> error a bit *too* earnestly?
>>>
>>> I'm wondering:  Why is there not some sort of re-try maximum
>>> in that loop to keep it from looping infinitely without letting the
>>> application know there's an issue, and why isn't there some sort
>>> of time delay to throttle down the rate to keep it from spinning too
>>> fast?
>>>
>>> Also, I notice there is no such workaround in SCardTransmit().
>>> I assume maybe there's a good reason to handle it differently in
>>> the two API calls, but I just want to find out if it was a conscious
>>> choice to add it to one and not the other, or not.
>>
>> If you do not want to wait in SCardReconnect() you can use
>> SCardDisconnect()/SCardConnect() insted. SCardConnect() will not block
>> and return SCARD_E_SHARING_VIOLATION immediately.
>>
>> Do you know the behavior of SCardReconnect() under Windows? That
>> should be the reference for pcsc-lite.
>
> Do you mean we're missing an important Windows specific detail?
> Thanks to summarize it, these exchanges will be more efficient :)

I just say the reference implementation is winscard in Windows. If
pcsc-lite is different then pcsc-lite must be corrected (unless it is
a bug on the Windows side)

Regards,

--
 Dr. Ludovic Rousseau

_______________________________________________
Muscle mailing list
Muscle@...
http://lists.drizzle.com/mailman/listinfo/muscle

[Emmanuel Deloget]

Ludovic Rousseau a écrit :
>
>
> I just say the reference implementation is winscard in Windows. If
> pcsc-lite is different then pcsc-lite must be corrected (unless it is
> a bug on the Windows side)
>
> Regards,
>
>  

Hi Ludovic (and other members of this list),

Your statement is somewhat interesting given the fact that as of today
there are a few differences between pcsc-lite and winscard which (in my
opinion) should be addressed in order to enhance  source compatibility
with existing Windows code. The problem is that some of them might also
break existing pcsc-lite based applications, so it's kinda hard to
decide what shall be done in these cases.

1) regarding SCardStatus(): (*pdwState) is filled with a bit field in
pcsc-lite and an enumeration in winscard. It make sense to tranform the
internal state bitfield to an enumeration before returning it since the
card cannot be in two different states at the same time. Unfortunately,
I believe that such a change would greatly impact existing pcsc-lite
applications in a subtle way - existing source would appear to be valid
(compile with no warning or error) but would contain logical errors.

2) regarding return codes: when writing an ifd handler, it's quite
difficult (if not impossible) to make sure that a specific error
condition in the handler will trigger a specific error code on the
pcsc-lite side. A typical example is SCardGetAttrib() which translate to
IFDHGetCapabilities() (which, according to
http://pcsclite.alioth.debian.org/ifdhandler-3/node15.html, can only
return IFD_SUCCESS, IFD_ERROR_TAG or IFD_NO_SUCH_DEVICE). How do we
ensure that pcsc-lite would return (for example)
SCARD_E_INSUFFICIENT_BUFFER when the output buffer is too small ?

3) SCARD_E_UNSUPPORTED_FEATURE: functions that return this error code
shall return ERROR_NOT_SUPPORTED instead. This is just a change in the
error name and value, but such change would enhance source compatibility
with Windows application - and would break source compatibility with
existing pcsc-lite applications as well.

There are many other cases - I can't list them all right now.

Best regards,

-- Emmanuel Deloget
_______________________________________________
Muscle mailing list
Muscle@...
http://lists.drizzle.com/mailman/listinfo/muscle

[Ludovic Rousseau]

2009/10/2 Emmanuel Deloget <e.deloget@...>:

> Ludovic Rousseau a écrit :
>>
>>
>> I just say the reference implementation is winscard in Windows. If
>> pcsc-lite is different then pcsc-lite must be corrected (unless it is
>> a bug on the Windows side)
>>
>> Regards,
>>
>>
>
> Hi Ludovic (and other members of this list),
>
> Your statement is somewhat interesting given the fact that as of today
> there are a few differences between pcsc-lite and winscard which (in my
> opinion) should be addressed in order to enhance  source compatibility
> with existing Windows code. The problem is that some of them might also
> break existing pcsc-lite based applications, so it's kinda hard to
> decide what shall be done in these cases.

I just added a section "Known differences with Microsoft Windows
WinSCard implementation:" in the Doxygen documentation. It is visible
here: http://pcsclite.alioth.debian.org/api/group__API.html#_details

> 1) regarding SCardStatus(): (*pdwState) is filled with a bit field in
> pcsc-lite and an enumeration in winscard. It make sense to tranform the
> internal state bitfield to an enumeration before returning it since the
> card cannot be in two different states at the same time. Unfortunately,
> I believe that such a change would greatly impact existing pcsc-lite
> applications in a subtle way - existing source would appear to be valid
> (compile with no warning or error) but would contain logical errors.

I do not plan to fix this. See the Doxygen note.

> 2) regarding return codes: when writing an ifd handler, it's quite
> difficult (if not impossible) to make sure that a specific error
> condition in the handler will trigger a specific error code on the
> pcsc-lite side. A typical example is SCardGetAttrib() which translate to
> IFDHGetCapabilities() (which, according to
> http://pcsclite.alioth.debian.org/ifdhandler-3/node15.html, can only
> return IFD_SUCCESS, IFD_ERROR_TAG or IFD_NO_SUCH_DEVICE). How do we
> ensure that pcsc-lite would return (for example)
> SCARD_E_INSUFFICIENT_BUFFER when the output buffer is too small ?

I will work on this later. I agree the ifdhandler API can be improved
regarding return codes.
It is easy to add a IFD_INSUFFICIENT_BUFFER.
Do you also want other return codes?

> 3) SCARD_E_UNSUPPORTED_FEATURE: functions that return this error code
> shall return ERROR_NOT_SUPPORTED instead. This is just a change in the
> error name and value, but such change would enhance source compatibility
> with Windows application - and would break source compatibility with
> existing pcsc-lite applications as well.

I do not want to fix this. Using ERROR_NOT_SUPPORTED is stupid. An
SCard* function should only return SCARD_* error codes.

> There are many other cases - I can't list them all right now.

Please list all the other cases you know so they can be fixed or, at
least, documented.

Thanks a lot

--
 Dr. Ludovic Rousseau

_______________________________________________
Muscle mailing list
Muscle@...
http://lists.drizzle.com/mailman/listinfo/muscle

[Martin Paljak]

On 02.10.2009, at 17:10, Ludovic Rousseau wrote:
> I just added a section "Known differences with Microsoft Windows
> WinSCard implementation:" in the Doxygen documentation. It is visible
> here: http://pcsclite.alioth.debian.org/api/group__API.html#_details
Please also add from SCardConnect http://pcsclite.alioth.debian.org/api/group__API.html#ga4e515829752e0a8dbc4d630696a8d6a5 
  :

"Contrary to Windows winscard behavior, the reader is accessed in  
shared mode and not exclusive mode."

--
Martin Paljak
http://martin.paljak.pri.ee
+372.515.6495




_______________________________________________
Muscle mailing list
Muscle@...
http://lists.drizzle.com/mailman/listinfo/muscle

[Ludovic Rousseau]

2009/10/3 Martin Paljak <martin.paljak@...>:

> On 02.10.2009, at 17:10, Ludovic Rousseau wrote:
>>
>> I just added a section "Known differences with Microsoft Windows
>> WinSCard implementation:" in the Doxygen documentation. It is visible
>> here: http://pcsclite.alioth.debian.org/api/group__API.html#_details
>
> Please also add from SCardConnect
> http://pcsclite.alioth.debian.org/api/group__API.html#ga4e515829752e0a8dbc4d630696a8d6a5 :
>
> "Contrary to Windows winscard behavior, the reader is accessed in shared
> mode and not exclusive mode."

Done in revision 4419. The web pages are updated.

Thanks

--
 Dr. Ludovic Rousseau

_______________________________________________
Muscle mailing list
Muscle@...
http://lists.drizzle.com/mailman/listinfo/muscle

[Ludovic Rousseau]

2009/10/1 Paul Klissner <Paul.Klissner@...>:
> During some testing of the Sun version of PCSClite we noticed
> some SCARD_E_SHARING_VIOLATION errors in SCardReconnect().
>
> A co-worker pointed out that winscard_clnt.c was patched (2475) in the
> open source code to make SCardReconnect() loop (re-try) when
> SCARD_E_SHARING_VIOLATION  occurs, thus masking the error.
>
> That looks like a workaround for something.  But does it mask the
> error a bit *too* earnestly?

Fixed in revision 4442.
http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2009-October/003960.html

SCardReconnect(): return SCARD_E_SHARING_VIOLATION instead of blocking
if the reader cannot be shared.

Thanks

--
 Dr. Ludovic Rousseau

_______________________________________________
Muscle mailing list
Muscle@...
http://lists.drizzle.com/mailman/listinfo/muscle

[Ludovic Rousseau]

2009/10/2 Emmanuel Deloget <e.deloget@...>:
> 2) regarding return codes: when writing an ifd handler, it's quite
> difficult (if not impossible) to make sure that a specific error
> condition in the handler will trigger a specific error code on the
> pcsc-lite side. A typical example is SCardGetAttrib() which translate to
> IFDHGetCapabilities() (which, according to
> http://pcsclite.alioth.debian.org/ifdhandler-3/node15.html, can only
> return IFD_SUCCESS, IFD_ERROR_TAG or IFD_NO_SUCH_DEVICE). How do we
> ensure that pcsc-lite would return (for example)
> SCARD_E_INSUFFICIENT_BUFFER when the output buffer is too small ?

Fixed in revision 4445
http://lists.alioth.debian.org/pipermail/pcsclite-cvs-commit/2009-October/003963.html

Thanks

--
 Dr. Ludovic Rousseau
_______________________________________________
Muscle mailing list
Muscle@...
http://lists.drizzle.com/mailman/listinfo/muscle