# [libnfc/pcsc] too smal reply

## Chr0nos

Bonjours, je rencontre un soucis depuis quelques temps avec pcsc-lite et la libnfc:

quand je branche mon lecteur nfc sur le port usb j'ai ca dans les logs:

 *Quote:*   

> 
> 
> Mar 19 16:43:37 StarK kernel: usb 4-2: new full-speed USB device number 9 using uhci_hcd
> 
> Mar 19 16:43:38 StarK kernel: usb 4-2: New USB device found, idVendor=072f, idProduct=2200
> ...

 

et si j'utilise la libnfc pour lister les périfériques ca se corse:

 *Quote:*   

> 
> 
> StarK / # nfc-list 
> 
> nfc-list uses libnfc libnfc-1.7.0-rc6-64-g8485996
> ...

 

d'instalé j'ai:

app-crypt/ccid-1.8.9

app-misc/acsccid-1.0.4

sys-apps/pcsc-lite-1.8.8

sys-apps/pcsc-tools-1.4.21

dev-libs/libnfc-9999 (j'ai aussi tenté avec la 1.5.1 : idem)

le systeme est en ~amd64

du coup je ne sais pas trop comment remedier a mon probleme,

quelqu'un aurait une idée ?

----------

## boozo

'alute

je n'ai pas d'expérience avec de type de périf - sans doute kwen en parlerait mieux - mais cela ressemble à un bug déclaré upstream si tu ne l'as pas déjà vu.

Risque de falloir attendre un correctif ou participer à sa résolution   :Idea: 

----------

## Chr0nos

salut^ oui je sais bien, je suis l'auteur du dernier commentaire (hisoka2...) j'avais bien tenté de contacter les dev mais aucune réaction  :Sad: 

----------

## boozo

mmm dsl m'en doutais un peu mais j'ai tenté qd même   :Sad: 

Sinon, je ne sais pas si tu as regardé/essayé mais dans le readme libnfc on peut lire çà à propos du module acr122 :

 *Quote:*   

> ACR122:
> 
> -------
> 
> Using an ACR122 device with libnfc and without tag (e.g. to use NFCIP modes or
> ...

 

C'est un aussi ce sur quoi semble s'accorder différents posts du forum... ça peut peut-être jouer (i.e. "(...) Some strace showed me that pcscd was actually not using the /etc/libccid_Info.plist. It was reading from /usr/lib/pcsc/drivers/ifd-acsccid.bundle/Contents/Info.plist instead").

Je ne sais pas ce qu'il en est avec notre package mais sait-on jamais que quelque chose cloche de ce côté-là ; c'est sans doute à vérifier si ce n'est déjà fait    :Wink: 

/off : pardonne ma curiosité mais ne connaissant que de principe ce type de reader, dans le "monde réel" quelle en est l'utilisation concrètement ? je veux dire sommairement les déclinaisons partiques, avantages/inconvéniants, etc

----------

## Chr0nos

alors j'ai bien trouvé le fichier ici: /usr/lib64/readers/usb/ifd-ccid.bundle/Contents/Info.plist

du coup j'ai mis a "4" (selon les commentaires dans le fichier ce n'était pas 5), j'ai stopé pcsc, debranché le lecteur de cartes, et rebranché le lecteur (pcsc demare en hotplug des que je branche le lecteur)

malheureusement cela n'a rien changé, j'ai en revanche trouvé un autre fichier: /usr/lib64/readers/usb/ifd-acsccid.bundle/Contents/Info.plist

qui lui contiens des info relatives a mon lecteur (le nom comercial est dans une liste, ce qui n'était pas le cas dans l'autre fichier)

en revanche la valeur du string n'est pas 0x0000 mais 0x00C0 , du coup je n'ose pas trop toucher

pour le lecteur sinon il me sers à faire une copie d'une puce nfc que je peu modifier et ré-écrire sur la clef, et vu que je bosse sur un programe qui modifie ces dumps de clef, je me retrouve un peu bloqué sans la libnfc  :Smile: 

apres niveau inconvéniants: ce lecteur est hyper déprécié par la team de la libnfc et ne veulent pour ainsi dire pas en entendre parler (alors qu'il est tres répendu en raison de son bas prix)

selon moi le probleme viendrais plutot de la non ?: Mar 22 12:57:31 StarK pcscd: readerfactory.c:1009:RFInitializeReader() Open Port 0x1 Failed (/dev/null)

y'a un fichier dans /etc/readers.conf.d/ifd-gempc.conf

dont le contenu est:

 *Quote:*   

> # Configuration file for pcsc-lite
> 
> #
> 
> # GemPC410 reader
> ...

 

donc je me demande si il ne faudrais pas que je fasse un fichier de config pour mon lecteur

----------

## boozo

Ce n'est pas impossible... d'après la remarque en commentaire que tu cites (une $ devicename renseignée avec /dev/null c'est un peu étrange) et c'est ce dont semble se plaindre la méthode plus haut dans les logs non ?

Comment celà se configure-t-il dans /etc/... ? je dis çà un peu au pif mais prendre un des /dev/tty<Sx> ça serait pas la norme pour ces bestioles ?

Au-delà, je ne sais pas trop : peut-être une règle udev existe-t-elle à ce sujet sinon créer une voire passer par un fichier de conf spécifique comme tu le dis... il y a d'ailleurs peut-être un lien direct avec udev/libusb ça peut être une piste aussi

Mais indépendemment je pense qu'il faut aussi retourner investiguer sur les sources, readme et autres fichiers en source d'infos notamment sur ces fichiers .plist - surtout si c'est "à l'abandon" comme périphérique - mais c'est sans garantie que tu trouves une solution au final   :Sad: 

ps: merci pour les infos générales ^^

Edit: Par acquis de conscience, je viens de lire le manpage de /etc/reader.conf.d/reader.conf issue de pcsc-lite (extrait ci-dessous) qu'en est-il chez toi ? 

 *Quote:*   

> SYNTAX
> 
>        The  /etc/reader.conf.d/reader.conf is a regular text file. Each reader
> 
>        must be defined by four fields:
> ...

 

----------

## Chr0nos

j'ai créé un fichier de config pour mon lecteur:

 *Quote:*   

> StarK reader.conf.d # cat acr122u.conf 
> 
> # Configuration file for pcsc-lite
> 
> #
> ...

 

mais dans les logs je me retrouve avec un:

 *Quote:*   

> Mar 23 12:05:00 StarK pcscd: configfile.l:150:evaluatetoken() WARNING: USB drivers SHOULD NOT be declared in reader.conf: /usr/lib64/readers/usb/ifd-ccid.bundle/Contents/Linux/libccid.so

 

donc je suppose que pour mon lecteur il ne faut en fait pas de fichier de config, du coup je me retrouve au meme point

ce qui me choque c'est que si je fais un pcsc_scan : tout marche bien, des que j'utilise la libnfc: plus rien, donc le soucis ne viendrais pas de la pcsc-lite mais plutot de la libnfc ?

----------

## boozo

Personnellement j'aurais repris un format selon les indications du man avec un devicename "standard" i.e.   :Shocked: 

(Et l'adresse de la libccid est bon ? y'a pas une copie ou un lien avec un path plus classique également ?)

Pourquoi dis-tu qu'il ne faut pas de fichiers de conf ? je n'ai rien trouvé à ce sujet mais c'est peut-être d'expérience s'il fonctionnait bien tel quel avant. Là ce qui m'étonne c'est qu'il semble tester une liste d'après tes logs : le GemPC410 qui échoue puis le ACR et tu as un fichier de conf pour un gempc par défaut alors... 

Qu'en est-il si tu actives le paramètre de debug ? Y'a-t-il plus d'infos pour savoir ce qui pourrait clocher ?

(d'ailleurs qu'y a-t-il dans les logs systèmes concernant la détection et les actions udev différents avec les changements de config apportés ?)

 *Chr0nos wrote:*   

> ce qui me choque c'est que si je fais un pcsc_scan : tout marche bien, des que j'utilise la libnfc: plus rien, donc le soucis ne viendrais pas de la pcsc-lite mais plutot de la libnfc ?

 

C'est très possible, je ne sais pas comment les 2 interagissent en séquence mais il faut identifier clairement le pb au moins pour savoir vers quoi chercher   :Sad: 

Y a-t-il une configuration pour libnfc dans /etc au fait ?

Edit: Complément d'infos trouvé sur sur la FAQ libnfc -> a tester donc  :Wink:  :

 *Quote:*   

>  Too small reply error
> 
> With Touchatag or ACR122U
> 
> Avoid using pcscd and libnfc with acr122_usb driver all together.
> ...

 

----------

## Chr0nos

qu'es que tu appele un device name "standard" ? car à part avec des /dev/bus/usb/... je ne sais pas faire, de plus si je fais ca je vais me retrouver avec des ports qui changeront suivant dans quel port je branche mon lecteur non ?

ensuite j'ai viré app-misc/acsccid et j'ai gardé app-crypt/ccid ainsi que pcsc, j'ai coupé intégralement pcsc-lite (je l'ai retiré du rc_hotplug et coupé son service)

malheureusement l'erreur reste la même, je n'ai plus rien dans les logs

pour le fichier de config c'est les logs qui disaient qu'il ne falait pas de fichier de config pour les périfériques usb, avant ca marchais tres bien sans fichier de conifg (ca ne marche plus depuis une maj) mais du coup est il nécéssaire d'utiliser pcsc-lite pour utiliser la libnfc ? car de ce que j'ai compris: la libnfc en dépends mais n'a pas besoin d'avoir le démon de lancé o_O

je peu aussi tenter de désactiver tout ccid si le driver entre en conflit avec quelque chose, car aller toucher dans son code source directement: je ne sais pas faire avec portage qui va surement me voller dans les plumes ensuite

apres je suis tout ouie ^

----------

## boozo

Ben je veux juste dire que c'est pas "classique" d'adresser les devices ainsi ; par exemple pour un port com on prends généralement un /dev/ttSx p.e. mais je ne sais pas comment c'est avec ton bidule... après la détection, c'est pcscd qui gère directement le montage c'est çà ?

Enfin quoi qu'il en soit, si il fonctionnait très bien sans avant ton update et que rien n'a été signalé quant à un besoin de fichier de conf spécifique, là tu as raison, c'est qu'il n'en faut pas.

A ce propos, pourquoi ne pas simplement downgrader le(s) programme(s) qui pose(nt) problème sur la(es) version(s) qui fonctionne(nt) ?

(ce n'est pas pour balancer le pb aux fraises mais si c'est important de pouvoir l'utiliser - vu que le device n'est pas/plus entièrement supporté par les devs upstream en plus - personnellement, je bloquerais portage sur une version qui fonctionne pour au moins pouvoir bosser le temps mettre à niveau le matos sur qqch de plus pérènne et/ou de faire du lobbying sur les mainteneurs   :Razz:  )

 *Chr0nos wrote:*   

> je peux aussi tenter de désactiver tout ccid si le driver entre en conflit avec quelque chose, car aller toucher dans son code source directement: je ne sais pas faire avec portage qui va surement me voller dans les plumes ensuite apres je suis tout ouie ^

 

C'est à l'extrait que j'ai mis de la faq que tu fais référence ? alors oui c'est tout à fait possible de modifier les sources sans que portage ne te baffe. Soit en faisant un bump de version du programme en question dans ton overlay local et en modifiant les sources avant d'installer cette version modifiée (méthode facile à trouver sur f.g.o si tu ne sais pas) ; soit en plus volatil simplement via la commande ebuild (man ebuild pour plus de détails dans les 2 cas de toute façon)   :Wink: 

----------

## Chr0nos

bon, alors apparement app-crypt/ccid est crucial pour pcsc (sans quoi les pcsc_scan ne detectent plus mon lecteur) , en revanche cela n'affecte en rien l'erreur "too smal reply" je pense donc que la libnfc n'utilise que des souces de pcsc , j'ai bien tenté de downgrader tout ce bazard mais à ma grande surprise : cela n'a rien changé, j'ai meme poussé le vice à installer une autre gentoo dans un chroot o_O"

mon bidule est branché en usb (donc pour le port com c'est rappé j'imagine)

pcscd : qu'il soit démaré ou non: idem donc je doute que le probleme viene de lui, surtout que les pcsc-tools sont tous fonctionels

je pense donc que le probleme vient uniquement de la libnfc, 

 *Quote:*   

> A ce propos, pourquoi ne pas simplement downgrader le(s) programme(s) qui pose(nt) problème sur la(es) version(s) qui fonctionne(nt) ?
> 
> (ce n'est pas pour balancer le pb aux fraises mais si c'est important de pouvoir l'utiliser - vu que le device n'est pas/plus entièrement supporté par les devs upstream en plus - personnellement, je bloquerais portage sur une version qui fonctionne pour au moins pouvoir bosser le temps mettre à niveau le matos sur qqch de plus pérènne et/ou de faire du lobbying sur les mainteneurs  ) 

 

je suis bien d'accord avec toi et suis actuelement en train d'esssayer touuuutes les version du paquet (au point ou j'en suis lol) j'espere que cela va marcher^

si cela ne marche toujours pas: demain je tente de modifier directement le code source et adviene que poura ^

----------

## boozo

 *Chr0nos wrote:*   

> (...) j'ai bien tenté de downgrader tout ce bazard mais à ma grande surprise : cela n'a rien changé, j'ai meme poussé le vice à installer une autre gentoo dans un chroot o_O"
> 
> (...) je suis bien d'accord avec toi et suis actuelement en train d'esssayer touuuutes les version du paquet (au point ou j'en suis lol) j'espere que cela va marcher^
> 
> si cela ne marche toujours pas: demain je tente de modifier directement le code source et adviene que poura ^

 

Ce serait tout aussi étrange de ne pas réussir à revenir à l'état antérieur où il était fonctionnel   :Confused:  (mais tu dis essayer "touuuutes" les versions c'est un ebuild live svn peut-être ?)

Essayes de te caler avec les logs de portage quant aux màj qui ont été réalisées depuis la dernière date où tu es certain que tout fonctionnait - en espérant que ce ne soit pas il y a 1 an et que ça ne concerne pas 900 packages -

Pour la modif manuelle : tu peux essayer sans pb en parallèle de la remontée dans le temps c'est sans impact ailleurs sur ta gentoo ; tu pourras toujours défaire/itérer ce que tu auras modifié (voir la features "keepwork" de portage notamment)  

Si rien d'entrepris/envisagé ne marche et pour ne pas te perdre à tord dans d'autres pistes dans ta séquence :

si ça se trouve, le fait de ne pouvoir revenir à l'état antérieur fonctionnel vient peut-être d'un impact corollaire au niveau du kernel par exemple : de la détection hotplug usb ou d'une option impactant les lecteurs de carte multiformats... (des màj le concernent depuis cette date ?)

Allez courage   :Smile: 

----------

## Chr0nos

je suis (enfin) arrivé a mes fins en revenant a la version 1.6 de la libnfc, le svn est sur un 1.7 ce qui cause le souci ^

en fait un .so restais à cause d'un dépendence ^ donc meme quand je downgradais le fichier restais conservé, j'ai supprimé les dépendences, downgradé , et réinstallé les dépendences pour que le link se fasse sur la version downgradée: tout remarche comme avant ^

encore merci pour ton aide^

----------

## boozo

bah j'ai pas fait grand chose ^^

Et puis c'est pas résolu du tout mais au moins tu peux bosser tranquille d'ici a ce que les devs de libnfc se penchent sur le pb en 1.7 

En plus il te reste en parallèle le chroot pour modifier les sources en 1.7 si tu veux te pencher sur la question d'ici-là   :Razz: 

/off: Encore pour ma culture : vu ce qu'on trouve sur web en cas de pépins, on peut dire ça reste encore plus que confidentiel sous linux ces technos sans contact non ? subissent-ils un peu le même sort que les javacard ?

----------

## Chr0nos

et biens sous linux on trouve assé peu de doc sur la technologie nfc deja

la libnfc à utiliser en tant que developeur est assé internale... (du moin pour un débutant tel que moi)

apres j'avoue que le programme que je code est des plus immorals: il modifie des sauvegardes de clefs de machines à café avant de les réinjecter sur la dite clef   :Embarassed: 

mais j'aurais bien aimé pouvoir en savoir plus sur les clefs , leurs méthodes de fonctionement ainsi que la structure interne des dumps faits par mfoc

apres les javacard je ne connais pas du tout, mais je pense que tout ca va se démocratiser avec le temp

----------

