[Pcsclite-muscle] Asynchronous PCSC API

[Stephan Brunner]

Hi,

Am Saturday, dem 29.01.2022 um 16:44 +0100 schrieb Ludovic Rousseau:
> Hello,
> 
> Le mer. 26 janv. 2022 à 13:26, Frank Morgner <frankmorgner at gmail.com>
> a écrit :
> > 
> > Last time I tested, SCardCancel didn't abort *anything* on Windows;
> > it
> > didn't even cancel the command for entering the PIN on the reader's
> > PIN pad. Back then, I've also tried stopping the calling process
> > (and
> > invalidating the scardcontext), but still the PIN pad reader was
> > waiting for the PIN until the timeout was reached. As you can see,
> > this is not only a software limitation, but also a limitation in
> > hardware.
> 
> It should be possible to cancel a verify PIN (PC_to_RDR_Secure) using
> the CCID command PC_to_RDR_Abort.
> " This command is used with the Control pipe Abort request to tell
> the
> CCID to stop any
> current transfer at the specified slot and return to a state where
> the
> slot is ready to
> accept a new command pipe Bulk-OUT message. "
> 
> But since the Windows CCID driver does not even support verify PIN I
> am not surprised it is also not possible to cancel it :-)
> 
> My CCID driver does not use PC_to_RDR_Abort either.
> But that would be a technically interesting project to support
> SCardCancel() for SCardControl() and SCardTransmit().
> 
> 
> Ievgenii, Regarding SCardConnect(), I tried your sample code on
> Windows 10.
> I note that ScardConnect() is NOT canceled by SCardCancel().
> 
> The output I have is:
> $ ./cardlock "Alcor Micro USB Smart Card Reader 0"
> connecting...
> beginning transaction...
> status check
> status check
> status check
> status check
> status check
> status check
> status check
> status check
> status check
> status check
> status check
> status check
> status check
> status check
> status check
> 
> And in another window:
> $ ./cardlock_cancel.exe "Alcor Micro USB Smart Card Reader 0"

I'm not very sure about that one as I haven't done anything recent with
PCSC on Windows, but I think SCardCancel has to be issued on the same
handle as the request, thus doing it in the same process on different
threads. And not on a different process or with a different handle.

Otherwise I'd imagine the second context won't get a lock on the reader
or something like that.

> connecting...
> cancelling
> done
> /home/Ludovic/cardlock/cardlock_cancel.c:29 - 0x80100002
> 
> The SCardConnect() in cardlock_cancel does return only after the
> process cardlock has been manually interrupted (by control-C).
> The error code 0x80100002 is SCARD_E_CANCELLED but the cancellation
> is
> NOT working. You get the return value SCARD_E_CANCELLED but only
> after
> the reader has been unlocked by the termination of the ./cardlock
> process.
> 
> Be careful with your CHECK() macro.
> in:
> #define CHECK(rv) \
>  if (rv != SCARD_S_SUCCESS) printf("%d\n", rv);
> rv will be evaluated twice: in the if() and in the printf(). if "rv"
> is a function then the function will be called twice.
> 
> I guess this is NOT what you want.
> Instead use something like:
> #define CHECK(cmd) \
>  DWORD rv = cmd; \
>  if (rv != SCARD_S_SUCCESS) printf("%d\n", rv);
> 
> I then tried the same code on GNU/Linux and I have a behavior a bit
> different.
> $ ./cardlock_cancel "Alcor Micro AU9540 00 00"
> connecting...
> cancelling
> done
> connected
> disconnected
> 
> SCardConnect() is still NOT cancelled. But SCardConnect() *succeeds*
> when the process ./cardlock is terminated instead of returning
> SCARD_E_CANCELLED.
> Since SCardConnect() succeeds the program continues with
> SCardDisconnect() instead of exiting.
> 
> I could modify pcsc-lite to make SCardConnect() cancellable using
> SCardCancel().
> But your code (or any code using this behavior) would then not work
> on
> Windows nor macOS.
> So I am not sure it is a good idea.
> 
> Any thoughts?
> 
> Regards,
> 

-- 
Thanks!

Stephan