I'd appreciate any insight into a mental roadblock I've stumbled upon. I'm currently coding a ct-api lib for the GemPlus GPR400 PCMCIA reader (as much of an excercise as it is a usuable tool). I'm using the scez cttest app to double check my work. Now, my confusion arises with tests 2, 3 and 4 of cttest. Test 2 sends a REQUEST ICC (0x20120100), and expects a 0x9001 back. Sure, no problem. This is documented in the CT-BCS spec. Test 3 wants to check the REQUEST ICC once the ICC is already activated. It sends REQUEST ICC (0x20120100), and expects 0x6201 in response (ICC already present and activated). Again, this is documented in CT-BCS spec, and makes sense. HOWEVER, test 4 issues *another* REQUEST ICC, this time with ATR (0x2012010100). Test 4 expects a 0x9001 answer; however, based on test 3 (and the previous REQUEST ICC's), I return 0x6201 (ICC already present and activated). Sooooo....what's the proper way to handle this? Does a REQUEST ICC w/ ATR override the 0x6201 response? The CT-BCS spec doesn't address this. I'm not sure if I'm supposed to track previous REQUEST ICC and issue 0x6201, or not care and issue 0x9001, or do some kind of weird conditional thingy in between. Or is this a bug in cttest? Any help is appreciated. - rfp *************************************************************** 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 ***************************************************************
