Magnus,
If this gets through, it will be the first time for a long time that OCF has
accepted a posting from me - it didn't like something about Pegasus Mail,
but might accept a message from Outlook Express.
7816-3 is very complicated and obscure in parts, but I think your ATR gives:
3B Direct convention
ED bytes TB1, TC1, TD1 follow, and then 14 historical bytes
00 FF 81 are:
00 II=0, PI1=0 (not relevant, as these relate only to cards with separate
programming supply Vpp)
FF min of 11 etu for each byte
81 T=1, next byte is TD2
31 T=1, TA3 and TB3 to follow (these are T=1 controls)
42 TA3
45 TB3
Now you should have 13 historical bytes, plus a checksum byte - so the 89 is
the checksum, which your own implementation has somehow lost from the hex
display of the ATR - but it seems to be there in the text display of the ATR
(a ".")
Peter Tomlinson
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, January 19, 2001 9:46 AM
Subject: [OCF] ATR differs on different terminals???
Hi all,
My first posting... I am VERY proud :)
Well, here is my problem:
I have downloaded IBM's reference implementation of Embedded OCF
(TOCF) and I have it up and running with GCR410. Then I have also
managed to put TOCF on an embeeded device with a built-in card
terminal. After quite some time I now have a (seemingly) working
driver so that TOCF can be used to access this card terminal.
Now comes the strange thing: When reading files from the same card I
get the same result on both platforms. But the ATR differs.
Here's a small printout:
----------------------------------------------------------------------
The OpenCard democard (the white one :), jdk1.1.8 on WinNT, TOCF
(IBM's reference implementation), GCR410:
ATR:
0000: 3B ED 00 FF 81 31 42 45 7E 04 00 01 49 42 4D 20 ;....1BE~...IBM
0010: 53 43 20 31 30 89 SC 10.
Historical:
0000: 7E 04 00 01 49 42 4D 20 53 43 20 31 30 ~...IBM SC 10
Select file on EF_DIR (2f00) (APDU: a4 a4 00 00 02 2f 00)
Length of response: 17
Response bytes on select file:
0000: 63 0D 00 50 2F 00 01 00 03 FF FF C3 02 01 28 90 c..P/.........(.
0010: 00 .
----------------------------------------------------------------------
The OpenCard democard (still white), pjava 3.0.2, TOCF (IBM's
ref. impl., but with my own card terminal implementation), TDA8006AH:
ATR:
0000: 3B ED 00 FF 81 31 42 45 7E 04 00 01 49 42 4D 20 ;....1BE~...IBM
0010: 53 43 20 31 30 00 SC 10.
Historical:
0000: 7E 04 00 01 49 42 4D 20 53 43 20 31 30 ~...IBM SC 10
Select file on EF_DIR (2f00) (APDU: a4 a4 00 00 02 2f 00)
Length of response: 17
Response bytes on select file:
0000: 63 0D 00 50 2F 00 01 00 03 FF FF C3 02 01 28 90 c..P/.........(.
0010: 00 .
----------------------------------------------------------------------
As you can see the ATR differs slightly (the last byte) while the
response on select_file stays the same. Something I have missed?
Something I should have done to the ATR directly after receiving it
from the card terminal?
Since the response on the APDU is the same in both cases I assume that
my driver reads the data sent from the card terminal correctly.
/Magnus
--
Magnus Therning
[EMAIL PROTECTED]
+31-40-27 45179
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.
