Re: Memory Card support under MUSCLE
On Tue, 17 Apr 2001, David Corcoran wrote: > Hello, > > The error is normal since the card really isn't being powered up. Memory > cards do not all have ATR's and some of them that do don't always follow a > particular pattern. In this case the debug message could be more descriptive, like: "Synchronous ICC present, not powered up". > One way you can bypass this is to just return a bogus > ATR such as 3B 00 or just 3B for every memory card that is inserted. The > card service provider which sits on top of PC/SC will then manage > identifying the card. > I would better use the encoding rules for memory card's ATR. *** 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: Memory Card support under MUSCLE
Hi, On Tue, 17 Apr 2001, David Corcoran wrote: > Hi, > > The ATR is parsed because the Resource Manager has to determine which > protocols can be used on the card and is in charge of sending a PTS when > the application has the choice of T=0 or T=1 and chooses the one that is > not default. The driver could also do this instead of the RM but when I > proposed that I didn't get very positive results from the responses : ) > In my opinion it would be better if the PCSC neither care about T=0, T=1 or memory card detection. Then it would be driver resposibility to: * On card initialization determine card type and ATR if it exists. * Store status information and ATR in some kind of internal hash table correlated to the ctn (in CT-API) or lun (in ifd handler), so it can be looked up when a command is sent to this particular ctn/lun number. Some drivers works like this and in fact ignore protocol information passed back by the pcsc, because they already have it. However not all drivers works this way. So I think the pcscd can just _try_ to parse the ATR in order to provide card type/protocol information to the drivers that don't do this by themselves. If the parsing fails, pcscd shouldn't modify the ATR neither return any error. > > I think an easy way to do this is to send back a bogus ATR such as > > Say your ATR for a memory card is: AD FE AC DE > > > 3B 04 ad fe ac de > > 1) You must send 3B. > 2) Then send the memory card's ATR as historical bytes in > this bogus ATR . > Most memory cards (mainly 2 wire and 3 wire) have an scheme to encode it's size on the ATR. The parsing routine should be able to recoginze this format (see http://www.panstruga.de/ct-api/spec/spec_v09.html Part 5). For I2C cards without ATR we can either return 0 length ATR or format a bogus ATR following 2 wire / 3 wire rules. *** 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: Memory Card support under MUSCLE
Hi > The ATR is parsed because the Resource Manager has to determine which > protocols can be used on the card and is in charge of sending a PTS when > the application has the choice of T=0 or T=1 and chooses the one that is > not default. The driver could also do this instead of the RM but when I > proposed that I didn't get very positive results from the responses : ) ATRDecodeATR() should ignore any ATR that does not start with 3B or 3F and should assume a memory card instead. Most memory/logic cards support the ISO7816-3 ATR for synchronous cards. This is either 16 or 32 bits long. For cards not supporting the ATR (e.g. card with I2C bus protocol) it is common practice to read the ATR from the first 4 bytes in memory. For memory cards it is the responsibility of the reader driver to select the appropriate protocol, but it still is important for the application to receive the ATR. Quite often the application uses the ATR to determine the size of memory available. The MCT specification contains a definition for the ATR. > I think an easy way to do this is to send back a bogus ATR such as > > Say your ATR for a memory card is: AD FE AC DE > > > 3B 04 ad fe ac de > > 1) You must send 3B. > 2) Then send the memory card's ATR as historical bytes in > this bogus ATR . IMHO it should not do that. The most common memory cards (I2C, 2Wire, 3 Wire) return either 8x, 9x or Ax in the first byte. I have not yet seens a memory card that returns 3B or 3F in the ATR. 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 ***
Re: Memory Card support under MUSCLE
Hi, The ATR is parsed because the Resource Manager has to determine which protocols can be used on the card and is in charge of sending a PTS when the application has the choice of T=0 or T=1 and chooses the one that is not default. The driver could also do this instead of the RM but when I proposed that I didn't get very positive results from the responses : ) I think an easy way to do this is to send back a bogus ATR such as Say your ATR for a memory card is: AD FE AC DE 3B 04 ad fe ac de 1) You must send 3B. 2) Then send the memory card's ATR as historical bytes in this bogus ATR . Just a thought. Any ideas ?? Dave *** 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: Memory Card support under MUSCLE
Hello, The error is normal since the card really isn't being powered up. Memory cards do not all have ATR's and some of them that do don't always follow a particular pattern. One way you can bypass this is to just return a bogus ATR such as 3B 00 or just 3B for every memory card that is inserted. The card service provider which sits on top of PC/SC will then manage identifying the card. Dave *** 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: Memory Card support under MUSCLE
Hi, > it will make the return ATR length zero > This will cause EHSpawnEventHandler: power up fail The only issue is that the debug message Power Up Fail is printed. The card should work the same if you send the appropiate commands. However I also don't understand why the ATR is parsed by the pcsc subsystem. Wouldn't it be better if it were returned as transparent data to the user level? Which is the reason for parsig the ATR in the pcscd? __ 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 ***
