Neue Version (jameica 2.12, hibiscus 2.12) hat Probleme mit dem Reader (ReinerSCT Comfort)

hab ich gesehen, trifft aber bei mir nicht zu (Alle Konten standen bereits auf PIN/TAN).
Ich hab als erstes geguckt, was der Reader Dialog hergibt, der zeigt die Fehlermeldungen.

Aber die Funktionalität der App (Statusabfrage + Überweisung) ist gegeben

Es ist eine dedizierte Banking Card der Sparkasse (Minden Lübbecke).
Die war vorher schon mit Hibiscus im Einsatz, davor auch eine Banking Card,
und davor als HBCI-Chipkarte bezeichnete HBCI Karten.

Oder ist der Eintrag

nur ein Relikt und könnte gelöscht werden?

Weiterer Update

Die Maintainer von pcsclite verweisen an Upstream bzgl. ccid (welches die Rules mitliefert)

Upstream fuer ccid ist aber wiederum Ludovic Rousseau, der einigermassen genervt geantwortet hat, er sei dafür nicht zuständig (weil libifd-cyberjack.so von ReinerSCT benutzt wird und nicht sein ccid, ganz ignorierend, dass seine Regeln sehr wohl Anwendung finden). Er sei nur willig, sich die Gross- und Kleinschreibung Sache anzugucken,er sei aber nicht bereit, den Komfort Reader hinzuzufügen.

Dafür sei Reiner zuständig, Regeln in seinen Treibern mitzubringen.

Nachdem ich das dann dem pcsclite Team mitgeteilt habe, haben diese den Bug geschlossen.

Es verbleibt nun eine Anfrage bei Reiner, wie diese zu diesem Thema stehen.


Nachtrag:

Bis zu einer Lösung seitens Reiner, empfehlen diese, die Änderungen wie folgt zu machen:

/etc/udev/rules.d/99-cyberjack.rules

Ich habe aber auch das ganz offensichtlich fehlende exit() eingefordert

Aktueller Stand:

• Ludovic Rousseau besteht auf udev rules und sagt, die Maintainer von pcsclite müssen diese integrieren.

• Die Maintainer von pcsclite sagen, upstream d.h. entweder Rousseau (als Basis fuer das pcscd Paket) oder Reiner in ihrem Treiberpaket müssten diese zur Verfügung stellen

• Reiner will nur debian unterstützen und stellt nur eine polkit Datei zur Verfügung, die angeblich unter Debian funktioniert und die Arch Maintainer von pcsclite müssten das integrieren.

• Die Maintainer von pcsclite sagen dazu wiederum, dass sie die Funktionalität bezweifeln und das nicht integrieren werden.

Ganz ignoriert wird dabei, dass seit mindestens 50 Jahren grundsätzlich der Hauptprogrammierer vorgibt, wie zu konfigurieren ist, und nicht jemand, der etwas zuliefert ...

Inzwischen ist rausgekommen, obwohl die pcsclite Maintainer das in Sekundenschnelle abgelehnt hatten, dass die (obige) .policy Datei sehr wohl bereits seit mindestens Oktober vom pcsclite Paket mitgeliefert wird. Und die Regeln werden auch in einem pkaction --verbose angezeigt.

Nur damit und ohne udev Rules stürzt das Ganze ja ab, sonst wären wir ja gar nicht hier.

Ich hab mal direkt bei Arch einen Bug aufgemacht, indem ich frage, wieso das nicht auf arch läuft, wenn es doch vermeintlich "auf Debian und allen Derivaten ohne udev rules läuft" (So O-Ton Reiner; allerdings ist das natürlich eine komische Aussage, denn auf den aktuellen Stable-Versionen ist ein pcscd 2.3.* drauf und kein 2.4.0, somit läuft der da auch weiterhin mit root und die policy Datei und udev rules deshalb ggf. unnötig )

usb.ids hab ich unter /usr/share/misc/  nicht (in dem Verzeichnis ist gar nichts), dafür aber unter /usr/share/hwdata/ (und da sind die Reader auch drin).

Mit eigenen udevs geht es natürlich. Das ist aber ja nicht Sinn der Sache, dass jeder einzelne Nutzer das selber pfriemeln muss.

Ja, jetzt hängt es ja davon ab, wie dein Setup ist.

• welche udev Rules meinst du ?
  
• welchen Reader hast du ?
  
• welche Version des pcscd läuft da bei dir und unter welchem User?
  

Welches Paket hat denn diese Regeln unter Debian mitgebracht ? libccid ? Dann sind das ja die buggy Regeln, ueber die wir hier gesprochen haben, für die Rousseau verantwortlich ist, der sich wiederum weigert, den RFID Komfort dort aufzunehmen und er auch wiederum sagt, dass diese gar nicht für den "ifd" Treiber des RFID Komforts zuständig sind.

Ich habe auf meiner "nagelneuen" Debian sid/forky VM Testinstallation libccid nicht installiert. Trotzdem nimmt dort das Device in der Tat die Gruppe pcscd an (Ob das an der VM, weil dort das USB durchgeroutet wird, kann ich nicht sagen)

Die installierten Pakete unter Debian sid/forky:



Interessant dabei, dass ich sp17 installiert bekommen habe, welches es auf der Seite von Reiner noch ueberhaupt nicht gibt.

Nachtrag:
Nun hab ich dort ein 60-libifd-cyberjack6.rules gefunden, dass mir beim ersten Check nicht aufgefallen war

dpkg -S 60-libifd-cyberjack6.rules
libifd-cyberjack6: /usr/lib/udev/rules.d/60-libifd-cyberjack6.rules

und das wird von dem 17SP mitgeliefert (entgegen der Aussage von Reiner)

Nachtrag 2:

Reiner stellt nun das SP17 auf seiner Seite zur Verfügung.
Ich hab den arch Maintainer des Pakets dazu aufgefordert, die SP17 zu integrieren, inklusive der obigen Datei.

Ja mit dem udev rule File sollte es ja auch keine Probleme geben. Das widersprach aber der Aussage von Reiner,
die sagen, es würde auch nur mit dem policy File gehen. Nimm doch mal das 60-libifd-cyberjack6.rules aus den Rules raus (mv in dein Home, danach reboot oder sudo udevadm trigger) ... und du würdest vermutlich die gleichen Probleme haben, wie wir auch.

Und den Link .... ummmm, den hatte ich doch schon ein paar Posts weiter oben gegeben Der hat die Arch Maintainer aber bisher nicht interessiert, denn solche Änderungen müssten von upstream kommen ...

Nun, in meiner VM funktioniert der RFID Komfort genau dann nicht mehr, wenn ich die 60-libifd-cyberjack6.rules verschiebe und danach udevadm trigger ausführe. Sobald ich die Datei wieder nach /lib/udev/rules.de zurückbewege (plus udevadm trigger) ist der Leser wieder voll funktionsfähig.