Hi,
That makes sense, since the ACK reply would me mistaken for a status byte.
Moreover, if your card expects incoming data for this bogus command
(from host to card) then it will timeout since at this moment, the
reader will also wait, for SW2. If the command has outgoing data (from
card to host) then it will be lost right after the first byte (read as
SW2).
Regards
Sebastien
Ludovic Rousseau <[email protected]> a écrit :
2011/8/25 Martin Paljak <[email protected]>:
Hello,
On Thu, Aug 25, 2011 at 14:47, Ludovic Rousseau
<[email protected]> wrote:
The realy strange situation is that you can have a working T=0
card+reader with these "invalid" INS bytes.
In your INS exploration program just skip 6X and 9X INS values.
Thanks for the explanation!
For the fun of it I think I'll do the opposite instead:
- make the protocol dependant probing more explicit (for several
stupid reasons I'm using T=0 only currently, as this is the only
"supported algorithm" for Estonian eID cards)
- DO probe the forbidden ranges (not by default though)
- see what happens with different card+reader combos :)
Would it make sense to debug on USB level what is happening at
different situations, to maybe make the CCID driver more robust (==
predictable outcome with different readers)?
You can activate the communication logs in the CCID driver.
But you will not see much more than at the PC/SC level. The error
comes from the reader (I guess), not the CCID driver.
The best would be to log at the card/reader interface. I guess the
CardMan reader do not even try to send the "bogus" APDU to the card
and just reject it.
bye
--
Dr. Ludovic Rousseau
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
