2015-11-13 21:23 GMT+01:00 Marcin Cieslak <[email protected]>: > On Fri, 13 Nov 2015, Ludovic Rousseau wrote: > > > 2015-11-13 15:35 GMT+01:00 Marcin Cieslak <[email protected]>: > > > > > This happens when passing data to CT API: > > > > > > char CT_data(unsigned short ctn, /* Terminal Number */ > > > unsigned char *dad, /* Destination */ > > > unsigned char *sad, /* Source */ > > > unsigned short lc, /* Length of command */ > > > unsigned char *cmd, /* Command/Data Buffer > */ > > > unsigned short *lr, /* Length of Response > */ > > > unsigned char *rsp /* Response */ > > > > > > The supplied buffer length on my system, 65548 (hex 0x1000c) gets > > > downcast to (unsigned short), which is 12. > > > > > > CT-API will not accept a buffer longer than 64KB. (No wonder given its > > > origins). > > > > > > > Maybe you can fix CT-API API to use "unsigned int" for a buffer size > > instead of "unsigned short". > > No, one can't. The CT-API specification says the length of response > is "IU16" - integer, unsigned, 16bit. > > https://www.tuvit.de/cps/rde/xbcr/tuevit_de/CTAPI11EN.pdf > > as far as I know most card readers produced or designed in Germany > use CT-API internally even if they expose PC/SC interface. >
Well, maybe not fix CT-API but at least fix the driver you are using. I guess you do not use CT-API if you use PC/SC. CT-API is just an internal API. I seriously doubt such the readers accept larger buffer sizes. > > 8eb9ea1b354b050f997d003cf3b0c5b56f29f9f7 is strange because > requested buffer size given by the client application is no > longer used(!), only maximal value is used. > The size given by the client is used to report an error if the buffer is too small. The test is performed _after_ the command has been sent to the cardreader + card. I do not plan to change pcsc-lite just because CT-API is limited. Regards, -- Dr. Ludovic Rousseau
_______________________________________________ Pcsclite-muscle mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pcsclite-muscle
