ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Offenbach
Beiträge: 301
Dabei seit: 03 / 2012
Betreff:

ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 16.12.2014 - 04:16 Uhr  ·  #1
Hallo,


ich habe unter OpenSuse 13.1 ein Problem mit meinem Kartenleser, welches ich unter Win7 nicht hatte.
Nicht soooo schlimm, aber immerhin fast immer und recht einfach reproduzierbar, daher frage ich hier mal nach, ob jemand das Problem kennt. Und vielleicht sogar schon behoben hat :-)

Nach einem frischen Linux-Start funktioniert Hibiscus mit dem cyberJack zunächst einmal auch ohne jedes Problem. Ein paar mal zumindest.
Lässt man aber z.B. den Rechner dann aber eine Weile in Ruhe, Zeitraum kann ich nicht genau sagen, dann bleibt Hibiscus (auch wenn es dazu neu vorher gestartet wird) plötzlich beim Zugriff an immer der gleichen Stelle hängen: Egal ob eine HBCI-Karte im Leser steckt, sie wird nicht mehr erkannt "Bitte legen Sie die Chipkarte in das Lesegerät". Und Schluß, kompletter Freeze. Letzte Zeile im Status-Log ist "Öffne HBCI-Verbindung". Keine Tastatur- oder Mauseingaben in Hibiscus mehr möglich.

Will ich Hibiscus schliessen, kommt nach einer Weile, dauert einen Moment, die (vermutlich) KDE-Meldung, dass ein Fenster der Anwendung "swt" nicht mehr reagiert und ob ich die Anwendung wirklich beenden möchte, Sage ich ja, ist zwar Hibiscus sofort zu, aber der nächste Shutdown oder Reboot dauert eine halbe Ewigkeit, irgendwas hängt ab da also zusätzlich im Hintergrund.

Ich dachte zunächst, es liegt am Warten, also an irgendwelchen Energiesparmodi oder so was. Eben gerade hatte ich es aber direkt nach einen Reboot, beim dritten Aufruf. Und umgekehrt bin ich auch sicher, Hibiscus ab und zu erst nach Stunden erstmals genutzt zu haben. Auch da zunächst fehlerfrei.

Irgendwie scheint der erste Start von Hibsicus da was anzutriggern, ich vermute irgendwas mit dem cyberjack Treiber. Das m.W. von ReinerSCT kommende RPM-Paket "pcsc-cyberjack" hat ein Test-Utility "cyberjack", was nach einem Hibiscus-Freeze an der Stelle "BEGIN: ermittle und teste angeschlossene Leser (4/5)" ebenfalls hängen bleibt. Ebenso das aus dem Paket "pcsc-tools" stammende Utility "pcsc_scan", bleibt auch hängen.

Wie gesagt, mein Workaround ist, Kontosachen möglichst nur einmal bis zweimal pro Sitzung durchzuführen, aber eine Idee, woran das Problem liegen könnte, oder wo man weitersuchen könnte, fände ich prima.
Benutzer
Avatar
Geschlecht:
Beiträge: 6679
Dabei seit: 06 / 2008
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 16.12.2014 - 06:43 Uhr  ·  #2
hört sich nach einer Energiesparfunktion an, nur mit Suse kenne ich mich nicht aus.
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Offenbach
Beiträge: 301
Dabei seit: 03 / 2012
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 16.12.2014 - 17:27 Uhr  ·  #3
Wie gesagt, dachte ich die ganze Zeit auch. Bis mir irgendwann aufgefallen ist, dass der cyberJack auch dann IMMER funktioniert, wenn man Hibiscus Stunden nach dem Booten das erste Mal aufruft.
Daher die etwas schwammige Umschreibung "Hibiscus triggert irgendetwas an".

Aber auch ich vermute, dass das weniger mit Hibsicus zu tun hat. Ich habe mal eine Supportanfrage an ReinerSCT gestellt, mal sehen ob die eine Idee haben.
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 325
Dabei seit: 07 / 2005
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 16.12.2014 - 18:57 Uhr  ·  #4
Wenn das Einfrieren gerade passiert ist oder auch nach dem Beenden, schau doch mal auf der Konsole, welche Prozesse noch laufen.
Evtl. kann man dann den Verursacher besser einkreisen.
Oder Hibiscus mal direkt über das Terminal starten, evtl. sieht man auch hier irgendwelche Fehlermeldungen.
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Offenbach
Beiträge: 301
Dabei seit: 03 / 2012
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 23.12.2014 - 20:55 Uhr  ·  #5
Mal ein kurzes Zwischen-Feedback, für die, die es es interessiert :-)

Von ReinerSCT bekam ich erstmal nur ein paar mir schon bekannte Links zum Thema "Kartenleser unter LINUX". Noch nichts brauchbares also.

DIe Idee mit dem Jameica Aufruf aus der Shell/Bash hab ich mal versucht, zeigt aber auch nur wie es scheint, dass Hibsicus auf eine Rückmeldung wartet, welche Kartenleser es im System gibt.

Aufruf mit "funktionierendem" cyberJack:

Code
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.gui.parts.SynchronizeList$SyncStart.handleAction] Collecting synchronize jobs
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.gui.action.Synchronize.handleAction] Start synchronization
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.gui.action.Synchronize.handleAction] backends to synchronize: 2
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.gui.action.Synchronize.handleAction] synchronizing 2 backends
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.gui.action.Synchronize.sync] synchronizing backend HBCI with 10 jobs
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.synchronize.AbstractSynchronizeBackend.execute] starting HBCI synchronization
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.synchronize.AbstractSynchronizeBackend$Worker.<init>] accounts to synchronize: 8, jobs: 10
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.synchronize.AbstractSynchronizeBackend$Worker.updateStatus] updating synchronization status to: RUNNING
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.gui.internal.parts.BackgroundTaskMonitor.check] creating progress monitor for GUI
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.gui.internal.parts.BackgroundTaskMonitor$2.run] activating progress monitor
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.synchronize.AbstractSynchronizeBackend$Worker.run] BEGIN synchronization of account 1/8
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.server.PassportHandleImpl.open] open ddv passport
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.DDVConfigFactory.findByKonto] searching config for konto XXXXXXXXXXXX, blz: XXXXXXXXXXXXXXXXXX
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.DDVConfigFactory.findByKonto] found config via account. name: default
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.DDVConfigFactory.createPassport]   pcsc name: 
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.DDVConfigFactory.createPassport]   soft pin: false
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.DDVConfigFactory.createPassport]   entry index: 1
[Tue Dec 23 19:46:09 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.DDVConfigFactory.createPassport]   passport type: DDVPCSC
[Tue Dec 23 19:46:10 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log] found card terminals:
[Tue Dec 23 19:46:10 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log]   REINER SCT cyberJack RFID komfort (3699930810) 00 00
[Tue Dec 23 19:46:10 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log]  card type: T=1
[Tue Dec 23 19:46:10 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log]  using: org.kapott.hbci.smartcardio.DDVCardService1
[Tue Dec 23 19:46:10 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log] querying features
[Tue Dec 23 19:46:10 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log]   FEATURE_VERIFY_PIN_DIRECT: 42000db2
[Tue Dec 23 19:46:10 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log]   FEATURE_MODIFY_PIN_DIRECT: 42000db3
[Tue Dec 23 19:46:10 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log]   FEATURE_MCT_READER_DIRECT: 42000db4
[Tue Dec 23 19:46:10 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log]   FEATURE_MCT_UNIVERSAL: 42000db5
[Tue Dec 23 19:46:10 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log]   FEATURE_UNKNOWN: 42000dcc
[Tue Dec 23 19:46:10 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.server.PassportHandleImpl.open] ddv passport opened
[Tue Dec 23 19:46:10 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.server.PassportHandleImpl.open]   hbci version: plus
[Tue Dec 23 19:46:11 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log] [BPD] max age: 7 days
[Tue Dec 23 19:46:11 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log] [BPD] last update: Mon Dec 15 12:29:10 CET 2014
[Tue Dec 23 19:46:11 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log] [BPD] expired, will be updated now
[Tue Dec 23 19:46:11 CET 2014][INFO][de.willuhn.jameica.hbci.HBCICallbackSWT.log] resetting BPD version from 42 to 0
[Tue Dec 23 19:46:11 CET 2014][INFO][de.willuhn.jameica.hbci.AbstractHibiscusHBCICallback.update] got new bpd version. old: 42, new: 0, updating cache


Aufruf mit "hängendem" cyberJack:

Code
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.gui.parts.SynchronizeList$SyncStart.handleAction] Collecting synchronize jobs
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.gui.action.Synchronize.handleAction] Start synchronization
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.gui.action.Synchronize.handleAction] backends to synchronize: 2
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.gui.action.Synchronize.handleAction] synchronizing 2 backends
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.gui.action.Synchronize.sync] synchronizing backend HBCI with 10 jobs
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.synchronize.AbstractSynchronizeBackend.execute] starting HBCI synchronization
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.synchronize.AbstractSynchronizeBackend$Worker.<init>] accounts to synchronize: 8, jobs: 10
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.synchronize.AbstractSynchronizeBackend$Worker.updateStatus] updating synchronization status to: RUNNING
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.gui.internal.parts.BackgroundTaskMonitor.check] creating progress monitor for GUI
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.gui.internal.parts.BackgroundTaskMonitor$2.run] activating progress monitor
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.synchronize.AbstractSynchronizeBackend$Worker.run] BEGIN synchronization of account 1/8
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.server.PassportHandleImpl.open] open ddv passport
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.DDVConfigFactory.findByKonto] searching config for konto XXXXXXXXXXXX, blz: XXXXXXXXXXXXXXXXXX
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.DDVConfigFactory.findByKonto] found config via account. name: default
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.DDVConfigFactory.createPassport]   pcsc name: 
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.DDVConfigFactory.createPassport]   soft pin: false
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.DDVConfigFactory.createPassport]   entry index: 1
[Tue Dec 23 19:36:56 CET 2014][INFO][de.willuhn.jameica.hbci.passports.ddv.DDVConfigFactory.createPassport]   passport type: DDVPCSC


Eher durch Zufall ist mir aber was aufgefallen, was für die Theorie "irgendwas schläft ein" spricht: Aus Versehen hatte ich ein Bash-Fenster mit einer laufenden Instanz des Utility "pcsc_scan" aus dem Package "pcsc-tools" am laufen, WÄHREND ich Hibsicus offen hatte. Dieses Utility scheint permament auf den Leser oder einen Daemon zuzugreifen, da es auf jedes Strecken und Entfernen einer Karte reagiert. Daher hätte ich erwartet, das sich Hibsicus und pcsc_scan nicht gleichtzeitig mögen, beim Start von Hibiscus eine Fehlermeldung kommt. Das Gegenteil ist aber der Fall: Solange pcsc_scan läuft, kann ich in Hibiscus tun und lassen was ich will, stundenlang und mit vielen Pausen :-)
"pcsc_scan" scheint den cyberJack also irgendwie "wachzuhalten", spannend....

Einen weiteren "Workaround" für das hängende "Hibiscus" habe ich auch gefunden: Das USB-Kabel des CyberJacks aus- und einstecken, dann fkt. der Zugriff sofort wieder, ohne (verlängerten) Reboot.

FALLS ReinerSCT mir da nichts zurückmeldet: Weiss einer von Euch, welche Linux-Prozesse bzgl. Kartenleser beteiligt sind? Wie die heißen? Es gibt da ja mehrere Zugriffswege (CT-API, PC/SC) daher weiss ich nicht genau, nach welchen Daemons etc. ich suchen muss.
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 4
Dabei seit: 01 / 2015
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 02.01.2015 - 23:33 Uhr  ·  #6
Ich habe ein ähnliches Verhalten bei Moneyplex unter openSuse 13.1 und 13.2 beobachtet: zunächst geht alles wunderbar und irgendwann verklemmt Moneyplex.
Mit Hilfe von http://ludovicrousseau.blogspo…stemd.html habe ich zunächst verstanden, wie das automatische Starten des pcscd funktioniert. Die Ursache für das Verklemmen scheint mir die Funktion "auto-exit" des pcscd zu sein: nach 60s ohne Aktivität beendet der sich. Der Neustart beim nächsten Zugriff funktioniert mit dem cyberjack-Treiber offenbar nicht sauber - bei mindestens einem anderen Leser, der über pcsc-ccid angesprochen wird, geht's einwandfrei.
Meine Lösung ist, pcscd ohne "auto-exit" starten zu lassen. Dazu habe ich /usr/lib/systemd/system/pcscd.service entsprechend geändert. Jetzt bleibt pcscd nach dem ersten Zugriff dauerhaft aktiv - frisst ja kein Brot.
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10015
Dabei seit: 03 / 2005
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 03.01.2015 - 23:31 Uhr  ·  #7
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Offenbach
Beiträge: 301
Dabei seit: 03 / 2012
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 05.01.2015 - 17:46 Uhr  ·  #8
Zitat geschrieben von user_31415

Ich habe ein ähnliches Verhalten bei Moneyplex unter openSuse 13.1 und 13.2 beobachtet: zunächst geht alles wunderbar und irgendwann verklemmt Moneyplex.
Mit Hilfe von http://ludovicrousseau.blogspo…stemd.html habe ich zunächst verstanden, wie das automatische Starten des pcscd funktioniert. Die Ursache für das Verklemmen scheint mir die Funktion "auto-exit" des pcscd zu sein: nach 60s ohne Aktivität beendet der sich. Der Neustart beim nächsten Zugriff funktioniert mit dem cyberjack-Treiber offenbar nicht sauber - bei mindestens einem anderen Leser, der über pcsc-ccid angesprochen wird, geht's einwandfrei.
Meine Lösung ist, pcscd ohne "auto-exit" starten zu lassen. Dazu habe ich /usr/lib/systemd/system/pcscd.service entsprechend geändert. Jetzt bleibt pcscd nach dem ersten Zugriff dauerhaft aktiv - frisst ja kein Brot.


Soweit ich das testen kann hast Du definitiv die Wurzel des Problems erkannt und gelöst.

Ich finde es es insbesondere klasse, dass Du selbst Hibiscus gar nicht nutzt, aber im Forum querliest und Dir dir Mühe machst hier zu posten.

Daher:
user_31415: Du bist mein erster HELD in 2015 !!!!!

Vielen lieben Dank,
Michael
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 8104
Dabei seit: 08 / 2002
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 07.01.2015 - 09:00 Uhr  ·  #9
Auch von mir besten Dank!
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 4
Dabei seit: 01 / 2015
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 08.01.2015 - 09:49 Uhr  ·  #10
Freut mich, wenn meine Erfahrungen auch anderen helfen.
Die Wurzel des Problems ist das natürlich nicht, sondern eher ein Workaround. Mit einem anderen Kartenleser klappt es ja auch ohne Patch.
Ich fürchte, die Wurzel liegt im cyberjack-Treiber.
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 325
Dabei seit: 07 / 2005
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 08.01.2015 - 18:10 Uhr  ·  #11
Hm, ich habe es jetzt mal neugierdehalber getestet, da ich das Verhalten bei mir noch nie bemerkt habe. Ich setze allerdings kein OpenSuse ein, sondern ein Debian Sid.
In meinem pcscd.service ist --auto-exit ebenfalls aktiv. Ich habe einen erneuten Kontoabruf nach gut zwei Stunden "Ruhezeit" ohne Probleme durchgeführt.
Vielleicht ist es doch eher etwas Susespezifisches? Evtl. liegt es auch an den eingesetzten Versionen von systemd und udev? Bei mir läuft beides mit Version 215-8.
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 4
Dabei seit: 01 / 2015
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 08.01.2015 - 20:09 Uhr  ·  #12
Das mag durchaus openSuse-spezifisch sein, hängt aber jedenfalls auch mit dem cyberjack zusammen. Denn, wie gesagt, mit einem anderen Leser (eingebaut im Thinkpad, angesprochen über ccid) gibt es keine Probleme.
Bei mir (openSuse 13.2) werkeln udev + systemd 210-25, pcsc-lite 1.8.13, pcsc-cyberjack 3.99.5final.SP05. Mit openSuse 13.1 sah es aber ganz genauso aus und das waren sicherlich andere Versionen. Vielleicht ist's irgendeine udev-Regel. Aber dem nachzuspüren kann ich mich gerade nicht so richtig motivieren :-)
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 4
Dabei seit: 01 / 2015
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 09.01.2015 - 08:11 Uhr  ·  #13
So richtig glaube ich doch nicht an eine Ursache im Bereich systemd/udev. Denn nach dem auto-exit wird pcscd beim nächsten Zugriff durchaus wieder gestartet - auch mit cyberjack. Damit hat nach meinem Verständnis systemd seine Schuldigkeit getan. Nur das Gespann aus pcscd und cyberjack verklemmt sich beim zweiten Mal irgendwie.
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 325
Dabei seit: 07 / 2005
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 09.01.2015 - 14:50 Uhr  ·  #14
Die gleichen Versionen für pcscd und cyberjack habe ich auch, wobei ich den Treiber von der ReinerSCT-HP einsetze.
Ich wüßte jetzt auch direkt keine Ursache, systemd und udev waren Vermutungen meinerseits. Auch der Kernel scheidet wohl aus...ich kann auch leider nichts nachsehen, da es bei mir ja läuft.
Vielleicht ändert sich ja was bei OpenSuse 14
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Offenbach
Beiträge: 301
Dabei seit: 03 / 2012
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 21.01.2015 - 18:42 Uhr  ·  #15
Ich habe nach Verweis auf diesen Thread eine neue Antwort vom ReinerSCT Support bekommen, allerdings noch nicht getestet:

Code

Bitte stellen Sie in den Energieeinstellungen Ihres Rechners ein, dass der usb-Port, an dem Ihr cyberJack RFID komfort angeschlossen ist, nie in den Stromspar-Modus (Standby) schalten soll.
Alternativ können Sie auch einen usb-HUB mit separater Stromversorgung zwischen den usb-Port und Ihren cyberJack RFID komfort schalten.
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Leipzig
Homepage: willuhn.de/
Beiträge: 10015
Dabei seit: 03 / 2005
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 25.01.2015 - 23:01 Uhr  ·  #16
Danke Michael fuer die Info. Schoen zu sehen, dass sich ReinerSCT hier engagiert. Hat das mit den Stromspar-Einstellungen mal jemand getestet?
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 49
Dabei seit: 08 / 2009
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 18.09.2020 - 10:06 Uhr  ·  #17
Hallo Leute,

erst einmal Entschuldigung, das ich diesen stark angestaubten Thread noch einmal ausbuddele.
Nachdem ich von LinuxMint auf Solus umgestiegen bin, habe ich aber ziemlich genau das beschriebene Problem und noch keine Lösung dafür gefunden.
Weder die Lösung von Reiner SCT einen aktiven USB-Hub zu nutzen, noch das bearbeiten der pcscd.service bringt Besserung. Einzig ein abziehen und neu anstecken des Readers bewirkt, das er benutzt werden kann.
Gibt es vielleicht inzwischen noch andere Lösungen, welche ich noch nicht gefunden habe?
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 49
Dabei seit: 08 / 2009
Betreff:

Re: ReinerSCT cyberJack RFID komfort unter OpenSuse 13.1

 · 
Gepostet: 19.09.2020 - 14:00 Uhr  ·  #18
Okay, ich antworte mir mal selbst:

Nachdem ich den Treiber von Reiner SCT kompiliert und installiert habe, funktioniert alles wie gewohnt. Es scheint also ein Problem im ccid Treiber zu sein.
Gewählte Zitate für Mehrfachzitierung:   0