Andrey Jivsov wrote:
First, it is unclear what number 248 represents. The lowest common
denominator? T=1 adds 4 bytes of headers+checksum, which gives us 252:
still smaller than 255 or 254 that one might expect to see...
if I remember the statistic ludovic did, all readers support at least
240 bytes or something. to find out which value will work, there is only
trial and error.
What about the readers that support larger packets? I don't think we
need to restricted all the readers this way.
I have no clue: would that restrict them? i.e. take functionality away?
or would opensc only split one command into several smaller ones and
thus preserve functionality, but add more communication overhead and
thus slow down the process.
Which generic reader classes we worry about? It seems to me that only
ccid class is an issue. If this is the case, would it be better to
special-case a few readers by their USB vendorID:prodID in ifd-ccid.c?
I'm not sure what the best way is myself. chaskiel indicated, he would
prefer opensc to deal with it. so not sure what to do.
Regards, Andreas
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
