Jump to content

hgdrn

Members
  • Gesamte Inhalte

    5
  • Benutzer seit

  • Letzter Besuch

Reputation in der Community

0 Neutral

Über hgdrn

  • Rang
    Neues Mitglied
  1. 11. April: Keine Antwort von niemandem. Sehr unbefriedigende Situation. Xubuntu 14.04 meldet nach jedem Login einen abgestürzten pcscd. Der Reader funktioniert zwar nach einem Neustart des pcscd, aber das ist doch alles sehr lästig. Schade, dass das niemanden interessiert.
  2. Wir schreiben das Jahr 2017, ich nutze Xubuntu 14.04.5 LTS und seit gestern den Cyberjack RFID Standard, habe ihn mit Moneyplex zum Laufen gebracht, habe anschließend die Abstürze bemerkt und bin nun hier gelandet. Situation: Cyberjack ist nicht angeschlossen, pcss-Daemon läuft nicht root@ltp:/tmp# /usr/sbin/pcscd --foreground --debug 00000000 debuglog.c:269:DebugLogSetLevel() debug level=debug 00000216 configfile.l:254:DBGetReaderListDir() Parsing conf directory: /etc/reader.conf.d 00000033 configfile.l:266:DBGetReaderListDir() Skipping non regular file: . 00000009 configfile.l:266:DBGetReaderListDir() Skipping non regular file: .. 00000014 configfile.l:307:DBGetReaderList() Parsing conf file: /etc/reader.conf.d/libccidtwin 00000073 pcscdaemon.c:545:main() pcsc-lite 1.8.10 daemon ready. 00001825 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/001/001 00000137 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/001/001 00000138 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x8087, PID: 0x0020, path: /dev/bus/usb/001/002 00000144 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x0A5C, PID: 0x217F, path: /dev/bus/usb/001/003 00000138 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x0A5C, PID: 0x217F, path: /dev/bus/usb/001/003 00000134 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x0A5C, PID: 0x217F, path: /dev/bus/usb/001/003 00000129 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x0A5C, PID: 0x217F, path: /dev/bus/usb/001/003 00000129 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x8087, PID: 0x0020, path: /dev/bus/usb/001/002 00000163 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/002/001 00000121 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x1D6B, PID: 0x0002, path: /dev/bus/usb/002/001 00000129 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x8087, PID: 0x0020, path: /dev/bus/usb/002/002 (Cyberjack wird angeschlossen) 12422064 hotplug_libudev.c:269:get_driver() Looking for a driver for VID: 0x0C4B, PID: 0x0500, path: /dev/bus/usb/002/005 00000025 hotplug_libudev.c:321:HPAddDevice() Adding USB device: REINER SCT cyberJack RFID standard 00000077 readerfactory.c:989:RFInitializeReader() Attempting startup of REINER SCT cyberJack RFID standard (1044480224) 00 00 using /usr/lib/pcsc/drivers/libifd-cyberjack.bundle/Contents/Linux/libifd-cyberjack.so CYBERJACK: Started 00001675 readerfactory.c:874:RFBindFunctions() Loading IFD Handler 3.0 02173357 readerfactory.c:327:RFAddReader() Using the pcscd polling thread (Cyberjack wird abgezogen: CRASH) RSCT: No USB context.}nSpeicherzugriffsfehler (Speicherabzug geschrieben) root@ltp:/tmp# Was tun?
  3. Ich stelle zum jetzigen Moment fest: Man möchte nur telefonieren und hat kein Interesse daran, hier im Forum auf meine Fragen eine Antwort zu liefern, die ggf. auch anderen Benutzern oder Forenbesuchern eine Hilfestellung sein könnten.
  4. ich habe die PN beantwortet, bitte antworten.
  5. Die Windows-Treiber scheinen regelmäßig die reiner-sct.de-Server anzurufen und nach Updates zu schauen. Dabei wir ein base64-encodetes XML-File per HTTP GET übertragen. Das sieht dann im Proxy-Log etwa so aus wie im ersten Anhang. Das XML-File selbst sieht etwa so aus wie im zweiten Anhang (btw: was wird da eigentlich alles übertragen?) Problem: Durch die langen XML-Tagnamen ergibt sich ein langes base64-Encoding und entsprechend eine ziemlich lange URL für den HTTP-GET-Request. Unser alter Proxy reicht diesen Request nicht durch und liefert einen TCP_DENIED/400 zurück und syslogt "URL too large". Problem Nummer 2: Die Update-Routine weiß offenbar nicht damit umzugehen und versucht es eine Minute später ein weiteres Mal. Problem Nummer 3: Und so haben wir am Ende des Tages 8 Stunden mal 60 Minuten sprich das ganze Proxy- und Syslog voller immergleicher Einträge. Doof BTW: Es treibt mir ein paar Runzeln auf die Stirn, wenn ich feststelle, dass ein aus Sicherheitsgründen erworbenes Gerät regelmäßig mehrere Kilobyte große XML-Dateien nach Hause schickt, nur um zu schauen, ob es ein Update gibt. Wo kann man das abstellen?
×
×
  • Neu erstellen...