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

um welche Bank/Karte handelt es sich?
war die Karte bereits im Einsatz bspw. Moneyplex?

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?

Hallo miteinander,

@ pahhur: Danke für deinen Einsatz. So weit war ich auch gekommen. Nur eine Überweisung habe ich noch nicht mit diesem Setting durchgeführt. Ich kann - vor allem vorübergehend - mit dem Debogmode des pcscd leben. Jedenfalls hat die Veränderung der /usr/lib/systemd/system/pcscd.service (Ergänzung um "--debug") bei mir nicht geholfen.

@alle: Ich hatte die Fehlermeldung von pahhur auch (Fehler 6A82: Datei wurde nicht gefunden). Den Link von infoman hatte ich selbst gefunden. Er schien mir angesichts der Gesamtproblematik aber nicht hilfreich zu sein.
Will damit sagen: Auch bei mir ist die selbe Karte schon 2 Jahre im Einsatz und erst seit eines Updates (die zu diesem Faden geführt hat) wegen des Lesers setting-abhängig außer Funktion.

Mfg Michael

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

Weiterer Nachtrag:

Ein weiterer Experte bei Reiner fordert nun ein, dass dieses nicht mit udev Rules sondern mit polkit gelöst wird
und zwar von demjenigen, der pcscd zur Verfügung stellt.

Den Vorschlag hab ich an das pcsclite weitergeleitet.

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 ...

@pahhur
Das finde ich wirklich gut, daß Du da dranbleibst, alle Achtung.
Aber so wie es aussieht, schiebt das jetzt Einer zum Andern und keiner fühlt sich zuständig, das kennt man ja.
Folgende Idee habe ich noch:
Der Verzeichnisbaum ist natürlich von Debian, wird evtl. etwas anders in Arch lauten, aber das weißt Du ja sicher.
Ich habe in /usr/share/polkit-1/policy eine polkit.action, vielleicht kannst Du die in Arch einfügen. Ob die dann funktioniert, müßte man probieren.

Dann würde ich in /usr/share/misc/ die usb.ids prüfen, ob der Eintrag vorhanden ist. Bei mir ist das der Fall, wenn nicht, ergänzen:

Die udev-rule hast Du ja schon in /etc/udev/rules.d

Evtl. hilft das etwas weiter.

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.

Doch, Debian hat die udev-rules und ebenso die policy Datei und die usb.ids. Alle Dinge, die ich genannt habe, sind standardmäßig in Debian vorhanden, daher hatte ich auch keinerlei Probleme.
Dann bin ich ja mal gespannt, wer denn nun letzendlich das fehlende Stück beisteuert *daumendrück*

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.

So, ich habe mal alles zusammengestellt, wie ich es in meinem Debian Sid habe.
Wie schon zuvor geschrieben, habe ich keinerlei Probleme gehabt, auch bei einer Überweisung letzte Woche als Echtzeitüberweisung.
Meine Bank ist die Sparkasse Bochum, ich nutze chipTan-USB, hier die anderen Infos:

Das habe ich noch gefunden:
https://blog.apdu.fr/posts/2025/10/pcscd-runs-as-pcscd-user/
In Debian Sid ist das bereits umgesetzt

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 ...

Ich habe die rules mal ins Home verschoben und neu gestartet. Es funktionierte trotzdem, der Kartenleser wird erkannt und ich konnte bei der Bank Umsätze abrufen. Zum überweisen hab ich grad nix, aber das würde wohl auch funktionieren.
Tja, da unterscheidet sich Debian zu Arch doch wohl ziemlich, dann kannst Du die VM ja erstmal behalten. Vielleicht ist Michael ja auch interessiert.
Den bereits geposteten Link hab ich dann wohl übersehen... na ja, man ist ja schließlich nicht mehr die Jüngste ;-)

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.

Merkwürdig, die VM ist doch Debian Sid? Ob da was emuliert wird? Aber eigentlich macht das doch alles systemd und udev.
Wenn die gleichen rules und policies auf dem Hostsystem eingerichtet sind, sollte es doch auch funktionieren, da ist Arch doch nicht anders als Debian.
Ich weiß es nicht....