This patch may break the PIV card, because it changed the
line 1792: card->max_send_size = 0xffff;
The PIV card does not directly support read/write binary,
but get/put_data commands which transfer the whole object
using adpu chaining using 255 and 256. Its not using extended
apdu either.
To emulate the read/write binary it sets the card_max_* sizes
to 0xffff to allow the caller to read/write the whole object
rather then 255 byte chunks or records.
So the max_*_size values are used in two different ways,
for read/write and for apdu lengths.
Since there is no "close" command there is no way to know when
the last write_binary is done. Using the 0xffff a write is done
all in one operation.
The attached patch might work, would would needs to be tested.
(I am on vacation starting today till after the first, so this
is not a good time to make a change.)
The piv_general_io routine that does the sc_transmit_apdu
is also used for a number of other operations, so a lot of testing
will be needed.
Andreas Jellinghaus wrote:
> Mats here has a fix for apdu chaining / the default
> send size is too big. I don't know much about this
> topic, so could you please review this change?
>
> Regards, Andreas
>
> ---------- Weitergeleitete Nachricht ----------
>
> Betreff: Re: [opensc-devel] OpenSC 0.11.12-rc1 release candidate available
> Datum: Donnerstag 17 Dezember 2009
> Von: Mats Andersson <ma...@checkpoint.com>
> An: Andreas Jellinghaus <a...@dungeon.inka.de>, Martin Paljak
> <mar...@paljak.pri.ee>
>
>
> Hi again,
>
> Here is the udiff. I think the patch is safe. However, by itself maybe this
> patch is not worth much, it only solves half of the problem that this is now
> hard-coded in opensc (I just did this for keeping copying to a minimum when I
> did support for a vasco-card).
>
> If cards support extended APDU's they don't need chaining typically (this
> patch will only affect sc_transmit_apdu() when SC_APDU_FLAGS_CHAINING is
> set).
> Anyway, as I said, it would be even more "generic" if one has a flag/option
> on
> card-level which indicates that the card supports chaining (I think it's a
> discoverable capability of the card according to iso7816, I think through ATR
> inspection). Then change the code so that it will "auto-chain" if a larger
> than max_send_size APDU is to be sent (i.e. when extended APDUs are supported
> the max_send_size is set to the max that can be sent with extended APDUs,
> hence no chaining will take place there typically).
>
> I can have a go at such a patch if there is interest. What is the official
> way
> to provide patches/help out with testing/development?
>
> Cheers,
>
> /Mats
>
> On 12/17/09 5:34 PM, "Andreas Jellinghaus" <a...@dungeon.inka.de> wrote:
>
> Hi Mats,
>
> thanks for your patch, I was not aware we had a problem there.
>
> could you resend your patch in unified diff format ("diff -u")?
> that is much easier to review.
>
> I think however the solution is not as simple as this patch -
> some cards support large APDU commands ("extended" are they
> called I think), so I need to check with the development
> team to make sure we don't fix one and break other cards.
>
> so this patch won't go into 0.11.12, but if we can verify
> it fixes a problem and rule out breaking other cards, we
> can have another 0.11.* release for it.
>
> Regards, Andreas
>
> Scanned by Check Point Total Security Gateway.
>
>
> -------------------------------------------------------------
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> opensc-devel mailing list
> opensc-devel@lists.opensc-project.org
> http://www.opensc-project.org/mailman/listinfo/opensc-devel
--
Douglas E. Engert <deeng...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
_______________________________________________
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
