Hi. There was a bug in reader-pcsc.c, which made pcsc_disconnect leave the card as is, when it was supposed to reset the card. Fixed this in r3683.
Another change to pcsc_disconnect could be changing SCARD_RESET_CARD to SCARD_UNPOWER_CARD. pcsc_reconnect uses unpower (for protocol forcing reasons) so if it works for in-process resets, it can as well work after we're done with the card. Comments? About your resets: there must be something wrong somewhere if it is not possible to execute two commands in a row and it is clearly a bug, as all tools should leave the reader and card in a clean state. Please re-test with the latest trunk, which actually resets the card after disconnecting. Why do you need to reset the card twice? Doesn't one reset work for you? Please explain. Martin. On 17.04.2009, at 9:28, Marc Rios Valles wrote: > Hi, > > I think we (C3PO) have discovered a bug in the file pcsc-reader.c. > We are developing a card driver that needs to call 2 times each > execution to sc_reset because its a card that works under > secure_channel and we need to assure that we break the secure > channel befor we recreate it. If I execute for example 'pkcs11-tool - > Il' the first execution works correct, but after this exec if I > reexecute 'pkcs11-tool -Il' it waits for a lock of PCSCD that will > never be released. After some tests we have found that if you make 2 > sc_reset() in the same execution of a tool of opensc that executes > that code (pkcs11-tool or pkcs15-tool for example) the next > execution of another tool waits for this lock. We have been looking > at the code of opensc and we have discovered a possible lock that > isn't released. A possible solution is this: > > > =================================================================== > --- OpenSC/trunk/src/libopensc/reader-pcsc.c 2009-04-16 09:54:14 UTC > +++ OpenSC/trunk/src/libopensc/reader-pcsc.c 2009-04-16 13:35:06 UTC > @@ -616,6 +616,8 @@ > > priv->gpriv->SCardDisconnect(pslot->pcsc_card, priv->gpriv- > >transaction_reset ? > SCARD_RESET_CARD : SCARD_LEAVE_CARD); > + > + > memset(pslot, 0, sizeof(*pslot)); > slot->flags = 0; > return SC_SUCCESS; > @@ -699,6 +701,9 @@ > struct pcsc_slot_data *pslot = GET_SLOT_DATA(slot); > int old_locked = pslot->locked; > > + if(old_locked) > + r = pcsc_unlock(reader, slot); > + > r = pcsc_reconnect(reader, slot, 1); > if(r != SCARD_S_SUCCESS) > return pcsc_ret_to_error(r); > > If you add this unlock the code works perfect. > > What do you think about it? Is the best solution? There was a > comment after the pcsc_reconnect call that says that reconnect > relase the lock, but doesn't do it. > > To reproduce this its as easy as put 2 sc_reset in the same code. > > Thanks > -- > Marc Rios Vallès > m...@c3po.es > > C3PO, S.A. > http://www.c3po.es > C/ Alejandro Goicoechea, 6 Local 9 - 08960 St. Just Desvern, Barcelona > Tel. 93 417 99 55 - Fax 93 253 12 80 > > > _______________________________________________ > opensc-devel mailing list > opensc-devel@lists.opensc-project.org > http://www.opensc-project.org/mailman/listinfo/opensc-devel -- Martin Paljak http://martin.paljak.pri.ee +372.515.6495 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
