reader-proto-not-supported-fix: change returned value to IFD_NOT_SUPPORTED if reader does not support protocol

[mskalski]

reader-proto-not-supported-fix: change returned value to IFD_NOT_SUPPORTED if reader does not support protocol

Commit 8dda132 'Fail if the requested protocol is not supported by
reader' was meant to signal to PC/SC daemon that reader does not support
(i.e by means of its CCID descriptor) requested protocol even if card
supports it.

Unfortunately error IFD_ERROR_NOT_SUPPORTED was selected to return on
such case from CCID, which is not used in error handling of PTS in pcscd
daemon - only IFD_PROTOCOL_NOT_SUPPORTED and IFD_NOT_SUPPORTED are
handled there.

[LudovicRousseau]

I think my code is correct.
What I want is to make PHSetProtocol() to fail and go to https://github.com/LudovicRousseau/PCSC/blob/master/src/prothandler.c#L123

With your patch the code will arrive in https://github.com/LudovicRousseau/PCSC/blob/master/src/prothandler.c#L115 and the wrong protocol will be used.

Or maybe I missed something?

[mskalski]

Assume we have:

• preferred protocols T=0 and T=1
• smart card supporting T=0 and T=1 and having T=0 default protocol.

If both protocols are possible, let's choose T=1.

In such situation I suppose your intention is:

• case A:
  If the driver/reader does not support T=1, let's choose T=0, because it is absolutely OK with what we want.
  It is prothandler.c#115 and IFD_NOT_SUPPORTED.
• case B:
  If the driver/reader does not support PTS, let's choose T=0, because it is absolutely OK with what we want.
  It is prothandler.c#119 and IFD_PROTOCOL_NOT_SUPPORTED.
• case C:
  Any other kind of error, we cannot choose T=0 and we have to return SET_PROTOCOL_PPS_FAILED (prothandler.c#123).
  That way caller (functions SCardConnect() winscard.c:390 or SCardReconnect() winscard.c:683) would fail with PC/SC error SCARD_W_UNRESPONSIVE_CARD.

I expected your change 8dda132 was to allow use cards supporting both protocols on readers with only one protocol supported, so the situation I've described should be "case A" and IFD_NOT_SUPPORTED shall be returned. Do you agree?

[LudovicRousseau]

My change in 8dda132 was to detect and report a problem when you insert a T=1 only card in a T=0 only reader.

I see your point.
The current code will not work if the card supports T=0 and T=1 but the reader supports only T=0.
The preferred protocol will be T=1 and the default will be T=0.
The communication could work using T=0 but the driver will return IFD_ERROR_NOT_SUPPORTED and PHSetProtocol() will fail with SET_PROTOCOL_PPS_FAILED.

Proposal:
If PHSetProtocol() fails with IFD_ERROR_NOT_SUPPORTED and ucDefault is different from ucChosen then we can use the default protocol.

[mskalski]

I didn't think about situation you described (T=1 only card on in T=0 only reader), and in this situation your code was absolutely correct.

And yes, I think adding special handling of IFD_ERROR_NOT_SUPPORTED in PHSetProtocol() function is simplest and most elegant solution.

I was tempted to make fix only in CCID code, but this seems impossible, as it requires knowledge of preferred protocols chosen by user (default and available protocols can be decoded from ATR), so there is no point to complicate IFDHSetProtocolParameters() function.

Would you like me to make a merge request in PCSC with proposed change you described?

[LudovicRousseau]

You can always update your PR with a better solution.

[LudovicRousseau]

Fixed in PCSC LudovicRousseau/PCSC@5d58577
Thanks