Menu
▾
▴
opensc-devel
|
From: Chris J A. <chr...@gm...> - 2013-02-13 15:55:36
|
Hello, I've been trying to connect to an OpenVPN server with the .p12 key stored on my smartcard. I can connect to the OpenVPN server when not using the smartcard. This worked previously on my Ubuntu 12.04 install, but in 12.10 and 13.04 this is failing to work. When connecting it hangs at the line: PKCS#11: __pkcs11h_forkFixup entry pid=2475, activate_slotevent=1 I'm not sure where the problem occurs, however it seems like somebody on this mailing list, or Ludovic might be the person to ask. : ) I'm using a gemalto PC express smartcard reader (08e6:34ec) with an EnterSafe smartcard. According to the logs opensc-pkcs11 seems to think that the card has been removed, even though I have never moved it from the reader. The versions I am currently running with are: pcscd 1.8.8-1 libpcsclite1 1.8.8-1 pcsc-tools 1.4.21-1 libccid 1.4.9-1 opensc 0.12.2-2ubuntu2 libp11-2 0.2.8-2build1 libengine-pkcs11-openssl 0.1.8-2build1 openvpn 2.2.1-8ubuntu2 I have attached a verbose log from openvpn with opensc debug output printed to stdout. In addition I captured a pcscd log and attached it as well. Finally, I've attached the openvpn conf file I've been using to connect in case there is user error here. However, I know this configuration works in older version of the software. I'd like to help debug this as much as I can, so please let me know if this is a known issue, or if there is software versions / patches I can test. Any clues or places to look at in the code would be useful and I can try to debug further. Thanks, --chris j arges |
|
From: Alon Bar-L. <alo...@gm...> - 2013-02-13 16:15:26
|
Can you please attach the opensc debug log as well? On Wed, Feb 13, 2013 at 5:55 PM, Chris J Arges <chr...@gm...> wrote: > Hello, > I've been trying to connect to an OpenVPN server with the .p12 key > stored on my smartcard. I can connect to the OpenVPN server when not > using the smartcard. This worked previously on my Ubuntu 12.04 install, > but in 12.10 and 13.04 this is failing to work. When connecting it hangs > at the line: > PKCS#11: __pkcs11h_forkFixup entry pid=2475, activate_slotevent=1 > > I'm not sure where the problem occurs, however it seems like somebody on > this mailing list, or Ludovic might be the person to ask. : ) > > I'm using a gemalto PC express smartcard reader (08e6:34ec) with an > EnterSafe smartcard. According to the logs opensc-pkcs11 seems to think > that the card has been removed, even though I have never moved it from > the reader. > The versions I am currently running with are: > pcscd 1.8.8-1 > libpcsclite1 1.8.8-1 > pcsc-tools 1.4.21-1 > libccid 1.4.9-1 > opensc 0.12.2-2ubuntu2 > libp11-2 0.2.8-2build1 > libengine-pkcs11-openssl 0.1.8-2build1 > openvpn 2.2.1-8ubuntu2 > > I have attached a verbose log from openvpn with opensc debug output > printed to stdout. In addition I captured a pcscd log and attached it as > well. Finally, I've attached the openvpn conf file I've been using to > connect in case there is user error here. However, I know this > configuration works in older version of the software. I'd like to help > debug this as much as I can, so please let me know if this is a known > issue, or if there is software versions / patches I can test. Any clues > or places to look at in the code would be useful and I can try to debug > further. > > Thanks, > --chris j arges > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > |
|
From: Chris J A. <chr...@gm...> - 2013-02-13 16:22:42
Attachments:
opensc-debug.log
|
On 02/13/2013 10:15 AM, Alon Bar-Lev wrote: > Can you please attach the opensc debug log as well? > Attached is a log from a different run, but the results were the same. I can recollect all logs if necessary. Thanks, --chris j arges > On Wed, Feb 13, 2013 at 5:55 PM, Chris J Arges > <chr...@gm...> wrote: >> Hello, >> I've been trying to connect to an OpenVPN server with the .p12 key >> stored on my smartcard. I can connect to the OpenVPN server when not >> using the smartcard. This worked previously on my Ubuntu 12.04 install, >> but in 12.10 and 13.04 this is failing to work. When connecting it hangs >> at the line: >> PKCS#11: __pkcs11h_forkFixup entry pid=2475, activate_slotevent=1 >> >> I'm not sure where the problem occurs, however it seems like somebody on >> this mailing list, or Ludovic might be the person to ask. : ) >> >> I'm using a gemalto PC express smartcard reader (08e6:34ec) with an >> EnterSafe smartcard. According to the logs opensc-pkcs11 seems to think >> that the card has been removed, even though I have never moved it from >> the reader. >> The versions I am currently running with are: >> pcscd 1.8.8-1 >> libpcsclite1 1.8.8-1 >> pcsc-tools 1.4.21-1 >> libccid 1.4.9-1 >> opensc 0.12.2-2ubuntu2 >> libp11-2 0.2.8-2build1 >> libengine-pkcs11-openssl 0.1.8-2build1 >> openvpn 2.2.1-8ubuntu2 >> >> I have attached a verbose log from openvpn with opensc debug output >> printed to stdout. In addition I captured a pcscd log and attached it as >> well. Finally, I've attached the openvpn conf file I've been using to >> connect in case there is user error here. However, I know this >> configuration works in older version of the software. I'd like to help >> debug this as much as I can, so please let me know if this is a known >> issue, or if there is software versions / patches I can test. Any clues >> or places to look at in the code would be useful and I can try to debug >> further. >> >> Thanks, >> --chris j arges >> >> ------------------------------------------------------------------------------ >> Free Next-Gen Firewall Hardware Offer >> Buy your Sophos next-gen firewall before the end March 2013 >> and get the hardware for free! Learn more. >> http://p.sf.net/sfu/sophos-d2d-feb >> _______________________________________________ >> Opensc-devel mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/opensc-devel >> |
|
From: Ludovic R. <lud...@gm...> - 2013-02-17 15:42:34
|
2013/2/13 Chris J Arges <chr...@gm...>: > On 02/13/2013 10:15 AM, Alon Bar-Lev wrote: >> Can you please attach the opensc debug log as well? >> > > Attached is a log from a different run, but the results were the same. I > can recollect all logs if necessary. The PKCS#11 functions from OpenSC all returned CKR_OK. In particular C_Sign() also returned CKR_OK. So at the OpenSC level everything looks fine. I have no idea what is wrong. Bye -- Dr. Ludovic Rousseau |
|
From: Chris J A. <chr...@gm...> - 2013-02-18 15:21:47
|
On 02/17/2013 09:42 AM, Ludovic Rousseau wrote: > 2013/2/13 Chris J Arges <chr...@gm...>: >> On 02/13/2013 10:15 AM, Alon Bar-Lev wrote: >>> Can you please attach the opensc debug log as well? >>> >> >> Attached is a log from a different run, but the results were the same. I >> can recollect all logs if necessary. > > The PKCS#11 functions from OpenSC all returned CKR_OK. In particular > C_Sign() also returned CKR_OK. > So at the OpenSC level everything looks fine. > > I have no idea what is wrong. > If you look earlier in this thread at log_openvpn.txt, you notice that it stops at the following lines: Wed Feb 13 09:51:06 2013 us=360891 TUN/TAP TX queue length set to 100 Wed Feb 13 09:51:06 2013 us=361004 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0 Wed Feb 13 09:51:06 2013 us=361083 /sbin/ifconfig tun0 10.9.8.18 pointopoint 10.9.8.17 mtu 1500 Wed Feb 13 09:51:06 2013 us=362387 PKCS#11: __pkcs11h_forkFixup entry pid=2475, activate_slotevent=1 This is where it hangs when trying to connect, and I have to kill openvpn. This only happens when using libpcsclite1/libpcsclite-dev/pcscd 1.8.6, if I use 1.7.4 then it works (although I still have key renegotiation problems). For a more complete picture of this failure you can look at: http://sourceforge.net/mailarchive/attachment.php?list_name=opensc-devel&message_id=511E99C3.9030505%40gmail.com&counter=1 Can anyone reproduce this issue with OpenVPN/Smartcards? --chris |
|
From: Chris J A. <chr...@gm...> - 2013-02-18 23:54:53
|
On 02/17/2013 09:42 AM, Ludovic Rousseau wrote:
> 2013/2/13 Chris J Arges <chr...@gm...>:
>> On 02/13/2013 10:15 AM, Alon Bar-Lev wrote:
>>> Can you please attach the opensc debug log as well?
>>>
>>
>> Attached is a log from a different run, but the results were the same. I
>> can recollect all logs if necessary.
>
> The PKCS#11 functions from OpenSC all returned CKR_OK. In particular
> C_Sign() also returned CKR_OK.
> So at the OpenSC level everything looks fine.
>
> I have no idea what is wrong.
>
> Bye
Ok I've found a workaround that allows me to connect and it is related
to OpenSC.
It seems that _WIN32 is being defined (on a Linux system) when I build
OpenSC from the latest git source. And this was causing an issue in
C_Initialize that made it immediately C_Finalize. I used the following
patch to hack around this, and now OpenVPN connects using a smartcard
via OpenSC.
diff --git a/src/pkcs11/pkcs11-global.c b/src/pkcs11/pkcs11-global.c
index 5652975..bbf897b 100644
--- a/src/pkcs11/pkcs11-global.c
+++ b/src/pkcs11/pkcs11-global.c
@@ -199,6 +199,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
sc_context_param_t ctx_opts;
/* Handle fork() exception */
+#if 0
#if !defined(_WIN32)
if (current_pid != initialized_pid) {
C_Finalize(NULL_PTR);
@@ -206,6 +207,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
initialized_pid = current_pid;
in_finalize = 0;
#endif
+#endif
if (context != NULL) {
sc_log(context, "C_Initialize(): Cryptoki already
initialized\n");
However, it seems the larger problem would be disabling _WIN32 from
being defined on Linux systems. I'm not sure if this is a function of
autotool versions or what.
Thanks,
--chris j arges
|
|
From: Alon Bar-L. <alo...@gm...> - 2013-02-19 04:30:45
|
This is strange, can you please send config.log?
On Tue, Feb 19, 2013 at 1:54 AM, Chris J Arges
<chr...@gm...>wrote:
> On 02/17/2013 09:42 AM, Ludovic Rousseau wrote:
> > 2013/2/13 Chris J Arges <chr...@gm...>:
> >> On 02/13/2013 10:15 AM, Alon Bar-Lev wrote:
> >>> Can you please attach the opensc debug log as well?
> >>>
> >>
> >> Attached is a log from a different run, but the results were the same. I
> >> can recollect all logs if necessary.
> >
> > The PKCS#11 functions from OpenSC all returned CKR_OK. In particular
> > C_Sign() also returned CKR_OK.
> > So at the OpenSC level everything looks fine.
> >
> > I have no idea what is wrong.
> >
> > Bye
>
> Ok I've found a workaround that allows me to connect and it is related
> to OpenSC.
>
> It seems that _WIN32 is being defined (on a Linux system) when I build
> OpenSC from the latest git source. And this was causing an issue in
> C_Initialize that made it immediately C_Finalize. I used the following
> patch to hack around this, and now OpenVPN connects using a smartcard
> via OpenSC.
>
> diff --git a/src/pkcs11/pkcs11-global.c b/src/pkcs11/pkcs11-global.c
> index 5652975..bbf897b 100644
> --- a/src/pkcs11/pkcs11-global.c
> +++ b/src/pkcs11/pkcs11-global.c
> @@ -199,6 +199,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
> sc_context_param_t ctx_opts;
>
> /* Handle fork() exception */
> +#if 0
> #if !defined(_WIN32)
> if (current_pid != initialized_pid) {
> C_Finalize(NULL_PTR);
> @@ -206,6 +207,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
> initialized_pid = current_pid;
> in_finalize = 0;
> #endif
> +#endif
>
> if (context != NULL) {
> sc_log(context, "C_Initialize(): Cryptoki already
> initialized\n");
>
> However, it seems the larger problem would be disabling _WIN32 from
> being defined on Linux systems. I'm not sure if this is a function of
> autotool versions or what.
>
> Thanks,
> --chris j arges
>
>
>
|
|
From: Ludovic R. <lud...@gm...> - 2013-02-19 08:19:27
|
2013/2/19 Chris J Arges <chr...@gm...>:
> Ok I've found a workaround that allows me to connect and it is related
> to OpenSC.
>
> It seems that _WIN32 is being defined (on a Linux system) when I build
> OpenSC from the latest git source. And this was causing an issue in
> C_Initialize that made it immediately C_Finalize. I used the following
> patch to hack around this, and now OpenVPN connects using a smartcard
> via OpenSC.
_WIN32 is NOT defined.
What your patch does is to remove code used when _WIN32 is not defined.
Look at the ! (negation) in:
#if !defined(_WIN32)
> diff --git a/src/pkcs11/pkcs11-global.c b/src/pkcs11/pkcs11-global.c
> index 5652975..bbf897b 100644
> --- a/src/pkcs11/pkcs11-global.c
> +++ b/src/pkcs11/pkcs11-global.c
> @@ -199,6 +199,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
> sc_context_param_t ctx_opts;
>
> /* Handle fork() exception */
> +#if 0
> #if !defined(_WIN32)
> if (current_pid != initialized_pid) {
> C_Finalize(NULL_PTR);
> @@ -206,6 +207,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
> initialized_pid = current_pid;
> in_finalize = 0;
> #endif
> +#endif
>
> if (context != NULL) {
> sc_log(context, "C_Initialize(): Cryptoki already
> initialized\n");
>
> However, it seems the larger problem would be disabling _WIN32 from
> being defined on Linux systems. I'm not sure if this is a function of
> autotool versions or what.
We need to understanf why the code you removed is causing problems. It
is supposed to solve problems :-)
Alon, it looks like you wrote this code. Any idea?
Maybe call C_Finalize() only if initialized_pid has been set (!= -1)?
commit 1875a25c4090b261d9eeb419beeb74bae9735650
Author: alonbl <alonbl@c6295689-39f2-0310-b995-f0e70906c6a9>
Date: Thu Mar 6 14:56:31 2008 +0000
PKCS#11 "Application and processes" instructs the sequence
that should be taken after fork().
Applications should call C_Initialize() immediately after fork()
to reinitialize the provider.
The change monitor the pid that calls C_Initialize(), if it is
different than previous C_Finalize() is called.
Bye
--
Dr. Ludovic Rousseau
|
|
From: Chris J A. <chr...@gm...> - 2013-02-19 18:15:49
|
On 02/19/2013 02:19 AM, Ludovic Rousseau wrote:
> 2013/2/19 Chris J Arges <chr...@gm...>:
>> Ok I've found a workaround that allows me to connect and it is related
>> to OpenSC.
>>
>> It seems that _WIN32 is being defined (on a Linux system) when I build
>> OpenSC from the latest git source. And this was causing an issue in
>> C_Initialize that made it immediately C_Finalize. I used the following
>> patch to hack around this, and now OpenVPN connects using a smartcard
>> via OpenSC.
>
> _WIN32 is NOT defined.
> What your patch does is to remove code used when _WIN32 is not defined.
>
> Look at the ! (negation) in:
> #if !defined(_WIN32)
>
>
You are correct, sorry about the confusion. This is behaving correctly
and I verified in config.log and grepping.
>> diff --git a/src/pkcs11/pkcs11-global.c b/src/pkcs11/pkcs11-global.c
>> index 5652975..bbf897b 100644
>> --- a/src/pkcs11/pkcs11-global.c
>> +++ b/src/pkcs11/pkcs11-global.c
>> @@ -199,6 +199,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
>> sc_context_param_t ctx_opts;
>>
>> /* Handle fork() exception */
>> +#if 0
>> #if !defined(_WIN32)
>> if (current_pid != initialized_pid) {
>> C_Finalize(NULL_PTR);
>> @@ -206,6 +207,7 @@ CK_RV C_Initialize(CK_VOID_PTR pInitArgs)
>> initialized_pid = current_pid;
>> in_finalize = 0;
>> #endif
>> +#endif
>>
>> if (context != NULL) {
>> sc_log(context, "C_Initialize(): Cryptoki already
>> initialized\n");
>>
>> However, it seems the larger problem would be disabling _WIN32 from
>> being defined on Linux systems. I'm not sure if this is a function of
>> autotool versions or what.
>
> We need to understanf why the code you removed is causing problems. It
> is supposed to solve problems :-)
>
I agree.
What I did was instrument this code to print out the pids, I get:
[opensc-pkcs11] pkcs11-global.c:203:C_Initialize: current_pid 4432,
initialized_pid 4417
So they are clearly different, and this makes sense because I think
OpenVPN is forking. Looking at ps I see:
4417 pts/2 SL+ 0:00 /src/openvpn/.libs/lt-openvpn --config
sc.conf --verb
4432 pts/2 S+ 0:00 /src/openvpn/.libs/lt-openvpn --config
sc.conf --verb
> Alon, it looks like you wrote this code. Any idea?
> Maybe call C_Finalize() only if initialized_pid has been set (!= -1)?
>
> commit 1875a25c4090b261d9eeb419beeb74bae9735650
> Author: alonbl <alonbl@c6295689-39f2-0310-b995-f0e70906c6a9>
> Date: Thu Mar 6 14:56:31 2008 +0000
>
> PKCS#11 "Application and processes" instructs the sequence
> that should be taken after fork().
> Applications should call C_Initialize() immediately after fork()
> to reinitialize the provider.
>
> The change monitor the pid that calls C_Initialize(), if it is
> different than previous C_Finalize() is called.
>
Yes, any suggestions to test that openvpn+opensc is doing this properly
would be good. I can try to trace through the code, but perhaps there is
a more simple test.
Thanks,
--chris
|
|
From: Martin P. <ma...@ma...> - 2013-02-20 13:51:02
|
On Tue, Feb 19, 2013 at 10:19 AM, Ludovic Rousseau <lud...@gm...> wrote: > 2013/2/19 Chris J Arges <chr...@gm...>: > We need to understanf why the code you removed is causing problems. It > is supposed to solve problems :-) > > Alon, it looks like you wrote this code. Any idea? > Maybe call C_Finalize() only if initialized_pid has been set (!= -1)? > > commit 1875a25c4090b261d9eeb419beeb74bae9735650 > Author: alonbl <alonbl@c6295689-39f2-0310-b995-f0e70906c6a9> > Date: Thu Mar 6 14:56:31 2008 +0000 > > PKCS#11 "Application and processes" instructs the sequence > that should be taken after fork(). > Applications should call C_Initialize() immediately after fork() > to reinitialize the provider. > > The change monitor the pid that calls C_Initialize(), if it is > different than previous C_Finalize() is called. Looking at PKCS#11 v2.20, 6.6.1 Applications and processes It tells: In the scenario specified above, C should actually call C_Initialize whether or not it needs to use Cryptoki; if it has no need to use Cryptoki, it should then call C_Finalize immediately thereafter. This (having the child immediately call C_Initialize and then call C_Finalize if the parent is using Cryptoki) is considered to be good Cryptoki programming practice, since it can prevent the existence of dangling duplicate resources that were created at the time of the fork() call; however, it is not required by Cryptoki. So maybe "helping" the cryptoki application is actually not a good idea, better report some error or print some fat warning to stderr/out "misbehaving PKCS#11 application". Martin |
|
From: Nikos M. <n.m...@gm...> - 2013-02-20 15:53:36
|
On 02/20/2013 02:50 PM, Martin Paljak wrote: > Looking at PKCS#11 v2.20, 6.6.1 Applications and processes > It tells: > In the scenario specified above, C should actually call C_Initialize > whether or not it needs to use Cryptoki; if it has no need to use > Cryptoki, it should then call C_Finalize immediately thereafter. This > (having the child immediately call C_Initialize and then call > C_Finalize if the parent is using Cryptoki) is considered to be good > Cryptoki programming practice, since it can prevent the existence of > dangling duplicate resources that were created at the time of the > fork() call; however, it is not required by Cryptoki. And that looks like a very good reason why C_Initialize should be simple in OpenSC and not take several seconds (e.g., by trying to probe the inserted cards). Consider enabling smart card support with opensc in a forking server and then realize that each child would wait 4-6 seconds for C_Initialize on creation, irrespective whether smart cards are used on it. regards, Nikos |
|
From: Martin P. <ma...@ma...> - 2013-02-20 17:56:50
|
On Wed, Feb 20, 2013 at 5:53 PM, Nikos Mavrogiannopoulos <n.m...@gm...> wrote: > And that looks like a very good reason why C_Initialize should be > simple in OpenSC and not take several seconds (e.g., by trying to probe > the inserted cards). Consider enabling smart card support with opensc in > a forking server and then realize that each child would wait 4-6 seconds > for C_Initialize on creation, irrespective whether smart cards are used > on it. True, I can only think of some forgotten specifics for 2.11 why slots are created on C_Initialize rather than C_GetSlotList. Martin |
|
From: Douglas E. E. <dee...@an...> - 2013-02-20 20:13:33
|
On 2/20/2013 11:56 AM, Martin Paljak wrote: > On Wed, Feb 20, 2013 at 5:53 PM, Nikos Mavrogiannopoulos > <n.m...@gm...> wrote: >> And that looks like a very good reason why C_Initialize should be >> simple in OpenSC and not take several seconds (e.g., by trying to probe >> the inserted cards). Consider enabling smart card support with opensc in >> a forking server and then realize that each child would wait 4-6 seconds >> for C_Initialize on creation, irrespective whether smart cards are used >> on it. > > True, I can only think of some forgotten specifics for 2.11 why slots > are created on C_Initialize rather than C_GetSlotList. Yes there is a difference. PKCS #11 2.11, revision 1, November 2001 Section 11.5 Slot and token management functions All slots which C_GetSlotList reports must be able to be queried as valid slots by C_GetSlotInfo. Furthermore, the set of slots accessible through a Cryptoki library is fixed at the time that C_Initialize is called. If an application calls C_Initialize and C_GetSlotList, and then the user hooks up a new hardware device, that device cannot suddenly appear as a new slot if C_GetSlotList is called again. To recognize the new device, C_Initialize needs to be called again (and to be able to call C_Initialize successfully, C_Finalize needs to be called first). Even if C_Initialize is successfully called, it may or may not be the case that the new device will then be successfully recognized. On some platforms, it may be necessary to restart the entire system. PKCS#11 2.20 Section 11.5 Slot and token management functions All slots which C_GetSlotList reports must be able to be queried as valid slots by C_GetSlotInfo. Furthermore, the set of slots accessible through a Cryptoki library is checked at the time that C_GetSlotList, for list length prediction (NULL pSlotList argument) is called. If an application calls C_GetSlotList with a non-NULL pSlotList, and then the user adds or removes a hardware device, the changed slot list will only be visible and effective if C_GetSlotList is called again with NULL. Even if C_ GetSlotList is successfully called this way, it may or may not be the case that the changed slot list will be successfully recognized depending on the library implementation. On some platforms, or earlier PKCS11 compliant libraries, it may be necessary to successfully call C_Initialize or to restart the entire system. The way I read these, we could move the call for the card_detect out of C_Initialize. A 2.11 caller does not know if C_Initialize has done anything with slots until a call is made that needs to get slots and at that time the 2.11 caller expects the number of slots will be fixed and would not be trying to use the 2.20 requirement to call C_GetSlotList with a NULL pSlotList to get a new list of slots. The issue is then if any internal OpenSC code depends on the card_detect being called early. > > Martin > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@an...> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 |
|
From: Martin P. <ma...@ma...> - 2013-02-21 05:53:25
|
On Wed, Feb 20, 2013 at 10:13 PM, Douglas E. Engert <dee...@an...> wrote: > The way I read these, we could move the call for the card_detect out of > C_Initialize. A 2.11 caller does not know if C_Initialize has done > anything with slots until a call is made that needs to get slots > and at that time the 2.11 caller expects the number of slots will be fixed > and would not be trying to use the 2.20 requirement to call C_GetSlotList > with a NULL pSlotList to get a new list of slots. > > The issue is then if any internal OpenSC code depends on the card_detect being > called early. That seems like a safe choice. In fact, I did not understand why the card detection was not made a conditional depending on the 2.20 mode in the first place. This is far from the original problem (C_Finalize in C_Inititialize) though :) Martin |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X