Hi all.
The first development version of a Linux PC/SC and CT-API driver for the ORGA
ECO 5000 card reader can be found at
http://www.cardcontact.de
Please feel free to provide comments at [EMAIL PROTECTED]
Andreas
***
Linux Smart Car
.de/SICA/mkt/mkt.html
Unfortunately it is in German only.
Andreas
--
Andreas Schwier Tel. +49 171 8334920
CardContact Software & System Consulting
http://www.cardcontact.de
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movemen
extensions to the CT-API
interface in the ECO driver to enable access to memory cards using the
functions defined by Dave, but I recommend an extension to PCSC lite to
integrate support for synchronous cards in the SCardTransmit() function call.
--
Andreas Schwier Tel. +49 171
(SW2)
Andreas
--
Andreas Schwier Tel. +49 171 8334920
CardContact Software & System Consulting
http://www.cardcontact.de
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
e
> to improve the quality of the drivers.
I'm very interested in such a test program, because I already thought about
writing one myself. Do you also test the implementation of the Interindustry
Command Set for synchronous cards (SELECT, READ BINARY, UPDATE BINARY etc.) ?
This would be v
the
IFD handler. The IFD handler needs to do the mapping and shall return an error
if he is not successfull.
Andreas
--
Andreas Schwier Tel. +49 171 8334920
CardContact Software & System Consulting
http://www.cardcontact.de
maximum
amount of data that may be returned". I would not consider this a safe design.
Any comments.
--
Andreas Schwier Tel. +49 171 8334920
CardContact Software & System Consulting
http://www.cardcontact.de
***
Linux Smart Ca
sion).
I know that this is an ugly problem, but I would still recommend to change the
interface declaration to archive cross platform compatibility and avoid hard to
find errors as the one above.
Any comments ?
--
Andreas Schwier Tel. +49 171 8334920
CardContact Software & System Consult
from the web), just let me know.
Andreas
--
Andreas Schwier Tel. +49 171 8334920
CardContact Software & System Consulting
http://www.cardcontact.de
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart C
cards should have the same endianness. This is crazy that people haven't
> learned their lessons on this one yet.
That's a little bit more tricky, as the keys are usually stored in specific
areas in the card. This would clearly be the job of a card service provide in
PC/SC. On top
Hi everyone
We've released a new version of the ECO 5000 driver at www.cardcontact.de
--
Andreas Schwier Tel. +49 171 8334920
CardContact Software & System Consulting
http://www.cardcontact.de
***
Linux Smart Card D
4 << help;
else
pt->Number_of_Data_Units = 256;
Hope this helps. Additional information is contained in the MCT specifications.
You will find a link on our website.
Andreas
--
Andreas Schwier Tel. +49 171 8334920
CardContact Software & System Cons
NERIC, that
handles T=0, T=1 or memory card translation internally in the PC/SC (or reader)
driver. Maybe that is what PROTOCOL_RAW was initially invented for.
Or is anyone out there able to explain the use of the PCI data structure to me ?
Andreas
--
Andreas Schwier Tel. +49 171 83
, the card will not be
able to change it anyway.
Andreas
--
Andreas Schwier Tel. +49 171 8334920
CardContact Software & System Consulting
http://www.cardcontact.de
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for
et seens a memory
card that returns 3B or 3F in the ATR.
Andreas
--
Andreas Schwier Tel. +49 171 8334920
CardContact Software & System Consulting
http://www.cardcontact.de
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movem
Hi Naomaru
Our driver for the ORGA ECO 5000 automatically sends GET_RESPONSE; if the
card returns '61 xx' or '9F xx' and the application passed a case 4 command
APDU to the reader. The class byte for GET_RESPONSE is copied from the class
byte used for the original command.
IMHO this is the way i
> Most of the drivers pass the 61 XX back to the application to handle. I
> think it is bad practice to handle this in the driver since it is a card
> specific ISO function.
GET RESPONSE is a transport level command. It should therefore be invisible
for the application. The problem arises if you
> In the perfect world yes ! but, sadly, people sometimes doesn't follow
> correctly the ISO7816 or misunderstood it. I have cards (W4SC as an
> example) which send back a GET RESPONSE even for a APDU without data.
> This is really annoying as I have to modify my application to take care
> of this
18 matches
Mail list logo