meelab wrote on 11/04/2008 23:30:
J'ai un programme de lecture carte via PC/SC qui utilise potentiellement
des lecteurs avec ou sans contact.
if the "first exchange" is performed by your code, you know in which
reader the card is "inserted", since you know the reader, you should
know the protocol as well.
Non car j'ai potentiellement plusieurs lecteurs, et mon prgm scanne
les lecteurs pour détecter l'insertion. Je ne sais donc pas à priori
dans quel lecteur la carte a été inséré. De plus j'utilise un lecteur
mixte avec / sans contact. et ma carte est elle aussi mixte.
oui, c'est courant, mais les lecteurs "à 2 têtes" exposent souvent
2 lecteurs logiques PC/SC distints. le nombre de lecteurs contactless
sur le marché étant relativement restreint on peut les identifier par
leur nom PC/SC.
en complément de ma réponse sur ats, quel est le besoin de connaitre
le protocole en cours ?
Sur certains ordres spécifiques sans contact (recherche de PPSE), si je
suis en mode contact, l'interface PC/SC se plante avec une erreur bas
niveau. je pense que la carte ne doit pas répondre correctement et
plante les couches basses PC/SC.
"PPSE" pour "PayPass" ?
ils font des cartes PayPass contact ?? (la question n'est pas: peux-t-on
utiliser un code PayPass de test/de qualif. en mode contact).
qu'est-ce qu'un "ordre spécifique sans contact de recherche" ?
une sélection par AID de l'appli. PayPass ?
quelles erreurs ?
(si la carte interdit certaines opérations en RF, c'est à elle de se
protéger, pas à l'appli d'espérer que le lecteur donne l'info pour
s'interdire d'utiliser l'opération en question).
Dans le principe oui, si la réponse de la carte est correcte avec SW
approprié. Mais en l'occurence c'est surtout pour contourner un bug de
l'interface PC/SC ou de la carte.
si vous pensez que votre couche PC/SC est buggée, n'espérez pas qu'elle
vous indique - par quelque moyen - le protocole utilisé, la réponse
sera sûrement buggée. dans la pratique, les stacks PC/SC sont très peu
buggés (les drivers lecteurs, CCID ou full, le sont plus souvent).
et btw, vous n'indiquez pas votre environnement, ni votre stack PC/SC.
si l'un ou l'autre est corrompu le protocole (ISO-7816-3 ou 14443-3)
peut être impacté, parler d'un "SW approprié" (appartenant au layer 4)
ne fait que mélanger les sources possibles de pb.
dans le même temps, le "approprié" devrait être "conforme à sa spec",
avez-vous des écarts par rapport à celle-ci ?
bien sur d'apparents "téléscopages" entre transport et applicatif
peuvent apparaitre mais ils sont implicite pour une spec donné -
par exemple une carte B0' franco-française réponds *rien* sur une
mauvaise commande (elle part en boucle infinie), le lecteur plante
en timeOut, le transport pourrait être accusé mais c'est dans la spec.
> depending on reader's drivers you can also obtain an ATR with
> special DO when it's built from an ATS.
J'ai déjà essayé, mais la carte que je lis est mixte avec/sans contact,
pourtant elle rend un ATS identique à l'ATR.
PC/SC 2.0.1 décrit comment mapper un ATS dans un ATR conforme, un
driver "trop zélé" (en fait conforme) peut masquer cette info.
Sylvain.
