Hi Carlos.
Have you tried to split one T=1 APDU into more than
one fragment and send them secuencially to the
reader?
That´s not the real problem. You are right, that
huge amounts of data can be split by using the block
chaining mechanism of the T=1-protocol. The problem
will be, if the card has an IFSC of 255 bytes and the
programmer wants to use the whole range of the card´s
receive buffer. By sending 255 bytes of information
at once (255 bytes of real information, protocol data
not included!), he has to send more than this 255 bytes
to the reader because of the protocol overhead. Try to
tell this to the reader by using one byte for "length
of data to send" :-)
Actually this problem can be solved by not using the
whole receive buffer range of the card, as someone
wrote here. But in order to avoid problems in special
cases this problem has to be shown to programmers, I
think. That´s the reason why I wrote this "bug report"
within the mailinglist, as there should be some
programers using Towitoko-readers :-)
I think that if it is said that you can communicate
transparently with the card by issuing (0x6f, nn,
0x05, qs, t1, t2, ...) commands, it should not matter
how many fragments you use to send one APDU.
As I wrote above: you are right, as long as you only
look at the maximum length possible for one APDU. As
soon as you add the protocol overhead (which has to
be done... :) there will be more than 255 bytes to
send via the drive.
Bye, Mike
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***
