Jim,
You probably mean CWT (calculated from CWI), but the argument probably
applies to both. There is always a conflict between extra guardtime N and
BWT/CWT. N is in TC1, as you say, and this is a global interface byte.
Section 6.5.3 of 7816-3:1997 says: Parameter N is the extra guardtime used
to send characters from the interface device to the card. For T=1, this
guardtime parameter applies AND the BWT/CWT parameters apply. So it would be
sensible for a reader which is trying to make the card work to use N if it
finds a 'reserved' value in TC3; equally, it seems to me that a reader can
also assume that default values of BWT/CWT should be tried, or even that the
card should be rejected.
Unfortunately, the reader has merely said: 'not conforming' and stopped, so
we don't know what it didn't like.
Peter T
Bristol UK
----- Original Message -----
From: "Jim Rees" <[EMAIL PROTECTED]>
To: "Smart Muscleheads" <[EMAIL PROTECTED]>
Sent: Friday, June 29, 2001 1:47 PM
Subject: Re: MUSCLE Error using an IBM MFC in GemPlus readers.
> The Gemplus reader shouldn't wimp out just because BWT is "reserved." My
> Todos driver does its best to talk to the card and uses defaults when the
> protocol parameters don't make sense. There are an amazing number of
cards
> out there that aren't strictly 7816 compliant.
>
> Besides, isn't BWT given by TC1 in this case, not TC3? TC1 isn't present
so
> it defaults? I don't have part 3 in front of me so I could be wrong.
> ***************************************************************
> 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
> ***************************************************************
>
***************************************************************
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
***************************************************************
