Hi Ludovic, I have tested a similar sample.c (attached) in a windows vista (sorry, it's the only windows I have) with Windows SDK 6.1 and it is clear that the SCardRconnect clears the connections. Compilation and output is presented below:
C:\Users\ricky\Desktop>cl sample.c Winscard.lib Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. sample.c Microsoft (R) Incremental Linker Version 9.00.21022.08 Copyright (C) Microsoft Corporation. All rights reserved. /out:sample.exe sample.obj Winscard.lib C:\Users\ricky\Desktop>sample.exe reader name: Gemplus USB SmartCard Reader 0 response: 86 CC 40 80 7A 68 C9 90 00 response: 86 CC 40 80 7A 68 C9 90 00 SCardEndTransaction: 0x80100016 (0x80100016) So the SCardEndTransaction returns SCARD_E_NOT_TRANSACTED after the reconnect. Besides the documentation says the following: "The application must immediately call the SCardDisconnect, SCardReconnect, or SCardReleaseContext function to avoid an existing transaction blocking other threads and processes from communicating with the smart card." See here: https://msdn.microsoft.com/es-es/library/windows/desktop/aa379477%28v=vs.85%29.aspx Regards! On Monday, June 1, 2015 2:52 PM, Ludovic Rousseau <[email protected]> wrote: 2015-06-01 13:57 GMT+02:00 Ricardo Martin <[email protected]>: > Hi everybody, Hello, > Playing with opensc and the dnie driver I found a weird behavior. After some > tests I opened the following issue in opensc github: > > https://github.com/OpenSC/OpenSC/issues/475 > > It seems that opensc in the method sc_reset finally sends a SCardReconnect > with SCARD_UNPOWER_CARD or SCARD_RESET_CARD (depending the do_cold_reset > parameter). But at the end of the sc_reset function opensc performs the > following: > > /* pcsc_reconnect unlocks card... try to lock it again if it was > locked */ > if(old_locked) > r = pcsc_lock(reader); > > If the connection was previously locked, after the reconnect, it adds a lock > again (SCardBeginTransaction is called again inside pcsc_lock). My > impression is that this extra call adds one more lock in the pcsc > (rContext->LockCount) which is never released, and this ends in the complete > lock of the card until the current process finishes (no other process can > access the card in shared mode). Every call to pcsc_reset in opensc seems to > add a lost lock in pcsc (and the dnie driver calls to this reset). > > I have done some little test with pcsc (with the little sample.c copied > below) and it seems that SCardReconnect does not lose the locks (in any > case: SCARD_SHARE_SHARED or SCARD_SHARE_EXCLUSIVE, SCARD_UNPOWER_CARD or > SCARD_RESET_CARD). But, just to be sure, can anybody confirm that > SCardReconnect maintains the locks (transactions)? Is the extra call done in > opensc to SCardBeginTransaction needed? It looks like you are right. I checked the source code of pcsc-lite and SCardReconnect() does not release or take a lock. It only checks if a lock (from another PC/SC context) is not yet present. To know if this is a bug or not in pcsc-lite we should know how it works on Windows. I could not find any reference to transactions or locks in MSDN documentation [1]. Can you do some tests on Windows and tell us how SCardReconnect() behaves on Windows? Thanks [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa379797%28v=vs.85%29.aspx -- Dr. Ludovic Rousseau
sample.c
Description: Binary data
_______________________________________________ Pcsclite-muscle mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
