PC reboot

Ne, das hatte vorher schon nicht geholfen.

Ich hab allerdings jetzt zwischendurch Coredumps vom pcscd in libusb gesehen, die genau beim Anstecken des Readers an einen USB Port (mehrere ausprobiert) passieren.

Wenn das mit den letzten Systemupdates gekommen ist, muessten das aber ja andere Benutzer mit derselben Konfiguration nun auch haben (pcscd ist Bestandteil von pcsclite. Ich werd den Maintainer mal anschreiben).

Fehleranalyse Der Smartcard-Dienst pcscd startet, erkennt das Gerät jedoch nicht korrekt. Die Analyse zeigt, dass kein Hardwaredefekt vorliegt --> pcsc_scan findet aber kein Kartenlesegerät. Mit älteren Kernel-Versionen (z. B. 6.7.9) funktionierte der Leser noch einwandfrei. Banking-Software (Hibiscus) kann keine Verbindung zum Leser herstellen. Das Problem trat nach dem 30.09. auf, zeitlich nahe an der Umstellung (VOP). Logauswertung (journalctl -upcscd -f): RSCT: Error on libusb_open: -3 RFInitializeReader() Open Port Failed REINER SCT cyberJack RFID standard init failed pcscd.service: Main process exited, code=dumped, status=11/SEGV Interpretation der Fehlermeldungen: libusb_open: -3 deutet auf ein Zugriffs- oder Berechtigungsproblem beim Zugriff auf das USB-Gerät hin. RFInitializeReader() Open Port Failed zeigt, dass der Leser nicht initialisiert werden konnte. init failed und Failed adding USB device bedeuten, dass der Treiber den Leser nicht einbinden kann. SEGV (Segmentation Fault) zeigt, dass pcscd beim Versuch, auf den Leser zuzugreifen, abgestürzt ist. Ursache: Das Problem tritt ausschließlich unter neuen Kernel-Versionen (6.17.6) auf, ältere Kernel (6.7.9) funktionieren. Vermutlich Inkompatibilität des aktuellen Treibers mit Kernel 6.17.x, möglicherweise in Kombination mit Änderungen an libusb oder udev. Die Berechtigungen für USB-Geräte können zusätzlich einen Zugriff verhindern. Lösungsansätze: Treiber aus dem Source-Code kompilieren Aktuelles Quellpaket: Version 3.99.5 von der REINER-SCT-Website: https://help.reiner-sct.com/de…artenleser Schritte: tar xzf cyberJack-3.99.5.tar.gz cd cyberJack-3.99.5 sudo pacman -S base-devel pcsc-lite libusb glib2 ./configure make sudo make install sudo systemctl restart pcscd Vorteil: Anpassung an den aktuellen Kernel und libusb-Version. Überprüfung und ggf. Korrektur der USB-Berechtigungen Prüfen, ob der Benutzer auf das USB-Gerät zugreifen kann: ls -l /dev/bus/usb/003/006 udev-Regeln laden: sudo udevadm control --reload-rules sudo udevadm trigger sudo systemctl restart pcscd Temporäre Nutzung eines älteren Kernels Kernel 6.7.9 funktioniert, daher kann dieser vorübergehend verwendet werden, bis ein Treiber für neuere Kernel bereitsteht. Viele Grüße REINER SCT

Hallo Michael,
in /etc/udev wirst Du nichts finden, die Rules stehen in /lib/udev/rules.d, da ist dann auch die Datei 60-libifd-cyberjack6.rules.
Aber da wird keine Änderung gewesen sein, die Vendor-Bezeichnungen haben sich sicher nicht geändert.

Bis ReinerSCT reagiert hat, würde ich einen anderen Kernel nehmen, gibts ja sicher. Damit kannst Du dann auch testen, ob das selbstkompilierte Paket funktioniert.

Ich habe trotz Debian Sid immer einen eigenen, selbstkompilierten LTS-Kernel - aktuell 6.1.158 - in Gebrauch, da habe ich kein Problem mit meinem ReinerSCT.

Was meinst Du mit "Sicherheitsmedium wechseln"? Von ChipTanUSB auf was anderes?

[...]
Ich habe in /lib/udev/rules.d/92_pcscd_ccid.rules, welches entgegen der Aussage des pcscd Maintainers vom ccid Paket installiert wird, temporär die Regel

# ReinerSCT_cyberJack_RFID_komfort.txt
ATTRS{idVendor}=="0C4B", ATTRS{idProduct}=="0501", GROUP="pcscd"

hinzugefügt, was allerdings ebenfalls nicht den gewünschten Erfolg gebracht hat.
Das Device hat weiterhin Gruppe root und nicht Gruppe pcscd

Vielleicht ein blöder Hinweis (von jemandem, der die meisten udev-Regeln in /etc/udev/rules.d vermutet hat), aber: Hast du

versucht, um die Regel zu aktivieren? (Alternativ: Neustart)

So nebenbei:

Könnt ihr mal ausprobieren, wie sich das bei Euch verhält, wenn ihr



ausführt und danach guckt, ob Eure Apps (oder auch das Hibiscus) den Reader dann sehen.

Ich hab so den Eindruck, dass die Debugversion nicht abraucht.

ATTRS{idVendor}=="0C4B", ATTRS{idProduct}=="0300", GROUP="pcscd"
# ReinerSCT_cyberJack_RFID_standard.txt

aber wie gesagt, ist ein RFID Standard, eine ID 0501 gibt es bei mir nicht.
Eine eigene geänderte rule sollte man nach /etc/udev/rules.d schieben, /etc hat immer Vorrang vor /lib, insofern warst Du nicht auf der falschen Spur.
Macht man ja bei systemd Units auch so.
Noch eine Idee: man kann mal testweise in /etc/group in der Zeile pcscd den eigenen User zuordnen und neustarten. Evtl. hat man damit Erfolg.

... der Eintrag fuer den RFID Standard kommt nach der Beschreibung, und dann hast du
ATTRS{idVendor}=="0C4B", ATTRS{idProduct}=="0500", GROUP="pcscd"

Moin zusammen,

habe das gleiche Problem mit meinem cyberJack RFID comfort unter Arch Linux.
Folgendes hat das Problem gelöst:
Ich habe in der Datei /usr/lib/udev/rules.d/92_pcscd_ccid.rules einen Eintrag für den cyberjack RFID comfort angelegt, wie bereits vorgeschlagen:

Der kleine Unterschied ist die ProductID in Kleinbuchstaben. lsusb liefert die IDs in Kleinbuchstaben und udev prüft offensichtlich nach Groß- und Kleinschreibung, d.h. "0C4B" != "0c4b".
Einmal noch die udev rules neuladen und der Leser wird unter Hibiscus erkannt und kann genutzt werden.
Hoffentlich wird das Problem beim nächsten ccid update gelöst und idealerweise der cyberjack RFID comfort mit eingefügt.

Grüße moiner