Re: RE :MUSCLE memory-cards and muscle?
Thomas Schmidt wrote: Hello, i'm new in this list because i'm intrested in this smartcard theme, but also because i've a very actual problem with towitoko2.0.2 driver and pcsc-lite-0.8.4. The problem was already discussed in the "MUSCLE memory-cards and muscle?"-thread between the 18.01.2001 and the 21.01.2001. I wouldn't contact the list when i would be able to find the "sc_filesystem.c"-file or the "SCSelectFile"-function with the "sRecvPci.dwProtocol"/"sSendPci.dwProtocol" variables. Surely i'm "blind" or something like that maybe somebody could help me and tell me where to find this part ... ( phuuu i feel sooo stupid *lol*) wfg (mfg) Thomas -- Thomas Schmidt ||[EMAIL PROTECTED] http://www.md-network.de/ ||registered LINUX user No.: 171016 === -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/U d-(?) s:@ a-- C++ UL++()$ P++()$ L++() E W- N++ o K- w O M- V- PS+ PE++ Y+ PGP t 5 X+ R tv++ b++ DI-- D+ G++ e* h* r-- y? --END GEEK CODE BLOCK-- *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html *** Hi, sc_filesystem.c is a file that i had created in order to wrap the APDU command. So it's natural you don't have. Lucky you are not Blind ;-) In fact the important things of this file are in the posted mail : In order to call the function SCardTransmit you need to pass an argument of type SCARD_IO_REQUEST. This structure has an attribut called dwProtocol which takes the following values : SCARD_PROTOCOL_RAW, SCARD_PROTOCOL_T0, SCARD_PROTOCOL_T1. However in my case the value needed was 0. Christian Jean *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: RE :MUSCLE memory-cards and muscle?
--- Andreas Schwier [EMAIL PROTECTED] escribi: Hello On Sam, 20 Jan 2001, you wrote: I never really understood the reason for handling the transmission protocols at application level. For the application it should not matter, if the card uses T=0, T=1 or a memory card interface, What happens if card supports more than one transmission protocol? In't bad to have the chance to specify wich of them the application wants to use? Yes, absolutely. The application should specify the desired protocol option in SCardConnect. But once the protocol is selected with PTS, the card will not be able to change it anyway. Yes, SCardConnect() seems to be the rigth place to specify the protocol (better than SCardTransmit()). Also SCardReconnect could be used to reset the card and specify another protocol, I think. Carlos. __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: RE :MUSCLE memory-cards and muscle?
Hello, --- Andreas Schwier [EMAIL PROTECTED] escribi: Hi Dave I never really understood the reason for handling the transmission protocols at application level. For the application it should not matter, if the card uses T=0, T=1 or a memory card interface, What happens if card supports more than one transmission protocol? In't bad to have the chance to specify wich of them the application wants to use? it should just handle command and response APDU's. I suggest to introduce a PROTOCOL_GENERIC, that handles T=0, T=1 or memory card translation internally in the PC/SC (or reader) driver. Maybe that is what PROTOCOL_RAW was initially invented for. I agree that for cards with only one protocol (most smartcards and memorycards), something like PROTOCOL_AUTO, PROTOCOL_GENERIC or just passing the SCARD_IO_REQUEST = NULL would be fine. Or is anyone out there able to explain the use of the PCI data structure to me ? __ Do You Yahoo!? Yahoo! Auctions - Buy the things you want at great prices. http://auctions.yahoo.com/ *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: RE :MUSCLE memory-cards and muscle?
Hello,
I would put my hand in the fire, and guess that the
following happens with memory cards and protocol RAW:
* The pcsc daemon calls the ifdhandler function
IFDHControl().
* The driver maps the command to a CT command, instead
of a ICC command.
* 6E 00 is returned because this is the CT-BCS return
code when you specify a CLASS byte distinct from 0x20
(wrong class byte for CT-BCS).
It seems that if you specify dwProtocol = 0, then the
pcscd calls the rigth driver function for sending a
ICC command, that is IFDHTransmitToICC()
IMHO think this is a bug in pcscd, because it should
be calling IFDHTransmitToICC() even for memory cards
and IFDHControl() should be used internally by pcscd
but not exported to the user level.
--- [EMAIL PROTECTED] escribi: Hi,
I got the same problem.
I'm using a chip drive driver, a SLE 4428 as a smart
card and
towitoko2.0.2, and pcsc-lite-0.8.4.
I always got the response 6E 00 when i wanted to
select the Master File
(3F00).
(And even if i change the instruction code or
whatever)
However the tester provided with towitoko get the
right answer (90 00).
After searching for 3 days i manage to get the right
answer using
pcsc-lite.
Code generating wrong answer :
file sc_filesystem.c
-
LONG SCSelectFile(SCARDHANDLE hCard, BYTE fileId1,
BYTE fileId2)
{
LONG rv; //The response status
DWORD dwLength = 2;
BYTE bufToRecv[50]={0}; //unsigned char *
bufToRecv
BYTE cmdToSend[7]={1};
SCARD_IO_REQUEST sRecvPci;
SCARD_IO_REQUEST sSendPci;
//sRecvPci.dwProtocol = 0;
//sSendPci.dwProtocol = 0;
sRecvPci.dwProtocol = SCARD_PROTOCOL_RAW;
sSendPci.dwProtocol = SCARD_PROTOCOL_RAW;
cmdToSend[0] = 0xC0; // Class (Same result with
0x00)
cmdToSend[1] = 0xa4; // INS : Select APDU
cmdToSend[2] = 0x00; // P1 : 00 (Select by file
id)
cmdToSend[3] = 0x00; // P2 : 00 (Return the FCI)
cmdToSend[4] = 0x02; // Length of the data field
(Here 2 bytes)
cmdToSend[5] = fileId1; // 1st byte of the fileId.
cmdToSend[6] = fileId2; // 2nd byte of the fileId.
//cmdToSend[7] = 0x00; // Return up to 256 or
65536 response byte.
//cmdToSend[7] Empty
rv = SCardTransmit(hCard, sSendPci, cmdToSend, 7,
sRecvPci,
bufToRecv, dwLength);
if (rv == SCARD_S_SUCCESS dwLength == 2)
{
int i;
printf("PCSC OK: %s\n",
pcsc_stringify_error(rv));
for(i = 0; i dwLength; i++)
{
printf("Result APDU : %x\n",
bufToRecv[i]);
}
return rv;
}
else
{
printf("PCSC ERROR: %s\n",
pcsc_stringify_error(rv));
return rv;
}
}
Now testLib.c
--
dwShareMode = SCARD_SHARE_SHARED;
//dwPreferredProtocols = SCARD_PROTOCOL_T0;
printf("Test SCardConnect ... \n");
rv = SCardConnect(hContext, szReader, dwShareMode,
SCARD_PROTOCOL_RAW,
hCard, dwActiveProtocol);
if ( rv != SCARD_S_SUCCESS )
{
printf("PCSC ERROR: %s\n",
pcsc_stringify_error(rv));
return 1;
}
printf("Connection to the Card Successful ...\n");
printf("Protocol in used : %li ...\n",
dwActiveProtocol);
printf("Testing SCSelectFile ... \n");
rv = SCSelectFile(hCard, fileId[0], fileId[1]);
if ( rv != SCARD_S_SUCCESS )
{
printf("PCSC ERROR: %s\n",
pcsc_stringify_error(rv));
return 1;
}
When i used this piece of code i always got 6e 00.
I noticed that the value of dwActiveProtocol was
equal to 0, whatever
SCARD_PROTOCOL_xxx
i used in the SCardCONNECT function.
So i did this few changes in the SCSelectFile
function
{
sRecvPci.dwProtocol = 0;
sSendPci.dwProtocol = 0;
//sRecvPci.dwProtocol = SCARD_PROTOCOL_RAW;
//sSendPci.dwProtocol = SCARD_PROTOCOL_RAW;
}
I just replace SCARD_PROTOCOL_RAW by 0 and now
everything is working
fine.
What i would like to know is why this behavior ?
Is there a cleaner way to fix that ?
Thanks.
--
Christian Jean
Software Engineer
Celestix Networks PTE LTD : http://www.celestix.com
---
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux
Environment)
http://www.linuxnet.com/smartcard/index.html
***
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***
Re: RE :MUSCLE memory-cards and muscle?
On Fri, Jan 19, 2001 at 01:33:12PM +0800, [EMAIL PROTECTED] wrote:
Hi,
Hi Christian.
I got the same problem.
I'm using a chip drive driver, a SLE 4428 as a smart card and
towitoko2.0.2, and pcsc-lite-0.8.4.
I am using exactly the same configuration, just the smart card is no-name.
And I got exactly the same error-message.
[...]
So i did this few changes in the SCSelectFile function
{
sRecvPci.dwProtocol = 0;
sSendPci.dwProtocol = 0;
//sRecvPci.dwProtocol = SCARD_PROTOCOL_RAW;
//sSendPci.dwProtocol = SCARD_PROTOCOL_RAW;
}
I just replace SCARD_PROTOCOL_RAW by 0 and now everything is working
fine.
Me too. :-))
I more or less started searching for the problem on the wrong position.
Since pcscd always gave the message "eventhandler.c 311:
EHSpawnEventHandler: Error powering up card." I looked at that part of the
code, but found no problem there.
So thanks a lot, I wouldn't have found the problem for the next two weeks,
I'm rather sure...
BTW, now I got the reader and pcscd to work, it's time for some new
smart-cards. ;-) I'm interested in cards featuring crypto functionality, or
PIN-Codes or JavaCard 2.0.
On the Muscle-Homepage some Schlumberger Cards are mentioned, but I don't
know where to get them in Germany. Does anybody know dealers in Germany or
other cards which would provide such functionality?
--
CU,
Patrick.
"Never run on auto-pilot" - The Pragmatic Programmer
PGP signature
Re: RE :MUSCLE memory-cards and muscle?
Hi, That is probably a bug in pcscd in winscard.c SCardTransmit PROTOCOL_RAW automatically maps to IFDHControl instead of Transmit. Anyone have suggestions on how I can either create a new PROTOCOL_MEMORY or something. Dave * David Corcoran Internet Security/Smartcards Home: Purdue University 1008 Cherry Lane Department of Computer Science West Lafayette, IN 47906 Home: (765) 463-0096 Cell: (765) 532-6006 http://www.linuxnet.com * *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
Re: RE :MUSCLE memory-cards and muscle?
Hi Dave I never really understood the reason for handling the transmission protocols at application level. For the application it should not matter, if the card uses T=0, T=1 or a memory card interface, it should just handle command and response APDU's. I suggest to introduce a PROTOCOL_GENERIC, that handles T=0, T=1 or memory card translation internally in the PC/SC (or reader) driver. Maybe that is what PROTOCOL_RAW was initially invented for. Or is anyone out there able to explain the use of the PCI data structure to me ? Andreas -- Andreas Schwier Tel. +49 171 8334920 CardContact Software System Consulting http://www.cardcontact.de *** Linux Smart Card Developers - M.U.S.C.L.E. (Movement for the Use of Smart Cards in a Linux Environment) http://www.linuxnet.com/smartcard/index.html ***
